Re: [Gimp-developer] making plans
This is going back a bit... Sven Neumann wrote: I suggested that we make a list of changes for 2.2, so I sat down and tried to come up with such a list. [...] - option to edit files from cmd line sequentially http://bugzilla.gnome.org/show_bug.cgi?id=110242 I've thrown together a plugin which might satisfy the original feature request. It probably needs some refinement, but it's interesting that this can be done as a plugin rather than needing any core code changes. It's at: http://members.ozemail.com.au/~hodsond/fileSeq.html Comments are welcome. I haven't actually done much testing, but it seems to work OK. There's also a small bug in that the plugin keeps a stray reference to the last image used - how do I get rid of that? -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
V St 31. 03. 2004 v 20:08 +0200 píše Sven Neumann: > Hi, > > Dave Neary <[EMAIL PROTECTED]> writes: > > > I just tried this, and it didn't appear to work. At least, I didn't > > see my pattern show up in the pattern list after doing a refresh. > > Works for me and there's no need to refresh, the script does that for > you. As a person that prefers DnD as the most natural interface, I really welcome the possibility of dragging a layer from the layer dock to the pattern dock to create a new pattern. Similarly dragging an image from outside gimp to the pattern dock would be neat. cheers -- Jakub Steiner <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
[sorry for the late reply - I am just wading through pending replys] Joao S. O. Bueno ([EMAIL PROTECTED]) wrote: > But I do have a choice from the list bellow I like to address: > > > - vectors PDB API > > http://bugzilla.gnome.org/show_bug.cgi?id=129598 > > (this would allow to move the SVG path import from the core to a > >plug-in) > > If Simon is not picking it right now, I could check with him on what > is needed, and go for it. Well, I want to work on this, although I'll definitely wait until the branch for 2.2 has happened. However, I want to encourage people to suggest an API for conveniently handling strokes and vectors. > Just in case I can do it, and the Text Tool PDB ain ready, I'd like > to go for it. > > I have also one other improvement I think I could work on, and this > would be great, so I might even postpone the above PDB stuff: > Postscript saving plug-in. Feel free to hack on that, I won't come into your way there. > Also, to be added to the list of what I think is feasible: > - Add Vector Layers functionality. > (Simon, you there? ) Yes, definitely interesting and challenging. Before actually implementing this we'd need generalized Stroking Options for paintcore stroking and libart stroking. Probably something similiar should happen for the fill options (vector layers need filled vector shapes...) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I just tried this, and it didn't appear to work. At least, I didn't > see my pattern show up in the pattern list after doing a refresh. Works for me and there's no need to refresh, the script does that for you. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Sven Neumann wrote: Hi, Dave Neary <[EMAIL PROTECTED]> writes: I see this like Guillermo - creating a new pattern should bring up the new file dialog, and save the new image silently with an automatically generated filename and a .pat extension. That way, when you click on "New pattern", you get a new image dialog which you handle as usual, and then the .pat "Enter pattern name" dialog to save the pattern. It could be nicer, but I think that's sufficient. You will run into problems as soon as people start to use multiple layers, channels, layer masks and the like on the pattern image. Not at all - Ctrl-S or File->Save will go through the pat plug-in which will propose the conversion. It's no more of a problem than if I save something as a pattern now and then add a layer. The reason why these shortcuts are interesting is because they make making custom patterns obvious for people who don't want or need to know about the contents of .gimp-2.0. I see your point. But you don't really need to know about .gimp-2.0 in order to use Script-Fu->Selection->To Pattern. I just tried this, and it didn't appear to work. At least, I didn't see my pattern show up in the pattern list after doing a refresh. As I said, that's the easy part, though - making stuff in the patterns dialog act sanely is a little trickier. It would definitely be better to have this script in File->Save as GIMP Pattern though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I see this like Guillermo - creating a new pattern should bring up > the new file dialog, and save the new image silently with an > automatically generated filename and a .pat extension. That way, > when you click on "New pattern", you get a new image dialog which > you handle as usual, and then the .pat "Enter pattern name" dialog > to save the pattern. It could be nicer, but I think that's > sufficient. You will run into problems as soon as people start to use multiple layers, channels, layer masks and the like on the pattern image. > The reason why these shortcuts are interesting is because they make > making custom patterns obvious for people who don't want or need to > know about the contents of .gimp-2.0. I see your point. But you don't really need to know about .gimp-2.0 in order to use Script-Fu->Selection->To Pattern. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: The latter part (save as GIMP pattern) would be trivial, more or less. Handling the semantics for creqting new patterns in the pattern dock and duplicating/editting existing patterns is trickier. Well, there is already a menu entry for saving an image as GIMP pattern; it's nicely handled by a simple Script-Fu. That's good news, I'd suggest putting it in the File menu then. Really, I don't see this as an urgent issue, but sure, if you want to duplicate the image editing functionality of GIMP in the pattern editor, give it a try. I see this like Guillermo - creating a new pattern should bring up the new file dialog, and save the new image silently with an automatically generated filename and a .pat extension. That way, when you click on "New pattern", you get a new image dialog which you handle as usual, and then the .pat "Enter pattern name" dialog to save the pattern. It could be nicer, but I think that's sufficient. Duplicate is, as Guillermo said, just a copy (well, not quite - I'd see it more like the duplication of a gradient works, and use the GIMP Item code to do it). Editing a pattern is just opening the file. Almost trivial. Dragging & dropping images to the pattern dialog is a different matter, and a little more complicated. The reason why these shortcuts are interesting is because they make making custom patterns obvious for people who don't want or need to know about the contents of .gimp-2.0. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > The latter part (save as GIMP pattern) would be trivial, more or > less. Handling the semantics for creqting new patterns in the pattern > dock and duplicating/editting existing patterns is trickier. Well, there is already a menu entry for saving an image as GIMP pattern; it's nicely handled by a simple Script-Fu. Really, I don't see this as an urgent issue, but sure, if you want to duplicate the image editing functionality of GIMP in the pattern editor, give it a try. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: I suggested that we make a list of changes for 2.2, so I sat down and tried to come up with such a list. This list is not meant as the list of things that need to go into 2.2 but it's a list of things that could go into 2.2. A prerequisite for each item is that someone volunteers to work on it. And of course the list is by no means complete. Please send a mail if you want to see items added. I would still like to do this one: Allow creation and editting of patterns in the pattern dock, as well as a "Save as GIMP pattern" menu entry which automatically saves the image as a .pat in .gimp-2.0/patterns http://bugzilla.gnome.org/show_bug.cgi?id=132208 The latter part (save as GIMP pattern) would be trivial, more or less. Handling the semantics for creqting new patterns in the pattern dock and duplicating/editting existing patterns is trickier. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi,
"William Skaggs" <[EMAIL PROTECTED]> writes:
> From: Sven Neumann <[EMAIL PROTECTED]>
> >You didn't address point (a). Really, these strings are meant as a
> >description for developers, not for users. They don't explain what the
> >plug-in does when being called interactively, they explain what the
> >particular PDB function does. There are plug-ins that register a
> >number of PDB functions. What string would you use to display in the
> >user interface? The interactive call might actually do something
> >completely different.
>
> Well, as you pointed out, the strings are not in fact currently used for
> anything, because they mainly don't exist.
They are being used by the DB Browser which provides developer
documentation for the registered procedures. That's what these strings
are made for. The fact that there isn't much help available clearly
outlines the problem. Experience has shown that developers suck at
providing help. And people that are able and willing to contribute
help don't want to touch the source. We solved this dilemma by
introducing a way to contribute help that is decoupled from the
source. It handles translation and is IMO quite easy to use. All we
need to do is to fill that system with info. It would be shame to
weaken this effort by introducing yet another way to provide user
documentation.
> As for the second problem, you simply use the string that is
> relevant to the dialog that you're displaying.
How do you know what string that is?
> Well, two points: First, the plan I am suggesting is one that I can
> execute by spending 5-10 minutes per plug-in, not counting the time
> it takes to figure out how the plug-in works.
I am sure that if someone from the gimp-help-2 team could provide
templates it would be simpler and even less work than to edit the
source code.
> I would love to write a bunch of plug-in help pages, but only if I
> can write them as plain text or something Latex-like. (In fact, I
> invented a little "help-language" with a few commands like
> "\help-id{plug-in-foo-scale}" and have written a couple of things
> that way, with the thought for writing an xml-spewer that will put
> all the stereotyped angle-bracket stuff around it, but I don't want
> to go too far in that direction until I know if it makes sense.)
I am sure we can convert whatever format you prefer to what's needed
for gimp-help-2.
See, my point is that I like the idea of improving the plug-in user
interface. It is important to give the user more help what she can do
with all those filters. But I don't think we need a new API for it. We
can use the existing infrastructure. It is only missing content.
If you also want to do some hacking on the plug-in source code, rest
assured, there's something for you to work on. We could have a look at
bugzilla together, what do you think?
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
From: Sven Neumann <[EMAIL PROTECTED]>
>You didn't address point (a). Really, these strings are meant as a
>description for developers, not for users. They don't explain what the
>plug-in does when being called interactively, they explain what the
>particular PDB function does. There are plug-ins that register a
>number of PDB functions. What string would you use to display in the
>user interface? The interactive call might actually do something
>completely different.
Well, as you pointed out, the strings are not in fact currently used for
anything, because they mainly don't exist. My thought was just that it
is a convenient place to put a brief description, where there are already
tools to access it easily. As for the second problem, you simply use the
string that is relevant to the dialog that you're displaying.
>
>> I've actually already written meaningful pdb-help for about 1/3 of
>> the relevant plug-ins -- it takes about 5 minutes once you
>> understand what the plug-in does -- and am ready to do it for the
>> rest if I have some reasonable confidence that I'm not wasting my
>> time.
>
>Given the problems I outlined above, I wonder if this time would be
>better spent on writing help for the plug-ins. If we had at least a
>little bit of help for each plug-in, we could continue to use the PDB
>strings for what they've been designed for and we have added the help
>system for exactly this purpose. What do you think about putting your
>descriptions into gimp-help-2? You wouldn't need to do a full page for
>each plug-in. A page for each filters menu would be completely
>sufficient to begin with.
Well, two points: First, the plan I am suggesting is one that I can execute
by spending 5-10 minutes per plug-in, not counting the time it takes to
figure out how the plug-in works. Second, after spending a couple of hours looking
at gimp-help-2, I don't have a clue how to do anything with it. If I have
to write XML, it takes me about an hour to do a paragraph, and then my
eyes are blurred from all the angle brackets. I would love to write a bunch
of plug-in help pages, but only if I can write them as plain text or something
Latex-like. (In fact, I invented a little "help-language" with a few commands
like "\help-id{plug-in-foo-scale}" and have written a couple of things that
way, with the thought for writing an xml-spewer that will put all the
stereotyped angle-bracket stuff around it, but I don't want to go too far
in that direction until I know if it makes sense.)
>
>If we did this using the help system, you wouldn't even have to call
>the plug-in dialog to get to the help about it. Pressing F1 with the
>plug-in menu entry focused already calls the respective help ID. And
>the navigation that's possible with the help or web browser allows you
>to discover the GIMP plug-ins a lot faster as if you would have to
>bring up the dialog for each plug-in first.
Aha, now here you're telling me something I didn't know, since I've never
had a system set up with functioning help, and it actually solves a lot
of the issues.
Best,
-- Bill
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > >The problem is that the "blurb" and "help" strings as they are > >registered with the PDB are (a) not meant to be user help You didn't address point (a). Really, these strings are meant as a description for developers, not for users. They don't explain what the plug-in does when being called interactively, they explain what the particular PDB function does. There are plug-ins that register a number of PDB functions. What string would you use to display in the user interface? The interactive call might actually do something completely different. > I've actually already written meaningful pdb-help for about 1/3 of > the relevant plug-ins -- it takes about 5 minutes once you > understand what the plug-in does -- and am ready to do it for the > rest if I have some reasonable confidence that I'm not wasting my > time. Given the problems I outlined above, I wonder if this time would be better spent on writing help for the plug-ins. If we had at least a little bit of help for each plug-in, we could continue to use the PDB strings for what they've been designed for and we have added the help system for exactly this purpose. What do you think about putting your descriptions into gimp-help-2? You wouldn't need to do a full page for each plug-in. A page for each filters menu would be completely sufficient to begin with. If we did this using the help system, you wouldn't even have to call the plug-in dialog to get to the help about it. Pressing F1 with the plug-in menu entry focused already calls the respective help ID. And the navigation that's possible with the help or web browser allows you to discover the GIMP plug-ins a lot faster as if you would have to bring up the dialog for each plug-in first. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
>You have valid points Bill. However, popping up unnecessary dialogues will >also undesirably slow down and get in the way of many users. If you proceed >with your suggested changes, then I would strongly suggest an option to >bypass the dialogue for plug-ins that don't really need one. Well, the extra time it takes is the time to hit the return key, since Okay is the default response. Anyway, I'll add an anecdote. One of the plug-ins that don't use a dialog is Gradient Map. So, exploring the Gimp universe, I came across this one in the menu, and thought "hmm, what does this do?", and tried it. It converted my image to grayscale! I thought that was a bit odd, since there was already a much easier way to convert an image to grayscale. The only way I could figure out what Gradient Map did was to read the source code. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
>The problem is that the "blurb" and "help" strings as they are >registered with the PDB are (a) not meant to be user help and (b) >missing or not helpful in almost all plug-ins. Also these strings >would have to be translatable. This could be easily changed but before >you call for translation there would have to be reasonable strings. I was actually aware of that. I've actually already written meaningful pdb-help for about 1/3 of the relevant plug-ins -- it takes about 5 minutes once you understand what the plug-in does -- and am ready to do it for the rest if I have some reasonable confidence that I'm not wasting my time. (I've been trying to understand what plug-ins exist and what they do, and in the course of this it just seemed natural to write down a brief summary for each one I looked at.) Of course by this I don't mean a full help page, I just mean information enough to tell a user what the plug-in does and whether it is likely to be useful for the current need. >> It should also have a "Help" button that invokes the help browser >> with the main help page for the filter. > >This could be discussed. Basically since we have help IDs with every >dialog, we could have a help button everywhere (and we wouldn't need >any API changes to do that). But then we are often short of space in >the dialog action area. Last time we discussed this we went for not >adding Help buttons. The idea was that F1 would be good enough to get >to the Help. Of course we could review this decision. Yes, I know it's redundant, but (a) it's very easy, and (b) the help button is not on the main dialog, only the "About" dialog, so it doesn't add clutter for practical purposes. Certainly not essential, but friendly to new users. (Incidentally, most plug-ins are very lacking in help-id's; I've been adding some as I go.) > >Please excuse if I may sound demotivating. I am only trying to explain >the reasoning behind the current state and problems that I see with >your suggestions. I am perfectly willing to discuss this further. I have anticipated these points, and a few others you haven't mentioned yet, but didn't want to make an already long email longer by trying to discuss every possible aspect at once. Let the discussion continue! >I'd also like to add that in we plan to redo the way that standard >filters create dialogs. When we get a new PDB API where plug-ins >register named parameters with default value, range and a blurb, we >can construct a user interface from that similar to what (but not how) >Script-Fu does it now. With some extra info more complex user >interfaces could be build. The beast prject has some code that does >this and perhaps we could use it or implement a similar approach. For >a plug-in author this would mean that unless the plug-in needs >non-standard widgets, no GUI code would have to be written at all. Well, I think that what I am suggesting is a step toward this, and would actually make it easier when the time comes. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
You have valid points Bill. However, popping up unnecessary dialogues will also undesirably slow down and get in the way of many users. If you proceed with your suggested changes, then I would strongly suggest an option to bypass the dialogue for plug-ins that don't really need one. s/KAM - Original Message - From: "William Skaggs" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Gimp Developer" <[EMAIL PROTECTED]> Sent: Monday, March 29, 2004 2:18 PM Subject: Re: [Gimp-developer] making plans > > >> 1) Every filter should produce a dialog when called interactively. > >> At the moment, some just do their thing without showing any dialog: > >> this is bad. > > > >Why is this bad? There are plug-ins that are supposed to be completely > >non-interactive. You call them from the menu, they do their job. What > >is bad about that? > > It's bad because (a) it's disconcerting to the user, when 95% of plug-ins pop > up a dialog, to have a couple that just plunge ahead, (b) Re-Show doesn't > make sense when nothing is ever shown, and most importantly (c) it's > impossible to summon help when there's no dialog. > > Separate response for other stuff. > > -- Bill > > > > > __ __ __ __ > Sent via the KillerWebMail system at primate.ucdavis.edu > > > > > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
>> 1) Every filter should produce a dialog when called interactively. >> At the moment, some just do their thing without showing any dialog: >> this is bad. > >Why is this bad? There are plug-ins that are supposed to be completely >non-interactive. You call them from the menu, they do their job. What >is bad about that? It's bad because (a) it's disconcerting to the user, when 95% of plug-ins pop up a dialog, to have a couple that just plunge ahead, (b) Re-Show doesn't make sense when nothing is ever shown, and most importantly (c) it's impossible to summon help when there's no dialog. Separate response for other stuff. -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > 1) Every filter should produce a dialog when called interactively. > At the moment, some just do their thing without showing any dialog: > this is bad. Why is this bad? There are plug-ins that are supposed to be completely non-interactive. You call them from the menu, they do their job. What is bad about that? > 2) The dialog should contain three standard buttons, "About", > "Cancel", and "Okay". The "Cancel" and "Okay" buttons should do the > obvious things; the "About" button should pop up a dialog that shows > the "blurb" and "help" strings for the filter, as entered into the > PDB. The problem is that the "blurb" and "help" strings as they are registered with the PDB are (a) not meant to be user help and (b) missing or not helpful in almost all plug-ins. Also these strings would have to be translatable. This could be easily changed but before you call for translation there would have to be reasonable strings. We tried this approach for Script-Fu scripts (w/o the translation). I don't think it works very well. > It should also have a "Help" button that invokes the help browser > with the main help page for the filter. This could be discussed. Basically since we have help IDs with every dialog, we could have a help button everywhere (and we wouldn't need any API changes to do that). But then we are often short of space in the dialog action area. Last time we discussed this we went for not adding Help buttons. The idea was that F1 would be good enough to get to the Help. Of course we could review this decision. Please excuse if I may sound demotivating. I am only trying to explain the reasoning behind the current state and problems that I see with your suggestions. I am perfectly willing to discuss this further. I'd also like to add that in we plan to redo the way that standard filters create dialogs. When we get a new PDB API where plug-ins register named parameters with default value, range and a blurb, we can construct a user interface from that similar to what (but not how) Script-Fu does it now. With some extra info more complex user interfaces could be build. The beast prject has some code that does this and perhaps we could use it or implement a similar approach. For a plug-in author this would mean that unless the plug-in needs non-standard widgets, no GUI code would have to be written at all. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
From: Carol Spears <[EMAIL PROTECTED]> >would it be reasonable to have plug-ins that change the drawable to work >on a copy of the drawable? that would take away the need to >differentiate between the two. The point is that things like "Cancel" and "Okay" buttons are only relevant to a subset of plug-ins, and those are the ones I'm talking about. -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Mon, Mar 29, 2004 at 10:09:37AM -0800, William Skaggs wrote: > > First, though, a little terminology. As I will use the terms, a > "plug-in" is an external executable that interacts with the Gimp core > via the plug-in mechanism. A "filter" is a plug-in that changes a > drawable in some way. Only some plug-ins are filters -- there are > others that read or write specific file formats, set the foreground > color, interact with the PDB, etc. The plan I will describe here > really only applies to filters -- other types of plug-ins may well > call for other types of interface. > would it be reasonable to have plug-ins that change the drawable to work on a copy of the drawable? that would take away the need to differentiate between the two. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi,
I have been thinking about how to improve the consistency of the
user interface for plug-ins, and have come up with a tentative plan
and the mechanism for implementing it, which I will outline here to
see if people think it is reasonable and workable.
First, though, a little terminology. As I will use the terms, a
"plug-in" is an external executable that interacts with the Gimp core
via the plug-in mechanism. A "filter" is a plug-in that changes a
drawable in some way. Only some plug-ins are filters -- there are
others that read or write specific file formats, set the foreground
color, interact with the PDB, etc. The plan I will describe here
really only applies to filters -- other types of plug-ins may well
call for other types of interface.
There are two basic principles behind the plan. 1) Every filter
should produce a dialog when called interactively. At the moment,
some just do their thing without showing any dialog: this is bad. 2)
The dialog should contain three standard buttons, "About", "Cancel",
and "Okay". The "Cancel" and "Okay" buttons should do the obvious
things; the "About" button should pop up a dialog that shows the
"blurb" and "help" strings for the filter, as entered into the PDB.
It should also have a "Help" button that invokes the help browser with
the main help page for the filter.
I have written a set of functions that make it easy to implement
these things in a plug-in. Three of the functions are public:
gimp_filter_dialog_info_new(), gimp_filter_dialog_new(), and
gimp_filter_dialog_run(). They would typically be used in the
following way:
{
GimpFilterDialogInfo *info;
info = gimp_filter_dialog_info_new (procname, /* PDB identifier */
_("Filter"), /* for title bar */
help_id,
help_func);
dialog = gimp_filter_dialog_new (info);
/*
* Set up the dialog (which is a GimpDialog) by
* packing its VBox with controls.
*/
run = gimp_filter_dialog_run (info); /* main loop */
/* if run=TRUE, run the filter */
}
Note that this is very nearly the way things are done in a standard
plug-in now, so converting one to the new system is about a
five-minute job. (I've done it to a few to test.) The advantage,
then, is that with a type of dialog specifically for plug-ins (as
opposed to GimpDialog, which is used for many purposes), changes can
be made in one spot that affect the appearance of all filter-plug-ins
without having messy side-effects. For example, in my code the
"About" button has a simple text label -- replacing it with a stock
item would be a one-line change.
As I said, I have written and tested code to do these things (two
files, gimpfilterdialog.c and gimpfilterdialog.h, which would go into
libgimpwidgets). I'll be happy to supply it on request, via Bugzilla,
mailing list, or email. I would include it here, except that I would
be pushing tolerances for mailing list email length.
This stuff is of course not suitable for 2.0. My thought is to submit
it for 2.1 after branching if people think it is a good idea.
Best,
-- Bill
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Joao S. O. Bueno schrieb: Hi, On Sunday 28 March 2004 16:47, Sven Neumann wrote: I have also one other improvement I think I could work on, and this would be great, so I might even postpone the above PDB stuff: Postscript saving plug-in. Actually, I have a similar list of things I believe I can implement in it, more or less in this order: - Add a "save one layer per page" option, with metadata on postscript comments to allow reloading without loosing layer Info. you don't want to loose layer info. But you should notice that you will loose image data. The PostScript files are rasterized by GhostScript and this will not give you back the original image. I would not recommend to use PostScript for information storage. Only if you work around ghostscript and use your own routines to get everything back (including raster data). An option "load layer per page" would be quite useful. - Add a rough (or maybe full) transparency support for postscript saving - Allow to save vectors as postscript paths, along with meta data to get them back on GIMP Same as above. Isn't there a format that supports saving paths ? How about XCF ? --Peter - Allow to save GIMP unstransformed text layers as postscript stroken paths - this could allow a 150dpi image with text on it to get press-ready, without great loss of information,as text would be vectorial. - Add color correction to PS save. This last one would be the greatest of them all, but also, the one I know less about how would be done. I imagine that with online help of whoever will be working on the color-profiles functionality (either on #gimp, or by e-mail), I can manage the postscript-side of it. Also, to be added to the list of what I think is feasible: - Add Vector Layers functionality. (Simon, you there? ) And I would happily add them to the postscript save. :-) Regards, JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Peter Kirchgessner http://www.kirchgessner.net mailto:[EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > My idea of saving text as curves would be: - having implemented a > "save vectors to postscript curves" (which I had done in python-fu > for gimp 1.2), create a "vector from text" thouhgh the PDB, and them > use this vector to save as postscript curves, filling with the text > layer's color (which also need to come from the PDB API) Hmm, so you want to save text as curves? That's of course a different issue, you basically don't need a text PDB API then. All you need is the vectors API. > You made no comments on the vector layers api, do you think they are > feasible into 2.2? Actually we only planned to add an API to create vectors through the PDB. Basically a replacement of the current API that doesn't support all the new things that vectors can do compared to paths in 1.2. What Simon and me had in mind here is an API similar to what is used in PS and SVG. Such an API already exists internally: http://developer.gimp.org/api/2.0/app/GimpBezierStroke.html What you will need however is an API to query the vectors objects. That API should probably be similar to the API proposed above and I don't think that adding it would be overly difficult. Saven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Monday 29 March 2004 07:21, Sven Neumann wrote: > Hi, Hm,, I talk that much about postscript, because I have learned it, as it is supposed to be "human writable". PDF however is a neat subset, and although I know little of it, I suppose I could handle PDF saving with ADOBE docs - that is all of the bellow could be done for both PS and PDF. In the meantime, however, we will need the PDB API's for both vector and Text layers, I think them I should address these first. I will browse through the text-core today, to start to get a feeling of how it works. My idea of saving text as curves would be: - having implemented a "save vectors to postscript curves" (which I had done in python-fu for gimp 1.2), create a "vector from text" thouhgh the PDB, and them use this vector to save as postscript curves, filling with the text layer's color (which also need to come from the PDB API) Such a plug-in would need to know if a text-layer had been modified after it was stroke. Is there a flag for it already on the core? I understand that if there was no prevision for it, it may be hard to implement. /me switches to the GIMP, creates text layer, paints on it, and tries to edit the text, thus answering his own question. Good, it is there. We will need a PDB proc. for that too. You made no comments on the vector layers api, do you think they are feasible into 2.2? > "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > > I have also one other improvement I think I could work on, and this > > would be great, so I might even postpone the above PDB stuff: > > Postscript saving plug-in. > > > > Actually, I have a similar list of things I believe I can implement in > > it, more or less in this order: > > - Add a "save one layer per page" option, with metadata on postscript > > comments to allow reloading without loosing layer Info. > > - Add a rough (or maybe full) transparency support for postscript > > saving > > - Allow to save vectors as postscript paths, along with meta data to > > get them back on GIMP > > - Allow to save GIMP unstransformed text layers as postscript stroken > > paths - this could allow a 150dpi image with text on it to get > > press-ready, without great loss of information,as text would be > > vectorial. > > - Add color correction to PS save. > > I had a similar idea but I think that PDF output would probably be > more useful. For the text layer part if may even be easier because you > could use PangoPDF. But then this is a rather large task and it > depends on the vectors and text PDB API. Actually it goes even further. > Your plug-in would want to query the text and vector objects in the > core and at the moment there's no way to do that and not even a > proposal how such an API could look like. On the other hand, such a > plug-in would be very useful and the PDB APIs that it needs might pave > the way for lots of other neat things. Lately I've been asked to help > with a plug-in that would allow to create avg description files (see > http://www.libavg.de/) from within GIMP and such a plug-in would also > need access to the text layer properties. > > > Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > I have also one other improvement I think I could work on, and this > would be great, so I might even postpone the above PDB stuff: > Postscript saving plug-in. > > Actually, I have a similar list of things I believe I can implement in > it, more or less in this order: > - Add a "save one layer per page" option, with metadata on postscript > comments to allow reloading without loosing layer Info. > - Add a rough (or maybe full) transparency support for postscript > saving > - Allow to save vectors as postscript paths, along with meta data to > get them back on GIMP > - Allow to save GIMP unstransformed text layers as postscript stroken > paths - this could allow a 150dpi image with text on it to get > press-ready, without great loss of information,as text would be > vectorial. > - Add color correction to PS save. I had a similar idea but I think that PDF output would probably be more useful. For the text layer part if may even be easier because you could use PangoPDF. But then this is a rather large task and it depends on the vectors and text PDB API. Actually it goes even further. Your plug-in would want to query the text and vector objects in the core and at the moment there's no way to do that and not even a proposal how such an API could look like. On the other hand, such a plug-in would be very useful and the PDB APIs that it needs might pave the way for lots of other neat things. Lately I've been asked to help with a plug-in that would allow to create avg description files (see http://www.libavg.de/) from within GIMP and such a plug-in would also need access to the text layer properties. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, On Sunday 28 March 2004 16:47, Sven Neumann wrote: > Hi, > > I suggested that we make a list of changes for 2.2, so I sat down > and tried to come up with such a list. This list is not meant as > the list of things that need to go into 2.2 but it's a list of > things that could go into 2.2. A prerequisite for each item is that > someone volunteers to work on it. And of course the list is by no > means complete. Please send a mail if you want to see items added. > > Well, just by reading this list, I see I have a lot to learn from the core yet. But I do have a choice from the list bellow I like to address: > - vectors PDB API > http://bugzilla.gnome.org/show_bug.cgi?id=129598 > (this would allow to move the SVG path import from the core to a >plug-in) If Simon is not picking it right now, I could check with him on what is needed, and go for it. Just in case I can do it, and the Text Tool PDB ain ready, I'd like to go for it. I have also one other improvement I think I could work on, and this would be great, so I might even postpone the above PDB stuff: Postscript saving plug-in. Actually, I have a similar list of things I believe I can implement in it, more or less in this order: - Add a "save one layer per page" option, with metadata on postscript comments to allow reloading without loosing layer Info. - Add a rough (or maybe full) transparency support for postscript saving - Allow to save vectors as postscript paths, along with meta data to get them back on GIMP - Allow to save GIMP unstransformed text layers as postscript stroken paths - this could allow a 150dpi image with text on it to get press-ready, without great loss of information,as text would be vectorial. - Add color correction to PS save. This last one would be the greatest of them all, but also, the one I know less about how would be done. I imagine that with online help of whoever will be working on the color-profiles functionality (either on #gimp, or by e-mail), I can manage the postscript-side of it. Also, to be added to the list of what I think is feasible: - Add Vector Layers functionality. (Simon, you there? ) And I would happily add them to the postscript save. :-) Regards, JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
From: Sven Neumann <[EMAIL PROTECTED]> Date: 28 Mar 2004 21:47:52 +0200 Hi, I suggested that we make a list of changes for 2.2, so I sat down and tried to come up with such a list. This list is not meant as the list of things that need to go into 2.2 but it's a list of things that could go into 2.2. A prerequisite for each item is that someone volunteers to work on it. And of course the list is by no means complete. Please send a mail if you want to see items added. - port print plug-in to newer libgimpprint http://bugzilla.gnome.org/show_bug.cgi?id=127957 I just checked in the final major API changes to the Gimp-Print mainline. This was one of the largest single commits in the history of the project (much bigger than the initial commit, which was far from the most extensive anyway); the only other one of this magnitude was the change to the parameters early in 4.3, which was done over more time. The only significant Critical features not in yet are piecewise curves and ink limiting (which is partially in). Ink limiting will have no effect on the user interface or plugin, since it will simply be another parameter or few, but piecewise curves will have some effect on the user interface code when and if we do it. However, this change should be less pervasive, and we can probably do it in a compatible fashion such that a synchronous change wouldn't be needed. I'm hoping to do 5.0 alpha 2 in the next week or so to get wider exposure for the new API and the feature enhancements that go along with it. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, I suggested that we make a list of changes for 2.2, so I sat down and tried to come up with such a list. This list is not meant as the list of things that need to go into 2.2 but it's a list of things that could go into 2.2. A prerequisite for each item is that someone volunteers to work on it. And of course the list is by no means complete. Please send a mail if you want to see items added. - GtkFileChooser (Mitch has patches for this) - GtkAction (this could include doing a menu editor) (perhaps also address http://bugzilla.gnome.org/show_bug.cgi?id=5673) - customizable Toolbox http://bugzilla.gnome.org/show_bug.cgi?id=105764 - text tool improvements http://bugzilla.gnome.org/show_bug.cgi?id=122707 http://bugzilla.gnome.org/show_bug.cgi?id=125144 http://bugzilla.gnome.org/show_bug.cgi?id=102822 - new text PDB API http://bugzilla.gnome.org/show_bug.cgi?id=124394 - improve font selection http://bugzilla.gnome.org/show_bug.cgi?id=137624 - vectors PDB API http://bugzilla.gnome.org/show_bug.cgi?id=129598 (this would allow to move the SVG path import from the core to a plug-in) - add a progessbar API that allows to embed plug-in progress bars in other dialogs (file selector, plug-in dialogs ...) http://bugzilla.gnome.org/show_bug.cgi?id=6010 - support the Recent File Storage Specification http://bugzilla.gnome.org/show_bug.cgi?id=131206 (this is a matter of implementing a well-defined spec) - Provide a way to manage thumbnails http://bugzilla.gnome.org/show_bug.cgi?id=137268 (could be a standalone tool, got some code for it already) - option to edit files from cmd line sequentially http://bugzilla.gnome.org/show_bug.cgi?id=110242 (could have a look at how cinepaint does this) - improve error reporting http://bugzilla.gnome.org/show_bug.cgi?id=92604 - port print plug-in to newer libgimpprint http://bugzilla.gnome.org/show_bug.cgi?id=127957 - add a preview widget for plug-ins http://bugzilla.gnome.org/show_bug.cgi?id=52374 - Use pixbuf instead of tempbuf for preview rendering in the core. Some GimpViewables convert pixbufs to TempBuf. This could be improved. - Improve usability of display filter modules. Save filter configuration in images. Allow to have default filters. - Check if the TIFF plug-in from Kai-Uwe could replace our current TIFF plug-in. - Improve color management. Support embedded color profiles, add a display filter that uses monitor profiles. Allow display filter modules to access image and gimp parasites. - Finish gimp-console, the command-line GIMP app that is almost working already. Perhaps add a nice command-line interface for it. If you query bugzilla and include enhancement requests, you will find a lot more. I only included things that I think would be nice to have and that can be implemented during a short release cycle. So please, let us know if you want to work on one of these or if you have other plans for 2.2. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Fri, Mar 26, 2004 at 11:06:46AM -0600, Kelly Martin wrote: > > That's my two cents on the matter, at least. > can you give a nickels worth sometime? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Fri, Mar 26, 2004 at 04:52:29PM +0100, Dave Neary wrote: > Hi, > > Sven Neumann wrote: > >Helps for what? If libpdb is not our PDB redesign, what is it then? > > What is it? Rock? > > I may be misunderstanding what it is, but I understood that libpdb was an > extra > layer between the existing (unchanged) PDB and plug-ins which allowed things > like named parameters, and sockets rather than shm for plug-in/core > communication. Looking at the code, there's no wrapping layer at all, it's pretty much a wholesale replacement. > Aside from those 2 things, I know nothing about it except that someone is > actively working on it, and that person was under the impression that it was > scheduled for inclusion in 2.2. AFAIK, Nathan made libpdb primarily so common PDB functionality could be shared between projects, and gimp isn't the sole customer. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Dave Neary wrote: I could be convinced that having a release in 3 months is the right thing (I am under no illusions though - if I disagree with it, that won't necessarily influence the eventual decision). It would depend on the feature lists we compile over the next few days/weeks. I think a goal of a 2.2 release in three months is a good one, which means the feature list that gets accumulated should have anything that can't be implemented in that time removed from it. If that makes for too few features, then either add one or two more. I wouldn't push the release date back much more than that. That probably means that a feature freeze in one to two months is appropriate. There's a lot of little stuff that people have been holding off on; surely there's enough of those to fill the next three months. Save the Big Stuff for 2.4/3.0. That's my two cents on the matter, at least. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi William, William Skaggs wrote: If you plan for three months, it will take nine months, so you should plan for three months. If you plan for six months it will take over a year. Feynman's Law: Everything takes twice as long as you expect it will, even when you take into account Feynman's Law. The problem is that if you go way over schedule (that is, if we say 3 months, and we're still not at 2.2 in 6 to 8 months time), you end up moving to a feature-based thing. People start working on things which hadn't been planned and you end up with so much schedule creep that the old schedule is eventually ignored and forgotten (I think in 1.3 this happened sometime at the start of 2002, although I wouldn't be able to put my finger on a particular event). At which point you need to come up with a new plan. I could be convinced that having a release in 3 months is the right thing (I am under no illusions though - if I disagree with it, that won't necessarily influence the eventual decision). It would depend on the feature lists we compile over the next few days/weeks. But I would be worried that if we set off on too short a cycle that people will not start features which won't be done in 6 weeks. And we might only end up with 2 or 3 people working on 2.1.x, which would be a shame given that we are getting more & more people contributing code at the moment. I'm agreed that if we have features without someone to write them that they shouldn't hold up a 2.2 release, though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Joao S. O. Bueno wrote: would it be too troublesome to call this release that will just finish things that have started, as 2.0.X series, instead of a 2.2 ? IMHO, that would be fine - but the "just finish things" won't just finish things, it will add smallish features too. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
>> Would it be too troublesome to call this release that will just >> finish things that have started, as 2.0.X series, instead of a 2.2 ? > >Yes. Only bug-fixes in a stable release series. And for a more practical reason, it can't be done without branching, and you don't want to call both branches 2.0.X. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
If you plan for three months, it will take nine months, so you should plan for three months. If you plan for six months it will take over a year. Feynman's Law: Everything takes twice as long as you expect it will, even when you take into account Feynman's Law. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: Helps for what? If libpdb is not our PDB redesign, what is it then? What is it? Rock? I may be misunderstanding what it is, but I understood that libpdb was an extra layer between the existing (unchanged) PDB and plug-ins which allowed things like named parameters, and sockets rather than shm for plug-in/core communication. Aside from those 2 things, I know nothing about it except that someone is actively working on it, and that person was under the impression that it was scheduled for inclusion in 2.2. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I think that if it's done, and works correctly, and is useful, we > should use it. Useful for what? What do you think libpdb is? We don't need to replace our working PDB code with other code that does the same thing. Unless I am completely wrong, what we are talking about here is a redesign of the way that plug-ins talk with the GIMP core. That's something that should be well done and it absolutely needs a stable API that isn't changed with the next release. Otherwise noone will ever port their plug-ins to it. > The PDB redesign is vaporware, and might not even be done before > gegl gets integrated. If libpdb helps in the meantime, I'm all for it. Helps for what? If libpdb is not our PDB redesign, what is it then? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > Would it be too troublesome to call this release that will just > finish things that have started, as 2.0.X series, instead of a 2.2 ? Yes. Only bug-fixes in a stable release series. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi all, Sven, would it be too troublesome to call this release that will just finish things that have started, as 2.0.X series, instead of a 2.2 ? JS -><- On Thursday 25 March 2004 14:20, Sven Neumann wrote: > Hi, > > Dave Neary <[EMAIL PROTECTED]> writes: > > > - Do a 2.2 release in about three months. > > > > I think that's unrealistically short at this stage. There are people > > who have said that they want to do some concrete and long-standing > > TODO items, and 6 weeks to 2 months is not enough time to get most > > of those done and debugged properly. > > IMHO we should rather try to finish what has started already and get > these new features to our users quickly. 2 months should be sufficient > to get that done. Whatever cannot be achieved in this time will have > to wait for the next release then (which could be by the end of the > year). >(...SNIP...) > Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Manish Singh wrote: I don't think libpdb should land in 2.2, since I don't think we'll be able to nail down everything we need in a new PDB api in the timeframe, and it'd be kind of silly to land a brand new core API that'll only live for one release. I think that if it's done, and works correctly, and is useful, we should use it. I think we should avoid the temptation to think 1 release ahead - you say that it'll only live for 1 release, but that release might be around for a long time. At one stage there were similar things said early in the 1.3 release cycle (the effort on thing X wouldn't be worth it because it would be superceded by gegl anyway) - I don't recall exactly the features in question, but layer grouping comes to mind as one of the things suggested a couple of years back that is, imho, doable reasonably nicely with the current core. The PDB redesign is vaporware, and might not even be done before gegl gets integrated. If libpdb helps in the meantime, I'm all for it. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Thu, Mar 25, 2004 at 06:20:14PM +0100, Sven Neumann wrote: > > Dave Neary <[EMAIL PROTECTED]> writes: > > > > - Do a 2.2 release in about three months. > > > > I think that's unrealistically short at this stage. There are people > > who have said that they want to do some concrete and long-standing > > TODO items, and 6 weeks to 2 months is not enough time to get most > > of those done and debugged properly. > > IMHO we should rather try to finish what has started already and get > these new features to our users quickly. 2 months should be sufficient > to get that done. Whatever cannot be achieved in this time will have > to wait for the next release then (which could be by the end of the > year). I think so too. We should shore up the app and get it to a decent state before we really land the major new break everything features. > > One example of something which would definitely miss 2.2 if we > > release in June is libpdb. > > libpdb is being developed outside of The GIMP. As soon as it is ready > it shouldn't take more than a few days to add it as an optional > plug-in API. You cannot replace the current system with it anyway > since we don't want to break the plug-in API for 2.x. I don't think libpdb should land in 2.2, since I don't think we'll be able to nail down everything we need in a new PDB api in the timeframe, and it'd be kind of silly to land a brand new core API that'll only live for one release. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, before we go into a sinless discussion on whether 3, 6 or 9 months would be an appropriate timeframe for 2.2, I'd like to propose a different approach. Let's collect what features we have in Bugzilla, what features people would like to work on, what time they think they would need and so on. When we have collected that list, it should be possible to come to a reasonable time schedule. What do you think? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, On Thu, 2004-03-25 at 15:55, Sven Neumann wrote: > now that 2.0.0 is released, it's about time to make some plans for the > future. IMHO, we should try to come up with a roadmap that is clear > and detailed for the next months and reasonably vague for the time > thereafter. We can then make precise plans for the time after 2.2 at > GimpCon. Yes, this sounds like a decent approach for the time to come. > - Do a 2.0.1 release in about two weeks. We got a couple of bugs on >the 2.0.1 milestone and I expect more problems to be reported >during the next days. So there's plenty of work to do for 2.0.1. >And IMO we should not branch CVS before 2.0.1 is released. That >will save us some work on merging changes and it means that there's >more pressure to get 2.0.1 out. I agree that we should not branch CVS before after 2.0.1 is released. We need to focus on fixing the worst of the bugs in 2.0.0. Hopefully this will help us avoid the 'lets break everything and work on new features' mania. :) > - Do a 2.2 release in about three months. That seems like a short >release cycle but I think that's exactly what we need at the >moment. There are some unfinished things in 2.0 that could be done >in 2 months of development. And we should be able to release w/o >months of bug-fixing if we only have two months to introduce new >bugs. Of course before we decide to attempt to have 2.2 ready by >GimpCon (June 28 - 30) we should collect a more detailed list of >changes that we would like to see in 2.2. I will spend some time >with Bugzilla and try to prepare such a list... A 3 months release cycle for 2.2 sounds reasonable to me. This will give us enough time to fix the outstanding bug reports and we will have time at GIMPCon2004 to discuss a road map for 2.4. Sincerely, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > > - Do a 2.2 release in about three months. > > I think that's unrealistically short at this stage. There are people > who have said that they want to do some concrete and long-standing > TODO items, and 6 weeks to 2 months is not enough time to get most > of those done and debugged properly. IMHO we should rather try to finish what has started already and get these new features to our users quickly. 2 months should be sufficient to get that done. Whatever cannot be achieved in this time will have to wait for the next release then (which could be by the end of the year). > One example of something which would definitely miss 2.2 if we > release in June is libpdb. libpdb is being developed outside of The GIMP. As soon as it is ready it shouldn't take more than a few days to add it as an optional plug-in API. You cannot replace the current system with it anyway since we don't want to break the plug-in API for 2.x. > and I doubt that a preview widget would make it in either (it would > depend on the amount of free time David Odin has, and how well he > can co-ordinate with Ernst). Same goes here. If we can settle on a design and an API in time, then it shouldn't be a problem to get the code in. If not, it will have to wait till 2.4. > Setting up a 3 month release cycle sets us up for GTK+ 2.4 > migration, committing outstanding features with patches attached, > and maybe re-arranging the menus again. I don't see any major > features going in in such a short cycle. Exactly. It would mean that we would be able to deliver a GIMP2 that uses the new GTK+ file-selector, we could improve our menus by using GtkAction and we could finish the outstanding text and path tool issues. If libpdb, the preview widget or any other features are ready in time, they can go in as well. Sounds like a good plan to me. > Plus one of the objectives of 2.2 was to have complete coverage for > docs - that seems unrealistic for June. What docs are you refering to? > I would prefer to see us set ourselves up for a 6 month cycle and > stick to it, rather than a 3 month cycle that we know is going to > end up as 6 months in the end. If you are going to put a revamped PDB, the preview widget and a couple more things on our feature list, then you risk not to be able to stick to the 6 month cycle. For this reason, I'd rather like to go for a very short release cycle this time. Let's see how this works out and it would give us the chance to discuss new stuff on GimpCon. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: now that 2.0.0 is released, it's about time to make some plans for the future. IMHO, we should try to come up with a roadmap that is clear and detailed for the next months and reasonably vague for the time thereafter. We can then make precise plans for the time after 2.2 at GimpCon. I think we should have a good chat now about post-2.2, since the work of others in the meantime (Dan and Calvin) will depend on that plan. But that can be sufficiently vague as "Dan's plan sounds sane, we'll go that way", and set up 3 or 4 major milestones after 2.2 when we can do stable releases. - Do a 2.0.1 release in about two weeks. And IMO we should not branch CVS before 2.0.1 is released. Agreed. - Do a 2.2 release in about three months. I think that's unrealistically short at this stage. There are people who have said that they want to do some concrete and long-standing TODO items, and 6 weeks to 2 months is not enough time to get most of those done and debugged properly. One example of something which would definitely miss 2.2 if we release in June is libpdb, and I doubt that a preview widget would make it in either (it would depend on the amount of free time David Odin has, and how well he can co-ordinate with Ernst). I wouldn't be able to commit to getting the pretty small feature I said I'd do in that time scale either, particularly with gimpcon preparations underway. Setting up a 3 month release cycle sets us up for GTK+ 2.4 migration, committing outstanding features with patches attached, and maybe re-arranging the menus again. I don't see any major features going in in such a short cycle. Plus one of the objectives of 2.2 was to have complete coverage for docs - that seems unrealistic for June. I would prefer to see us set ourselves up for a 6 month cycle and stick to it, rather than a 3 month cycle that we know is going to end up as 6 months in the end. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] making plans
Hi, now that 2.0.0 is released, it's about time to make some plans for the future. IMHO, we should try to come up with a roadmap that is clear and detailed for the next months and reasonably vague for the time thereafter. We can then make precise plans for the time after 2.2 at GimpCon. I am going to propose a very short-term plan here. Feel free to comment on it and don't be afraid to use "fighting words". Just tell me that my plan is wrong if you think that's the case. - Do a 2.0.1 release in about two weeks. We got a couple of bugs on the 2.0.1 milestone and I expect more problems to be reported during the next days. So there's plenty of work to do for 2.0.1. And IMO we should not branch CVS before 2.0.1 is released. That will save us some work on merging changes and it means that there's more pressure to get 2.0.1 out. - Do a 2.2 release in about three months. That seems like a short release cycle but I think that's exactly what we need at the moment. There are some unfinished things in 2.0 that could be done in 2 months of development. And we should be able to release w/o months of bug-fixing if we only have two months to introduce new bugs. Of course before we decide to attempt to have 2.2 ready by GimpCon (June 28 - 30) we should collect a more detailed list of changes that we would like to see in 2.2. I will spend some time with Bugzilla and try to prepare such a list... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
