Re: Speaking of additional plug-ins
On Wed, Jan 26, 2000 at 07:28:13PM -0500, Kelly Lynn Martin [EMAIL PROTECTED] wrote: to redo the UI for 1.4/2.0, which included a considerably different way of handling plugins. Plugins would be installed w/i the Gimp interactively (a noninteractive installation procedure would be offered for system administrators) with the user being asked where to install the plugin in the menu tree and so forth. I've never gotten Without affecting the plug-ins at all you can get the advantages of this approach by having some kind of menu editor: just as you can already customize shortcuts, it should be possible to customize menu layout, disabling plug-ins, moving them into differnt menus (even duplicate entries would make sense, e.g. for a quick-access menu for the ten most used plug-ins that the user itself can administer. would be great with tear-off-menus as well). BTW, "should" means "would solve many probelms at once". I have no idea how much owrk it is, but you can combine that with some kind of plug-in-manager (since it already _is_ a kind of plug-in manager). For example it should be easy then to select a binary plug-in using a file selector, and gimp updates it's rc files to search that file for a plug-in etc... It would be cool to have a more flexible plug-in management inside the gimp (e.g. at the moment you can only register plug-ins at startup) anyway, for other reasons as well. Just my thoughts... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Speaking of additional plug-ins
On Wed, Jan 26, 2000 at 01:24:44AM +0100, Sven Neumann wrote: enough. Ideally, this project should completely replace the registry. A web interface to the repository together with tips for installation will be essential. Plug-ins should be released on a regulary basis, Better yet, a GIMP interface. If we are to change the entire plug-in architecture anyway, we should make a single way of compiling and installing them. /* Steinar */
Re: Speaking of additional plug-ins
On Wed, 26 Jan 2000 14:31:52 +, "Steinar H. Gunderson" [EMAIL PROTECTED] said: Better yet, a GIMP interface. If we are to change the entire plug-in architecture anyway, we should make a single way of compiling and installing them. I've thought about this somewhat. I had a vague idea in mind for how to redo the UI for 1.4/2.0, which included a considerably different way of handling plugins. Plugins would be installed w/i the Gimp interactively (a noninteractive installation procedure would be offered for system administrators) with the user being asked where to install the plugin in the menu tree and so forth. I've never gotten back to it, though. Kelly
Re: Speaking of additional plug-ins
On Tue, Jan 25, 2000 at 12:03:43PM -0500, "Garry R. Osgood" [EMAIL PROTECTED] wrote: For the record, I think a plug-in CVS tree independent of Gimp is a good idea. "Let's focus, people!" At the time this was discussed, the office of a "plugin-maintainer" was also posed, I don't think this is a good idea. Ok, it is a good idea, but I fear you won't find somebody, despite being such an honourable position. GCC is without release manager and will likely stay without one, simply because nobody wnated that most honourable position (and the work ;). The issue is: who has the time? Without people, good ideas remain abstract. I have no time, but I would nevertheless devote part of on merges between the two cvs trees. I could also set up a cvs server, but I firmly believe that it should be related to the gimp.org domain, and I would first have to ask my "boss" wether abusing a machine at the university would be ok (this is a space issue). So my first wish would be to set up an empty cvs on some reliable server, and I would try to populate it with the gimp tree, with (say) nightly updates from main cvs = gimp plug-in cvs (for the core), so that plug-in developers can just check out the tree from the plg-in server and work there. Failing that, I will set up a gimp server on a local machine (in germany), but I can't promose that (I iwll need to find a free disk, but maybe in one or two weeks I can spare 2GB for it). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Speaking of additional plug-ins
From: Dean Johnson [EMAIL PROTECTED] Date: Tue, 25 Jan 2000 16:00:23 -0600 (CST) Cc: [EMAIL PROTECTED] (Garry R. Osgood), [EMAIL PROTECTED] (Gimp Developer's Newslist) Marc Lehmann spontaneously blurts out: Failing that, I will set up a gimp server on a local machine (in germany), but I can't promose that (I iwll need to find a free disk, but maybe in one or two weeks I can spare 2GB for it). This has SourceForge written all over it! Its easy an convenient to start projects and manage stuff. I heartily endorse it! Indeed. I've been using SourceForge for about a week for the Print plugin (the gimp-print project), and it's really good. It takes some time to learn, though. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Speaking of additional plug-ins
On Tue, Jan 25, 2000 at 04:00:23PM -0600, Dean Johnson [EMAIL PROTECTED] wrote:
Failing that, I will set up a gimp server on a local machine (in germany),
but I can't promose that (I iwll need to find a free disk, but maybe in
one or two weeks I can spare 2GB for it).
This has SourceForge written all over it! Its easy an convenient to start
projects and manage stuff. I heartily endorse it!
Hmm... sounds sensible. Unless somebody comes up with something better
I'll start it in a week or so.
My idea is to copy the full cvs tree of gimp to (lets call it gimpforge)
and give any intersted plug-in author write access.
Updates from the gimp-cvs-tree/{libgimp,app,tools...} to gimpforge should
be automatic and regular, while updates in the other direction should be
enabled for specific files (plug-ins/common/snoise.c) or subdirectories
(e.g. plug-ins/perl).
That will effectively implement some kind of access-model, and it will
(hopefully) make it possible to *select* a fileset for distribution.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Speaking of additional plug-ins
For the record, I think a plug-in CVS tree independent of Gimp is a good idea. "Let's focus, people!" [snip] The issue is: who has the time? Without people, good ideas remain abstract. I have no time, but I would nevertheless devote part of on merges between the two cvs trees. I could also set up a cvs server, but I firmly believe that it should be related to the gimp.org domain, and I would first have to ask my "boss" wether abusing a machine at the university would be ok (this is a space issue). delurk People should feel free to ask for a CVS account on the cvs.gnome.org box. If they have something cool they are working on for the GIMP, we can certainly give them access, provided they are willing to follow the standard GNOME CVS etiquette. As far as the GIMP is concerned, people could maintain their own experimental plug-ins in little CVS modules and later, when the plug-in is Done(tm), they could ask a CVS maintainer to physically move it to the main GIMP module. Or it could be linked as a virtual module, which also is a nice solution. This way you can have branches for particular plug-ins. In particular, I would love to see the fantastic Print plug-in on the GNOME CVS :-) Of course, that is up to Robert to decide. If there is anything the CVS maintainers can do to make Robert's life easier, I'd love to hear about it. /delurk Federico
Re: Speaking of additional plug-ins
Hmm... sounds sensible. Unless somebody comes up with something better
I'll start it in a week or so.
My idea is to copy the full cvs tree of gimp to (lets call it gimpforge)
and give any intersted plug-in author write access.
Updates from the gimp-cvs-tree/{libgimp,app,tools...} to gimpforge should
be automatic and regular, while updates in the other direction should be
enabled for specific files (plug-ins/common/snoise.c) or subdirectories
(e.g. plug-ins/perl).
That will effectively implement some kind of access-model, and it will
(hopefully) make it possible to *select* a fileset for distribution.
This all sounds nice, but I hope you are aware that once gimp-1.2 is out
there will unlikely be another stable release (despite bug-fix releases
of course) before gimp-2.0 and the plug-in interface for 2.0 will certainly
be incompatible with what he have now.
I don't want to say that plugin development should stall until the
new interface has settled, but it would probably be a good idea to take
this into account from the beginning and split the tree from ground up.
This means having two branches (stable and devel) on the plugin CVS. That
way we could throw all plug-ins out when work on 2.0 starts and include
them later out of the 2.0 compatible plug-in branch. However I haven't
thought much about this yet, is it a good idea ...?
I also want to point out that IMHO setting up a CVS server will not be
enough. Ideally, this project should completely replace the registry.
A web interface to the repository together with tips for installation
will be essential. Plug-ins should be released on a regulary basis,
since working with stuff out of CVS is not what our users want to do
and it always buries the risk of checking stuff out that just doesn't
work at the moment.
...just my 2 cents...
Salut, Sven
Re: Speaking of additional plug-ins
Marc Lehmann spontaneously blurts out:
Hmm... sounds sensible. Unless somebody comes up with something better
I'll start it in a week or so.
My idea is to copy the full cvs tree of gimp to (lets call it gimpforge)
and give any intersted plug-in author write access.
Updates from the gimp-cvs-tree/{libgimp,app,tools...} to gimpforge should
be automatic and regular, while updates in the other direction should be
enabled for specific files (plug-ins/common/snoise.c) or subdirectories
(e.g. plug-ins/perl).
That will effectively implement some kind of access-model, and it will
(hopefully) make it possible to *select* a fileset for distribution.
I guess I wasn't advocating moving the whole tree over, just the plug-ins.
I don't know anything about the GIMP development process, or the internal
intrigue that seems to surface from time to time, so I can't ascertain
whether the whole thing should move.
-Dean Johnson
Tool Hooligan
Cluster Admin Tools Jessie Project
Silicon Graphics Inc.Eagan,MN (651) 683-5880
"I am Dyslexic of Borg, Your Ass will be Laminated"-- unknown
Re: Speaking of additional plug-ins
On Tue, Jan 25, 2000 at 07:17:31PM -0500, Federico Mena Quintero [EMAIL PROTECTED] wrote: People should feel free to ask for a CVS account on the cvs.gnome.org box. If they have something cool they are working on for the GIMP, we As a matter of fact, it is very difficult ot get a cvs account, for various reasons. We do not want to have every plug-in author have writing rights to the gimp tree, but we _do_ want every plug-in author to have them. For other reasons, giving them access to a "shielded cvs" could be done much easier (just let him prove he can do it), than having to persuade a lot of people to get a cvs account (for good reasons). On Tue, Jan 25, 2000 at 06:37:17PM -0600, Dean Johnson [EMAIL PROTECTED] wrote: I guess I wasn't advocating moving the whole tree over, just the plug-ins. No, the way it'l be done is to mirror the whole tree, so people can just check out the _whole_ gimp from sourceforge, and work in it. The difference to the anonymous server is that they can write to the cvs, but they will not be able to change any files not marked for changing. On Wed, Jan 26, 2000 at 01:24:44AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: this into account from the beginning and split the tree from ground up. This means having two branches (stable and devel) on the plugin CVS. That I think we should just do the same as we do on the main cvs server: once 1.2 is out, make a 1.2 branch, do the same on the plug-ins server. them later out of the 2.0 compatible plug-in branch. However I haven't thought much about this yet, is it a good idea ...? I haven't thought about that myself, but having two barnches (then) makes very much sense to me. The mirror script would be almost the same. I also want to point out that IMHO setting up a CVS server will not be Oh ;) SourceForge gives us all that, web, ftp, cvs etc.. As a matter of fact, there already is a sourceforge project named "gimp-plug-ins" since a few hours ;) My (better thought-pout plan) is to add these two files to the main gimp cvs: PLUGIN_CVS # control what gets mirrored, when ChangeLog.plug-ins # the changes for the plug-in tree the first one declares some files/directories to be part of the "plug-ins" cvs enough. Ideally, this project should completely replace the registry. A web interface to the repository together with tips for installation will be essential. Plug-ins should be released on a regulary basis, since working with stuff out of CVS is not what our users want to do and it always buries the risk of checking stuff out that just doesn't work at the moment. I fully support this. Alas, it's much work, so I suggest that I first create the project, add the mirroring (so the cvs is functional) and then gather _existing_ plug-in maintainers without cvs access to find out wether they want an account on ther sourceforge net. After that, some files (i.e. the "externally managed" plug-ins) are read-only in the main cvs tree, and writable in the plug-in cvs tree, and all the rest is read-only in the plug-in cvs, and read-write in the main gimp directory. This is the only solution that makes it possible to do automatic merges back into the main tree. It also complicates things for the main developers, so it should be given thought (in any case, the mirror script that I have allows to specify "file in original server", "file in copied/plug-in server" and "file is not getting mirrored" (i.e. it's part of gimp-plug-in-cvs but NOT part of the main gimp tree). [before you misunderstand the above paragraph, ask!] If this is in place we/I should seek out for help to get more automatic registrations etc.. (i.e. registering plug-in "space", having nicer packaging etc..) Having a seperately managable tree would it also make it possible to experiment with new ways of plug-in distribution, binary packages etc.. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Speaking of additional plug-ins
On Mon, Jan 24, 2000 at 04:10:46PM -0500, Michael Taylor [EMAIL PROTECTED] wrote: It looks like I've missed the deadline for another version of GIMP. I read that people are concerned about the number of plug-ins currently shipping with the GIMP. I have previously tried to elicit an opinion about whether that concern applies to format plug-ins, but I didn't get any responses. I think the issue is independent of the type of the plug-in. However, I don't believe in the "we accept no more useful plug-ins, since we already have so many useless ones in the tree" argument. Falks: what about that "secondary cvs server for plug-ins"-idea? I only remember a few posotive responses, but no really negative ones. Is it only that nobody has the time to set one up? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Speaking of additional plug-ins
I have a couple of image format plug-ins available for the GIMP one is included with the GIMP (pix) and one of them (formerly tdi, now MayaIFF) has been in the unstable tree since before 1.0 was released. The latest version, as always, is in the plug-in registry. It's not likely that many people on this list will be very interested in files of the MayaIFF variety. You would either have to be using Maya (http://www.aliaswavefront.com/entertainment/index.html) or Shake (http://www.nothingreal.com/). And would probably put you in the film or video game industry. From the number of e-mails I get, there are a lot of people using GIMP with Maya, primarily on SGI's. I distribute a binary of my plug-in for IRIX via my web page. But, unfortunate differences in which cut of GIMP and IRIX they have make it difficult to make my plug-in work on all SGI's. Most Maya/SGI users don't have a compiler installed either, so when it doesn't work, they are out of luck. It would be much less frustrating for users and less time consuming for me if I could get my plug-in into the main tree. It looks like I've missed the deadline for another version of GIMP. I read that people are concerned about the number of plug-ins currently shipping with the GIMP. I have previously tried to elicit an opinion about whether that concern applies to format plug-ins, but I didn't get any responses. If it is a concern, then I'd say that the MayaIFF plug-in is more useful than the Pix plug-in that I submitted in time for 1.0. Also, I'm behind a firewall and I haven't managed to get CVS working through it. I'm not sure what would be involved in getting it moved over. So, I would be ever so grateful if someone could comment on: 1. would it be appropriate to add yet another format plug-in to the main branch 2. when should I add it 3. what's involved in moving it (it's a single file plug-in) I've been maintaining the plug-in for over two years now and I will continue to do so. Nobody has ever logged a bug against it that wasn't related to getting it working on their particular cut of IRIX or GIMP. Any help or discussion would be greatly appriciated! /\/\ike -- Mike Taylor ([EMAIL PROTECTED]) Alias|Wavefront, Toronto http://reality.sgi.com/mtaylor
