Hi, "Guillermo S. Romero / Familia Romero" <famrom@xxxxxxxxxxxxxxxxxxxx> writes: > I would make a basic plugin handler so users can remove / add them to > menus, if installed, and let the real task of getting the plugin to > user / pkg system / whatever. If you use a pkg system, it can do it > for you better than anything, if not, there is a make install target > or a gimptool mode for that. I do not think becoming another Red > Carpet is worth the time (which in place seems to be APT with GUI). [...] > So I would split the system more at source level, so you get x groups > and build & install them (or make distro pkgs then install) following > an order, like you can do with GNOME, ie. ATM I already use that (with > x=2): gimp and gimp-data-extras. actually this is my opinion too. I'm not convinced that we should try to deal with binary packages. This is one of the ideas that has come up and that I remembered, but I second your thoughts about it. IMHO the best solution will be to have a bunch of standalone source packages that follow some well-defined rules. One rule should be that there needs to be a file that describes the package and all its components that can be used by the plug-in manager and by the next generation plug-in registry. Ingo had an XML format in mind and I was hoping he would post a proposal to this list, but I haven't seen it yet. For the moment we want to keep all plug-ins in the core package until we have ported Gimp to Glib/GTK+-2.0. This is because we think that a lot plug-ins will be ported very easily and having them all in one place might ease this task. Once the port is done (and we are going to start it very soon now), we should think about moving most of the plug-ins out of the core CVS module. Hopefully we have made up our mind on the new plug-in system until then. Salut, Sven
