Gamma and Collaborative way, question about techniques

Hello, while i m learning gamma, we are two to work on the same project.
We choosed Github, but in fact its not at all adapted to the App design of Gamma, where a same document may handle everything. Parts of “changed code” appears as XML hints from the *.vl files, so its un readable.

My first question, would that be possible to have a driect front end to Github INSIDE Gamma ? Nodes with modifications and warnings would appear inside gamma. Yes , i know its a lot of work, but really this would change a lot of things !

Other question, to avoid troubles we tried to split in modules the code:

  • having the main app including .vl files , and using them.
  • having the modules/interfaces apart

This way is giving the following troubles :

1: the modules, being included only as declarations give a problemof testing and usage. If i put in their vl space the way to use it, it will be udpdated in the app. It would be in fact SUPER COOL to have a special space for developping in stand alone a module, that, if included in a vl app will not be called, but if opened alone maybe called for developpement and tests. i dont know if its clear ? ( actually i use comment frame)

2: modules working with side vl types ( from other modules) dont know them. Should we create per project a global include file with all types and declarations ? will it make a mismatch in memory if i make 3 or 4 times the same include inside my app ?

Voilà, i hope that this feedback will give some idea and that someone will tell him what is the best practice for including files and developping modules.

cheers

This helps with merging .vl files in the git repository:

Thank @tonfilm . I installed it. But didnt notice any changes in front end. I dont understand how it works ( thank you to explain me like to a child ! )

For that, you could structure your dependencies as a library and use help patches as test beds. At least that’s what I’d do if I had a significant number of nodes/functions that need to be tested and documented.

Could you rephrase that? Not sure what you mean there.

2 Likes

Could you rephrase that? Not sure what you mean there.

Thank you sebescudie, i will try:

when writting independant modules ( not libraries but parts of the project) i m facing problems with handling types that are aside in the global project.
Should i redeclare them inside this modules as declarations ( possible mismatches ?), or is there any way to do it in a cleaner way ?

App level calling types from down level is ok but:
----------------> module 1 needs some types from module 2
----------------> module 2
----------------> module 3 needs some types of module 1

It’s totally OK to have all your definitions living in separate documents and reference them from your “main” application document. Something like :

  • ⬛ MyProject.vl is the file you open to start your application, but it does not define anything (let’s call that the entry point of your project). It only references stuff from the following definitions document. This allows you to potentially have multiple entry points for the same project with slightly different configurations/setups.
  • ⬛ MyProjectDefinitions.vl contains all your project’s definitions.

Even better : you can split that to more fine grained documents (like ⬛ MyProjectVideoStuff.vl, ⬛ MyProjectDatabaseStuff.vl) to make sure people don’t create conflicts in git, and still have them referenced by ⬛ MyProjectDefinitions.vl which only forwards them. This has the effect that your app only has to reference ⬛ MyProjectDefinitions.vl (which, again, is empty and just forwards the audio and database stuff) and gets all datatypes, functions and whatnot.

Also, duplicating definitions sounds like a terrible pattern and will not work anyway because the system should consider them as two different types.

But without knowing the structure of your project it’s kinda hard to give more precise advice.

7 Likes

@sebescudie thank you very much for this clear advice !
its pointing to a good solution !!! thank you !