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.

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

On Thu, Mar 25, 2004 at 06:20:14PM +0100, Sven Neumann wrote:

Dave Neary 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

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.

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 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

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.

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

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

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.

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 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

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

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

From: Sven Neumann
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.

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 ->

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" 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

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
Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

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

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

From: Carol Spears

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

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

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 ---

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

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

weskaggs@primate.ucdavis.edu (2004-03-29 at 1218.49 -0800):

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.

a) Menu entries have a rule about "...". Only those that request extra interaction must have the dots. Non interactive things have no dots.

b) Then make it disabled.

c) Maybe over menu? Maybe in a global place? This issue is going to happen with any menu entry that pops nothing, be it a filter or whatever. Should everything start poping dialogs now?

GSR

a) Menu entries have a rule about "...". Only those that request extra interaction must have the dots. Non interactive things have no dots.

Interesting. I just automatically assumed that the dots meant that the name was truncated, and never paid attention to them again.

c) Maybe over menu? Maybe in a global place? This issue is going to happen with any menu entry that pops nothing, be it a filter or whatever. Should everything start poping dialogs now?

Well, no. It's reasonably clear to me that "add alpha channel" should not pop a dialog :-). But you're right, there is certainly an issue of how to invoke help for something that does not present any interface beyond a menu entry.

Best,
-- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

On Mon, 2004-03-29 at 23:53, William Skaggs wrote:

a) Menu entries have a rule about "...". Only those that request extra interaction must have the dots. Non interactive things have no dots.

Please include a line which states who you are quoting.

./Brix

From: Sven Neumann

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

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.

sven@gimp.org (2004-03-31 at 1323.49 +0200):

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.

Duplicate would be a file op (cp) and a refresh, no? And new would be just creating a new image and immediately set the path (it should be like faking the load of an image).

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.

From my point of view, it would be just shortcuts not duplication. At

most an extra feature, so DnDing drawables to pattern selector (like you can do with toolbox) saves it as pattern directly.

GSR

Hi,

Sven Neumann wrote:

Dave Neary 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.

sven@gimp.org (2004-03-31 at 1637.04 +0200):

You will run into problems as soon as people start to use multiple layers, channels, layer masks and the like on the pattern image.

As now you can have RGBA patterns, merging all layers, cropped to image size, should be enough. Or do I miss any detail there?

GSR

Sven Neumann wrote:

Hi,

Dave Neary 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.

[sorry for the late reply - I am just wading through pending replys]

Joao S. O. Bueno (gwidion@mpc.com.br) 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

V St 31. 03. 2004 v 20:08 +0200 píše Sven Neumann:

Hi,

Dave Neary 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

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?