[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