[Gambas-devel] User components in Gambas 3

Charlie Reinl Karl.Reinl at ...646...
Wed Apr 21 10:53:25 CEST 2010


Am Dienstag, den 20.04.2010, 22:40 +0200 schrieb Benoît Minisini:
Salut,

I will write into your mail, to tell
> Hi,
> 
> I post this mail on both mailing-lists: please answer on the developer 
> mailing-list if possible, as this is related to the development version!
> 
> I'm currently thinking about how user components should work in Gambas 3, as I 
> dislike the way it was designed in Gambas 2.
> 
> In Gambas 2, user components work the same way as normal components made with 
> Gambas, except that they are symbolic located in the home directory that point 
> at the real executables.

> That design lead to many problems: you can't make packages of user components 
> easily, and if the real executable moves, the symbolic link is broken while 
> the IDE think the component is there.

That's only while MakeLink in the IDE isn't *perfect* 

> 
> So, for Gambas 3, I propose a different design:
> 
> - There are no "user" components anymore.
> 
> - Instead, a project will be able to depend on other projects.
> 
> - The list of associated projects will be defined in the IDE project option 
> dialog.
> 
> - That list will be just a list of project *names*.
> 
> - At design time, these project will be search inside one or more directories 
> that will be defined as a IDE global option.
> 
> - At run time, the associated projects will be searched by using the $PATH 
> environmental variable, as any other executables.
> 
> Consequently:
> 
> - The IDE global option will tell where you store the projects you want to use 
> as components.
> 
> - These projects will be packaged separately and installed like any other 
> Gambas projects.
> 
> - They should have a special name, because they are not real executables, but 
> some sort of "Gambas" libraries instead.

For me that will be a BIG problem, because, some of my "components" are
executables, which used in other projects.

Why, even if retaining all of the points below, it could not be
executable and/or library.

> - So the project executables should be in the $PATH. And so the main project 
> will find them easily.
> 
> - When creating the main project packages, it will be easy to add a dependency 
> on the associated project packages.

For packages a big step forward  

> 
> I need to find a good term for these "associated" projects. I'd like to find 
> something different than "component". 
> 
> Even if internally the interpreter will use the same code to load them, I want 
> the user to understand easily that they do not work the same way.
> 
> Maybe "library" would be a good term...

here are synonyms for component (in german) :
Abschnitt, Teil, Part, Partie, Segment, Bereich, Teilstück, Etape,
Periode, Etappe, Zyklus,Bauteil, Baustein, Bauelement, Modul, Element,
Bestandteil, Glied, Element, Grundstoff

That is the output of the google-translater : 

Section, part, part, section, segment, range, section, Etape, period,
phase, cycle, Component, device, component, module, element, component,
element, element, basic, 

And : "gambas-Add On", gambas-domino, gambas-link
> 
> What do you think about the new design?


-- 
Amicalement
Charlie





More information about the Devel mailing list