[Gambas-user] User components in Gambas 3

Jorge Carrión shordi at ...626...
Wed Apr 21 09:29:01 CEST 2010


If this structure means that all dependencies will be solved in package
time, It sounds fine.
Installation of gambas applications on clients machines is, perhaps, one of
the greater weakness of gambas, I think...
You ara doing a fine work Benoît.
Regards

2010/4/20 Benoît Minisini <gambas at ...1...>

> 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.
>
> 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.
>
> - 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.
>
> 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...
>
> What do you think about the new design?
>
> --
> Benoît Minisini
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>



More information about the User mailing list