[Gimp-developer] hmmmm
I can't reach the website http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer So I also can't unsubscribe the normal way ... Are there other ways to unsubscribe from this list ? -- Philip van Hoof aka freax (http://www.freax.eu.org) irc: irc.openprojects.net mailto:freax @ pandora.be ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: I expect that we're going to go alpha with 4.2 in the relatively near future, and then release some time this summer. What should we do about syncing up? What are you suggesting? I think we are willing to include a new version with stable gimp-1.2 if it has seen a good amount of testing. I would suggest you release 4.2 and if we do another stable gimp-1.2 release after this release we will consider including the new version. To assure that this happens and enough people test it, we should include 4.2 into gimp CVS as soon as it is released. For gimp-1.3/1.4 this brings up the general question about plug-ins again... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] hmmmm
Hi, Philip Van Hoof [EMAIL PROTECTED] writes: I can't reach the website http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer it seems to work for me. Does your browser support certificates? Did you try again? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
From: Sven Neumann [EMAIL PROTECTED] Date: 20 May 2001 13:47:36 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: I expect that we're going to go alpha with 4.2 in the relatively near future, and then release some time this summer. What should we do about syncing up? What are you suggesting? I think we are willing to include a new version with stable gimp-1.2 if it has seen a good amount of testing. I would suggest you release 4.2 and if we do another stable gimp-1.2 release after this release we will consider including the new version. To assure that this happens and enough people test it, we should include 4.2 into gimp CVS as soon as it is released. That sounds reasonable. Release is probably at least a few months off right now, but I want to get things rolling. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] hmmmm
I can't reach the website http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer it seems to work for me. Does your browser support certificates? Did you try again? Ok, I tried with netscape and now it works.. looks like Galeon with Mozilla 0.9 doesn't support certificates ? :( -- Philip van Hoof aka freax (http://www.freax.eu.org) irc: irc.openprojects.net mailto:freax @ pandora.be ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: plug-in distribution choices
[EMAIL PROTECTED] (2001-05-20 at 1535.17 +0200): Am I to understand that there is no recorded instance of this discussion? Well, let's start now, then, so that next time we can point to the mailing list archives. You can request IRC / mail logs, maybe someone has them. First of all a definition of the problem area: what are considered plug-ins? Everything that goes into the directory 'plug-ins'? Anything else? Some modules too, like the colour selectors, could be considered plug-ins. When talking about scripts earliers, I noticed that there is no clear way of distinguishing which scripts belong in the core distribution and which don't. I suggest we tackle this problem (first?). Scripts depend on the interpreter, so that would mean the interpreter should be in core app, which is not bad, but also not necessary. Scripts are plugins for plugins. My suggestion is that the following plug-ins belong to the core distribution: - those that perform a task that the GIMP should have provided for itself or will provide for in the future; I doubt Gimp will provide more, the idea is to have a small system where you plug things as needed, even GUI will be separate (and that for me is plugable). This general idea can be read in somewhere, this list archive probably. - those that will help other plug-in authors better understand how to write plug-ins; That should be in a devel package. Why do a user need a plugin that does nothing or near nothing? It is like the test script fu, lots of controls and you get a plain ball. Or like devel packages, users do not need to waste space with .h files that will never use. - those that will make the GIMP look good when compared to other raster image editors; and Then you include all those working, so you are sure you are giving the maximum you can. - those that perform a task the best in its field. I doubt there are repeated plugins, people do not code to have two, they patch instead. And if they did not know, they try to join the work, or deprecate the bad one. Can such a distinction be made? Yes, but you forgot: - plugins that are maintained. I think your point of view is what users want / need and the real thing is what volunteer coders can do. And from that comes the idea of reducing the number of core plugins, moving the rest to 1..N packages. That or somebody finds a way to keep all plugins updated (pay a coder with comunity money like with a Perl one? create a company to support it?). :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in distribution choices
Hi, Branko Collin [EMAIL PROTECTED] writes: Am I to understand that there is no recorded instance of this discussion? Well, let's start now, then, so that next time we can point to the mailing list archives. The mailing list archive definitely has at least parts of this discussion. Since we did not come to a conclusion last time, the archive is however not very helpful and you are right in pointing out that we should start it all over now. First of all a definition of the problem area: what are considered plug-ins? Everything that goes into the directory 'plug-ins'? Anything else? Scripts are definitely in the same category. In the future we will also see pluggable tools and its foreseeable that we will face the same problems there at one point. My suggestion is that the following plug-ins belong to the core distribution: - those that perform a task that the GIMP should have provided for itself or will provide for in the future; Our goal is to have as much functionality as possible in plug-ins. This reduces the size of the core, makes it cleaner and improves maintainability of the core. This makes this rule questionable especially since a task that the Gimp should provide is much too vague. - those that will help other plug-in authors better understand how to write plug-ins; We have a plug-in template for this task and I don't see what would stop plug-in authors to have a look into the plug-in packages that are distributed seperate from the core gimp package. - those that will make the GIMP look good when compared to other raster image editors Only because another program has a certain functionality does not make it necessary to distribute the same functionality with core Gimp. - those that perform a task the best in its field. Not a very useful definition either. Those plug-ins will most likely be pretty large and only useful to a subset of users. Thus they belong into a special package. Can such a distinction be made? You are right that we need to make such a distinction, but I don't think the rules you suggested make much sense. On the other hand I think we should first discuss how the gimp packaging should look like in the future instead of tackling the problem which plug-ins go into which package. I'll try to summarize some of the ideas that have come up during earlier discussions: A very important point for distributing a plug-in is to have a maintainer that feels responsible for it. The core Gimp maintainers would like to only have a set of basic image manipulation tasks in the core package and they would feel responsible for keeping them up to date, handling bug-reports and discussing patches. Such basic plug-ins would include for example Blur, Gauss-Blur, Sharpen, Rotate, and a set of important file-plug-ins to give only a few examples. Other plug-ins could be grouped into smaller packages for special purposes. For example there could be a gimp-web-plug-ins package that adds functionality like GIF-Save, Anim-Optimize, ImageMap and others. Such a package would have a maintainer who is responsible to handle bug-reports and keeping the package in sync with the core. Installing gimp would then be a process of installing gimp-core and a set of plug-in packages that fit the needs of the user. Such an approach has some obvious advantages but also a bunch of drawbacks: The packages would have interdependencies. The web-plug-ins package might include a gimp-perl script so it would require gimp-perl. Of course everything in the web-plug-ins package but this script would work w/o gimp-perl so actually gimp-perl is not required but only recommened. I can however only think of one binary package system that can handle those kind of weak interdependencies (debian). The packages should not overlap and they should share the menus intelligently. This would require some interaction between package maintainers. I think however that this should be doable. On multi-user systems the administrator who installs gimp can not decide what packages the users might want. One solution is to install them all. This would however lead to overcrowded menus. A problem that could be solved by a plug-in manager that knows about all plug-ins that are available and lets the user choose what plug-ins she wants to see in the menus. Having gimp split up into dozens of packages will make installation difficult. Again a plug-in manager that knows about all available plug-ins out there, collects and installs them would help. It turns out we need a plug-in manager. What functionality should such a beast have? Here's a list of things that came to my mind: It should read a number of plug-in lists: a list of all available plug-ins that is distributed with the core gimp and can be updated through the web. A list of plug-ins that are installed locally do not necessarily appear in the menus. It should have meta-packages of plug-ins similar to the task-lists Debian has so a user
[Gimp-developer] Re: plug-in distribution choices
[EMAIL PROTECTED] (2001-05-20 at 1636.07 +0200): It turns out we need a plug-in manager. What functionality should such a beast have? Here's a list of things that came to my mind: [...] It should be able to download and install precompiled binary packages or download sources, compile and install them. A solution for the binary packages would be to use the binary packaging system provided by the distribution. Since there are a bunch of different distrbutions out there, this might be tricky. 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). Also it would mean secutiry audit for UID 0 routines. We all know how fun would be messages like I got new plugins, but my other account does not have them or it gets them, and then hangs while CPU and disk go 100% (compilation) or it seems hung, but after some minutes it says error, missing lib, and I have that lib (but not lib-devel). If people with knowledge can have problems, imagine the rest. 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. GSR PS: OTOH it would be nice if Gimp could read post mail news. And IRC too. /me ducks runs. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PLUGIN] Gallery Maker full reviewed
On Sat, May 19, 2001 at 09:06:12PM +0200, Fabian Fridirick wrote: IMHO, it's a fundamental misunderstanding of the user needs and MEDIA growth.(Imagine there'll be _only_ DVD distro by 2002 or so). What's the problem if Gimp comes with some more useful scripts ? I think the point is that plug-ins are unnecessary to the GIMp, and therefore shouldn't be distributed with it as source, or for that matter in distributions. There is nothing stopping people who distribute the gimp from (say) having a gimp package and a gimp-plugins package, and installing both by default. But the plug-ins probably don't belong in the same CVS module as the core. For example, no-one would argue that binutils shouldn't be distributed with the linux kernel (in a distribution), but they're not stored in the same place in source. The linux kernel is all but useless without userland apps (in most environments), yet the userland apps aren't maintained in the same place. Similarly, the gnome core and the gnome games aren't stored in the same module, and are of interest to different developers. The only thing I'm worrying about in plugin supply is the _physical_ layering in menus.Who cares it's an executable or a Perl script which does the stuffAll has to be presented in a transparent way... And the standard APIs that exist for plug-in programming will continue to exist, and may even get easier. Regards, Fabian Cheers, Dave. -- .--. / David Neary, \ | E-Mail [EMAIL PROTECTED] | \ Phone +353-1-872-0654 / `--' ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: plug-in distribution choices
Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: plug-in distribution choices
Sven Neumann wrote: Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] writes: 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. snipped... If by deal with binary packages, mean make binary packages, I don't think we have the resources. Of course, we can't be indifferent to package makers of the distribution companies at the principle and practices level, since the workings of the plug-in manager will have an influence on how to make packages. 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. I also think this general approach is correct, but the design of a package manager would take a great deal of care (albeit, very useful). This particular rule readily turns into a protocol encoding a plug-ins' dependencies on other resources, (other plug-ins, modules, libraries, interpreters), its preferences in a menuing system, version level requirements, etc. 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. This would also be an ideal pipeline to inventory existing plug-ins with an eye toward how well they can be adapted to a package manager, what constraints they would place on the design of a package manager, establishing weak/strong dependencies among plug-ins, and deciding about functional groupings (i.e., logical packaging). 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. I think the Gimp could also use a Plugin Maintainer on par with the Core Maintainer to midwife this effort. Be good, be well Garry ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
