Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.

[Nathan Carl Summers]

On Tue, 7 Sep 2004, Alan Horkan wrote:

>
> > Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit
> > (ie. with translations) if it isn't fully ready yet by exposing it to
> > more users but what is in the best interest of GIMP and its users?
>
> I know I'd much prefer another stable release with Script-Fu in it first,
> but that is my entirely subjective opinion.
>
> I fear having to rewrite some of my scripts having already written gimp
> 1.2 and gimp 2.0 versions.  Compatibility is important to me, even if only
> small changes are necessary it causes problems.  I dont relish the
> prospect of new scripts I write not being usable by people who still have
> gimp 2.0.x or even 1.2, users are still requesting backports of scripts to
> 1.2.  It may seem like Gimp 2 has been available for ages, particularly
> for those who have been using gimp 1.3 but Gimp 2.0 was only released this
> summer.
>
> That said I'll certainly hope to instal Tiny-Fu alongside Script-Fu and
> sort things out after 2.2.
>

Given that 2.2 is supposed to be api-compatible with 2.0, I think that
should extend to the scheme extension as well.

Also, I'll again repeat my objection to the idea that the scheme extension
be packaged separately from GIMP.  We have always had Script-Fu as a
universal -- the one scripting system you could count on for all gimp
installations on every platform.  It would be quite a shame if that was no
longer the case.

Nathan

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] The way forward for Color Management

[Nathan Carl Summers]

On Fri, 13 Aug 2004, Alastair M. Robinson wrote:

>  From my point of view, I think it's important to tweak the display
> module system so that the display modules can fetch parasites on a
> per-image basis (rather than just global ones) - this will let me
> implement the features I want in the display module.
>
> This conflicts slightly with the goal of applying a filter to the colour
> selectors - but this should be solved easily enough with a NULL argument.

Wait -- the color selectors need to be filtered on a per-image basis as
well.  What if you are working in very different colorspaces for two
images?  It does you no good to select a color in the gamut of one image
if you really wanted to select for the other one -- that color might not
even be in the gamut of the the other image!

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] preparing GIMP 2.2

[Nathan Carl Summers]

> * Add a new section in the preferences dialog (or add to the existing
> Display section) the following options:
>   *   Enable/disable colour management  (Do we allow this to be
> enabled/disabled on a per-image basis?  The filter will need access to
> image parasites for that.)

I can't honestly think of a good reason to disable color management, but
couldn't we just have an option for "this monitor's colorspace" instead of
having two choice to choose from?

On second thought, I can think of a reason to disable color management,
but I still think that it wouldn't be a bad idea to just make "this
monitor's colorspace" one of the options.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] "Extrude"-filter and lots of triangles

[Nathan Carl Summers]

On Mon, 2 Aug 2004, Markus Triska wrote:

> I'm for now using a quick and terrible hack to fill the triangles (see
> attached source if you are curious) and want to ask:  Which method do
> you recommend to fill lots of triangles from within a plug-in? Is there
> a (fast?) Gimp function for this that I can use, maybe capable of
> anti-aliasing?

Well, the quick-and-dirty way of doing it would be to select a triangle
shape and use the GIMP's fill function. :)

I'm afraid I don't see why there is a lack of locality here: each triangle
to be filled indeed has locality.  Of course, if the triangle is
sufficiently small, only one tile needs to be involved.

Perhaps what you are really saying is that the tile cache needs to be
really large to be effective because there is not much between-triangle
locality.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Is an incompatible change to generated brushes acceptable?

[Nathan Carl Summers]

On Mon, 2 Aug 2004, Simon Budig wrote:

> Hi all.
>
> I am currently working on some tweaks to the generated brushes (the
> brushes you can configure interactively). In Gimp CVS you can
> generate brushes like these:
>http://www.home.unix-ag.org/simon/files/generated-brushes.png
>
> Note, that currently the new functionality does not affect existing
> generated brushes. However, when I fiddeled with this stuff I got the
> impression, that the hardness-parameter should be a bit more extendable
> to the soft side of the brush - IMHO hardness 0.0 is not yet soft
> enough.
>
> I have a patch sitting here, that makes more soft brushes possible, but
> since this patch still maps the range from 0 to 1 the hardness for
> existing generated brushes would effectively be reduced, i.e. existing
> brushes will look softer when loaded with the next release of the GIMP.
>
> Do you think this is acceptable? Note that the current hardness could
> be reached easily by dragging the slider a bit upwards again.

Is it possible to redo your logic so that the the old hardness scale is
used, but it's possible to have negative hardness?  Alternatively, we
could use a fileformat versioning system to keep backwards compatibilty.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: [Gimp-docs] Wording in German: Toolbox

[Nathan Carl Summers]

Roman Joost <[EMAIL PROTECTED]> writes:
> This mail is for "translating" the Toolbox into German. I wasn't sure
> how to translate the Toolbox to German for the manual. But please, hold
> your breath and let me explain why.
>
> So, what do you guys think: "Werkzeugfenster" or "Werkzeugkasten"?

I don't speak German, but Werkzeugfenster sounds cooler than
Werkzeugkasten.  In fact, I wouldn't mind a "Werkzeugfenster" T-shirt.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] compose - decompose nitpicking

[Nathan Carl Summers]

On 21 Jul 2004, Sven Neumann wrote:
> Dave Neary <[EMAIL PROTECTED]> writes:
> > I think it would be even more useful to set the compose mode to the
> > last used decompose mode, rather than the last used compose mode (if
> > you get my meaning).
>
> Well, this is doable but it would require closer interaction between
> the two plug-ins. compose could read the last-used-parameters set by
> decompose. A prerequisite for this would be to let the two plug-ins
> share a common header.

Why not put a parasite on the images created by decompose saying what
mode the image was decomposed with, and which layers (or images,
depending on the options when you decomposed) corrispond to which
channels?  Then there would be no need for guessing, and you could work
with more than one decomposed image (or layer, for that matter) at once.
You would still want to allow the user to switch to some other layer for
the recompose, of course, but it would be nice to default to the way it
was decomposed.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] removing gimp toys, second opinion please?

[Nathan Carl Summers]

On Wed, 21 Jul 2004, Alan Horkan wrote:

>
> http://bugzilla.gnome.org/show_bug.cgi?id=148027
>
> Given that some less used file formats have been removed in recently
> releases on the basis of less code to maintain and less general clutter I
> suggested that the old Toys be removed from the Gimp for version 2.2.  To
> my surprise Mitch rejected the idea (without much explanation), Adam who
> wrote the toys didn't seem to think it was a terrible idea so I'm asking
> onlist to try and get a second opinion.

If Excel had a flight simulator, Gimp can have a few toys.  :)

> If toys like Gee-Zoom were built on top of a useful plugin (eg some sort
> of a kaleidescope plugin for example) I wouldn't even be asking but they
> toy are not useful at all sso users are just presented with eye-candy and
> left wondering how they can get that effect on their actual image but they
> cannot.

I guess it wouldn't be impossible to have Gee-Zoom render individual
frames as layers, but that ignores the real question, which is why we
don't have some cool effect like gee-slime on the splash screen.

> If you still reject the idea I would ask you to keep the toys in mind when
> it comes to menu reorganisation.  (Wiki is still down otherwise I'd add
> this to the menu reorganisation document we had there).

> The Gnome HIG recommends:
> http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu
> Do not create submenus with fewer than three items, unless the items are
> added dynamically (for example the File->New Tab submenu in
> gnome-terminal).

Fortunately, this is only a recommendation.  Since the toys are rarely
used, I think the uniformity of the Filters menu having just submenus and
the usefullness of having the Toys being explicitly labeled as such is
better overall.  If we broke out all the menus that have only two items, I
don't think the menu would fit on the screen. :)

Besides, the best solution is to add another toy.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Scheme [was Re: [Gimp-developer] OSCon attendance]

[Nathan Carl Summers]

On Thu, 15 Jul 2004, Shlomi Fish wrote:

> Another implementation of Scheme? Aren't the ones in:
>
> http://www.schemers.org/Documents/FAQ/#implementations
>
> enough? Or isn't any of them better suited as a starting point?

Yeah, really, Little Scheme (http://www.crockford.com/javascript/scheme.html)
is all anyone could ever need :)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] OSCon attendance

[Nathan Carl Summers]

On Thu, 15 Jul 2004, David Neary wrote:

> Hi,
>
> Shlomi Fish wrote:
> > On Wednesday 14 July 2004 05:49, Nathan Carl Summers wrote:
> > > Heh, my vote is for Valgrind.  :)
> >
> > Well, valgrind is a very nice and useful tool. (I know becuase I'm also using
> > it extensively) However, I think that perhaps GNU Arch deserves to win
> > because:
>
> And what about the GIMP and its 10 years of being a core Free
> Software application?

Hmm, perhaps you missed the "Heh" at the beginning of my mail.  :)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] OSCon attendance

[Nathan Carl Summers]

On Wed, 7 Jul 2004, Dave Neary wrote:

>
> Hi,
>
> Quoting Carol Spears <[EMAIL PROTECTED]>:
> > On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote:
> > > Part of the results of that is that the GIMP is
> > > one of the candidates for the annual golden award (with a
> > > large cash prize) which will be presented to the winning
> > > project in Portland at the O'Reilly Open Source Conference
> > > in a couple of weeks.
> > awesome.
>
> We're a long way from winning - we're up against the Valgrind
> guy, Pango, VideoLAN, GNU arch and a couple of other really
> good projects. We have a shot, though.

Heh, my vote is for Valgrind.  :)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] easy questions

[Nathan Carl Summers]

On 9 Jul 2004, Sven Neumann wrote:

> Hi,
>
> Tor Lillqvist <[EMAIL PROTECTED]> writes:
>
> > I think what the OP really meant to ask whether GIMP requires a
> > *pre-emptively* multitasking OS. I.e. one that can interrupt a
> > running process that has exceeded its timeslice, even if it doesn't
> > do any system calls (or similar) that gives the kernel a chance to
> > let another process have the CPU. (For instance, Windows 3.1 wasn't
> > able to do that.) As far as I can guess, sure, GIMP might work on
> > such a system...
>
> I don't think GIMP plug-ins would work w/o proper multitasking and
> using GIMP w/o plug-ins doesn't make too much sense.

Hmm, I'm confident you could get it to work on a cooperative multitasking
system.  You might need to add a yield() into the glib loop, but no big
deal.  Of course, it wouldn't work *well*, but then again cooperative
multitasking never does.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Usability test - Results available

[Nathan Carl Summers]

On Mon, 7 Jun 2004, Carol Spears wrote:

> in the united states, there exists a condition where people are being
> educated for a test.  teachers that do not teach the content for the
> test are removed.
>
> i think this sort of thing is being introduced to gimp development.  i
> think it is very good to have the testers show what their purposes were
> before much of the good developers time is taken.  especially when you
> are dealing with such high quality developers and free software.
>
> show what you the human being wanted the gimp to do is a very very good
> question.
>
> i'm questioning the testers use of YOUR time, dude.  relax.

It's easier to improve the user interface of gimp than it is to improve
the gimp interface of all current and potential users. :)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Re: Re: Blur plug-in

[Nathan Carl Summers]

On 7 Jun 2004, Sven Neumann wrote:

> > Well, what would you call a script that just puts a menu entry and
> > calls convolution matrix with a fixed matrix?
>
> I'd call it a waste of resources. Actually such a simple task as
> applying a convolution kernel should probably be done completely in
> the core.

*chuckles*  I agree.

[EMAIL PROTECTED]

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Usability test - Results available

[Nathan Carl Summers]

On Sun, 6 Jun 2004, Ellen Reitmayr wrote:

> > I understand there is quite a learning curve involved with the path
> > tool. On the other hand, compare the tool to what sodipodi implements.
> > They have clear buttons for every action yet completing the same task
> > means kilometers of mouse movement and millions of clicks.
>
> Of course keyboard shortcuts are very important for quick interaction
> with the tool! Nevertheless, not every user is a image manipulation
> expert, possibly does not know the concept of path tools at all. For
> such user, the learning should be facilitated, by supporting the
> exploration with simple shortcuts and the like.

How about buttons for every mode, with a one-key shortcut to switch
between modes?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] plug-in preview widget (another try)

[Nathan Carl Summers]

On 22 May 2004, Sven Neumann wrote:

> So this API would allow you to queue a redraw even after the buffer is
> only halfway written. Of course you would also have to run the main
> loop for the redraw to actually happen. Anyway, I consider this rather
> bad style. IMO, if the preview takes considerable time, then it
> shouldn't be shown halfway done but instead the progress API should be
> used to draw a progress indicator in place of the preview. What do
> others think?

There are a lot of image applications that perodically update the
preview.  In fact, this is essentially what the gimp color balance tools
do -- load a large image and adjust the sliders intermittantly and you can
watch the previews go by.  There are good arguments for incremental
update, and good arguments for a progressbar.  Superimposing a busy cursor
over the preview or replacing it with a progress indicator makes judging
between slight differences in the settings harder.

But I think the real issue here is that slow previews should be computed
in small chunks in an idle handler so as to not impede interactivity.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] None

[Nathan Carl Summers]

On 21 May 2004, Sven Neumann wrote:

> Also I remember that the plan was to move all edge algorithms into
> edge.c in order to obsolete the other plug-ins in the distribution.
> That tasks has probably not been finished before 2.0. Might be a good
> time to do that now.

Come to think of it, it might be benificial to put some generic
convolution code in libgimp or an allied library.  Just a thought.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] None

[Nathan Carl Summers]

On Thu, 20 May 2004, William Skaggs wrote:

>   The motivation for doing this is that it seems to me that the existing
> edge detection plug-ins distributed with Gimp are rather weak in terms
> of output quality

Yeah, I've never been very happy with them.

> (their advantage is that, because they are all just
> 3x3 convolutions with different kernels, they are simple and very
> fast).

Since they are so similar, it might make sense to put them all in one
binary.  If nothing else, that way we could consolidate some menu items.
We would want to continue to export a compatibible PDB API, of course.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] scale image/layer UI analysis

[Nathan Carl Summers]

On 17 May 2004, Sven Neumann wrote:

> Well, we don't have such an entry and I don't see it being added for
> GIMP 2.2. So for now we should IMO keep the changes to the dialog
> purely cosmetic. It will help users to be able to recognize the Scale
> dialog that they have worked with in earlier GIMP versions. Also it
> makes the code changes easier to do in the limited timeframe that is
> left before 2.2 is supposed to be done.
>
> > * The ratio control has been dropped, since it effectively
> > duplicates the % unit.
>
> I'd rather drop the % unit since I don't think that it is intuitive
> enough. From my experience the ratio control is the most used control
> in this dialog and IMO it should stay.

I agree.  Percentage changes are definately common enough to warrant their
own control set.  Percentage isn't even considered a unit outside of the
computer graphics world, so most people wouldn't think of using a units
selector to select a percentage.

Now, if the default on this dialog was always "%", that might work, but it
might cause other problems as well.  Something to test in the lab.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Another new image dialog mockup

[Nathan Carl Summers]

On 7 May 2004, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> > I took a look at the new image dialogs on the list today, and I made
> > a few improvements.  I've posted them at
> >
> > http://wilber.gimp.org/~rock/NewDialogSimple.png and
> > http://wilber.gimp.org/~rock/NewDialogExpanded.png
>

> Sorry, but I fail to see any improvements in these mockups.

Honestly, I would have expected you to reply in a more thoughtful and
constructive manner.  It's obvious that I spent some time (hours,
actually) constructing this mockup, and that I didn't think that my
choices were stupid, yet it really feels like you have dismissed them all
out of hand.  This is exactly the reason GIMP has problems attracting and
retaining new contributors.

I'm sure if you have asked yourself why I was suggesting the things that I
was, what you would have said would have been more reasonable, or at least
more reasoned.  You know that I am not an idiot.  You also know that I
spent three months as an intern in a usability lab, so I'm not completely
clueless about the topic.  If you failed to see any improvements, you also
failed to see why others might think that there are, and to identify the
principles behind which the changes were made.  Not only that, you didn't
give me the opportunity to comment more on them (like I said I would)
before summarily dismissing them.  That is more than bad intellectual
practice; it is bad leadership.

That said, here is my responce to you comments.

> The icon next to the memory size as well as the bold label "Memory
> Required" don't add any value

The icon adds value in two major ways:

1. It provides instantaneous feedback about whether memory usage would be
   above the threshold set in the user preferences.  This is a usability
   win, since it allows the user to immediately fix the mistake instead of
   having to re-open the new image dialog after the warning comes up as a
   separate alert as in http://bugzilla.gnome.org/show_bug.cgi?id=21028
   and the user cancels the image creation.

   Note that it's still a good practice to have the alert box come up as a
   double-check that the user wants to create an overly large image, even
   if they have already been warned here in the new dialog.

2. In its normal usage, the icon immediately identifies the corresponding
   controls as being informational and not directly manipulable.  Since
   the general layout is consistent with other GTK applications, instead
   of distracting the user, it allows the user to immediately recognize
   that in order to get the work done, the user needs to manipulate the
   controls in the other sections of the dialog.  It would take a higher
   level of processing to identify the purpose of the section if the icon
   were not present, or if it were not placed where it was.

> wastes screen estate

Screen estate is really a non-issue here.  Even with the ridiculously
bloated theme that comes with Glade for Windows (yeah, yeah, buy me a T1
so I can do this kind of stuff at home on my beloved Debian Sarge box
instead of at work) the fully-expanded dialog is by default 344 x 521
pixels, which means that it will fit on any display bigger than 640 x 480.
Actually, it will even fit on a 640 x 480 display, since the somewhat
ungraceful behavior of the dialog is to clip the bottom part if there
isn't enough space allocated.  If your display adaptor can't do 640 x 480,
you will have bigger problems with GIMP than just the new image dialog
going off the screen.

Since the new image dialog is unlikely to be open very long, how much it
occludes other windows that are in use is unlikely to be an important
consideration.

Even if real estate was an issue, the mockup in total is 32 pixels longer
than the screenshot you posted yesterday.  The difference in real-estate
usage is not that great, and would probably be mitigated almost completely
if the same theme was used in both screenshots.  I should note that the
screenshot posted yesterday wouldn't fit on a 640 x 480 display, either.

Regardless of whether minimizing screen estate is a priority for the new
image dialog, given the previously discussed utility of the icon, I would
argue that it is a very effective use of real estate.

In fact, I experimented with several layouts for the memory required
portion of the dialog.  Some had icons and some did not.  For those that
did have icons, I experimented with the size of the icon and with hiding
it when the memory requirements did not exceed the threshold.  This layout
was by far the most effective, and that is why it is the one that you see.

It is the most effective because it is a slightly miniaturized version of
the standard HIG information window layout, and so, since it is consistent
with other applications, it is immediately identified by the user for what
it 

[Gimp-developer] Another new image dialog mockup

[Nathan Carl Summers]

I took a look at the new image dialogs on the list today, and I made a few
improvements.  I've posted them at
http://wilber.gimp.org/~rock/NewDialogSimple.png and
http://wilber.gimp.org/~rock/NewDialogExpanded.png

and for the curious, glade files at

http://wilber.gimp.org/~rock/newdialog.glade
http://wilber.gimp.org/~rock/newdialog.gladep

I've tried very hard to make sure they conform to the HIG, which wasn't
easy because there are a few bugs in the HIG where different sections
conflict. I like these mockups a lot and I think you will too.  I don't
have time to say more about them today because I have a train to catch,
but I will say a little more about them tomorrow.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp Menu Reorganization

[Nathan Carl Summers]

On Wed, 5 May 2004, Ellen Reitmayr wrote:

> Hi all,
>
> I just wanted to let you know that I'm still there to attend to some
> usability issues!
>
> Roman and I did some usability testing, and we wrote an article for the
> German Linux User based on the findings. In the meantime, we were both
> quite occupied with working for our offices, but now we started
> translating the results into English and to form some suggestions. We'll
> soon post them on the list!

I look forward to reading that.

> This week, I'll do three or four more tests, and I'll also show them the
> Wiki page to make them think about a good menu structure. It's really a
> great idea to provide a Wiki page for that concern!! I'm also planning
> to do some card sorting to learn more about the user's cognitive
> representation of the menu items and use the page as a basis for that.

Great!  That would be very helpful!

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] status report from the development branch

[Nathan Carl Summers]

On 4 May 2004, Sven Neumann wrote:

> Hi,
>
> "Branko Collin" <[EMAIL PROTECTED]> writes:
>
> > By abbreviating 'Scale Y:' to 'Y:', you are forcing the user to make
> > an extra mental transaction, namely to first read the 'Scale X:'
> > label, which only is partially related to what the 'Scale Y:' control
> > does.
>
> It works the other way around. If Scale is duplicated the user first
> need to recognize that both controls have the same label. She needs to
> read both labels and realize that they are the same. With the current
> layout the group of controls is labelled "Scale" and then there's an
> "X" and an "Y" label for the individual controls.

Fortunately, the human visual system has excellent pattern detection
hardware, and so that's not much of a challenge.  That is why so much gimp
code is written in the style of:

GimpFoo *foo  = gimp_foo_new   (bar);
GimpFoo *quux = gimp_foo_new   (baz);
int  cnt  = gimp_foo_count (foo, bar);

So that similar things are lined up, easing the task of comparing and
contrasting the three lines.  The similar words are actually noticed in
an earlier stage of processing than the actual charactor recognition and
parsing stages.

In fact, it takes less work to use the visual similarity in the
consistantly labeled example as a clue that the two entry controls are
related than it does to use the visual disimilarity in the inconsistantly
labeled example as a clue that the two entry controls are related.



Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Plug-in howto

[Nathan Carl Summers]

On 3 May 2004, Sven Neumann wrote:

> Hi,
>
> Dave Neary <[EMAIL PROTECTED]> writes:
>
> Well, dgo was started to finally give an alternative to this outdated
> sourceforge site, so please consider to help with dgo instead. It's in
> CVS, you have write access, feel free to improve it.

Do you have to run any weird scripts after you make changes, like you did
with the old wgo?  CCed to the list in the intrest of making the answer
public knowledge.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)

[Nathan Carl Summers]

On 3 May 2004, Sven Neumann wrote:

> PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost
> HIG compliant file-new dialog. This is a screenshot from the HEAD
> branch.

Looks fantastic!  I really like the "hideaway" Image Comment section.

Here are just a few minor suggestions that I think would improve the
dialog:

* The "extra title bar" seems to take up a lot more space than it needs.
* Center "Create a New Image" vertically (perhaps horizontally as well)
* Put the size in bytes either flushed right to or directly under the
   "Image Size" label.  Flushed right will probably look better.
* Move the portrait/landscape controls to the right of the template
   dropdown.  Grey them out when no template is selected.
* Merge the two Width and Height entries, or make the second one
   hideaway.  If you make the second one hideaway, make the top one have a
   dropdown units menu, so that you don't have to use the hideaway to
   specify image size in units other than pixel.
* Consider making Resolution hideaway as well.
* Resolution should have its own outdent, just like Image Size does.
* The units dropdowns should be centered vertically between the two entry
   boxes to which they apply.  (It would be better if they were aligned
   horizontally as well, but the presence of the link control in the
   resolution area makes that impractical.)
* Consider putting a GtkVSeparator between the "Image Type" and "Fill
  Type" combo box lists.


These are pretty easy to do; I would make the changes myself except that
the universe seems to be conspiring against me ever having a machine that
I can follow gimp-development work with.  Poor Rockwalrus.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] status report from the development branch

[Nathan Carl Summers]

On 3 May 2004, Sven Neumann wrote:

> Hi,
>
> here's another summary of what's happening in the HEAD branch, what do
> watch out for if you want to join development and where help is
> needed...
>
>
> Mitch has almost finished the port of the menus to GtkUIManager. The
> new code is in use now and seems to work fine. The only remaining
> regression is integration with the help system (pressing F1 on a menu
> item should call the relevant help pages). This is being worked on and
> will soon be reenabled.

Is the ocassionally-suggested right-click-menu for menu items easily
implementable with GtkAction?

> I started to change our dialogs to be more compliant with the GNOME
> HIG. To ease this effort, I've added a new widget called GimpFrame.
> This is a variant of GtkFrame that doesn't draw a frame but instead
> sets a bold title and indents the content of the "frame" as suggested
> by the HIG. I've changed some core dialogs already and I think the
> results look very pleasant.
>
> What remains to be done here is changing all plug-in dialogs. I don't
> plan to do this myself so it would be nice to get some volunteers for
> this task.
>
> It's important that we try to create a consistent dialog layout so
> this job should be well coordinated or done by a single person. Any
> volunteers for this?

While I don't volunteer to be this coordinator, I have created a Bugzilla
entry to help with that process:

http://bugzilla.gnome.org/show_bug.cgi?id=141772

This seems like an excellent opportunity to get new volunteer developers'
feet wet.  We could have a news item blurb about it on wgo that links to a
page on dgo with the proper steps:

1. Identify plug-ins with forbidden dialogs.
2. File a bug-report on bugzilla for each bug, making it block
#141772.  (there should be a mini-tutorial on how to file the bug and make
it block #141772)
3. Identify the offending plug-in dialog code, and fix it.  (Mini-tutorial
here as well)
4. Attach patch to bug report, add keyword PATCH.
5. Bask in glory.

> What I didn't address yet is the fact that the HIG suggests to
> left-align labels of UI controls while we currently consistenly
> right-align labels so that they are close to the control they are
> describing. I am not sure if I can follow the HIG argumentation for
> this. I guess we should create some screenshots or mockups of standard
> GIMP dialogs and discuss this change here before we start to work on
> this.

It seems like the HIG suggests left-alignment for controls whose labels
are roughly equal in length, and right-alignment for dissimilarly-sized
labels.  While this probably does result in the most pleasant appearance,
it's an internationalization nightmare.  I suggest we stick with the Palm
usability guidelines here.  I suggest that the next version of the HIG do
the same.

And while we're talking about the HIG, I still wonder what they were
smoking when they suggested that Gnome lay out all of its buttons opposite
to the way that common sense and every other set of UI guidelines I've
ever read suggests.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp Menu Reorganization

[Nathan Carl Summers]

On Sun, 2 May 2004, David Neary wrote:
> Sven Neumann wrote:
> > Nathan Carl Summers <[EMAIL PROTECTED]> writes:
> > > http://wiki.gimp.org/gimp/GimpMenuReorganization
> >
> > Very nice. I wonder if there's a way to convert between the menu XML
> > files and the Wiki content. That would make it possible to easily try
> > the suggested menu layout.
>
> The forward direction (menu XML to wiki text) should be trivial
> with xslt - the other way would probably be easier with perl or
> something.

That's funny, I think of wiki -> menu as being the forward direction. :)
Turning wiki into XML looks like it should be trivial with Perl.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)

[Nathan Carl Summers]

[EMAIL PROTECTED] accidentally forgot to cc the mailing list.  Forwarded
with his permission.

Date: Mon, 3 May 2004 16:53:32 -0500
From: Seth Burgess <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Nathan Carl Summers <[EMAIL PROTECTED]>
Subject: Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME
Foundation)


Also, from the HIG:

Right-justify the contents of spin boxes, unless the convention in the
user's locale demands otherwise. This is useful in windows where the
user might want to compare two numerical values in the same column of
controls. In this case, ensure the right edges of the relevant
controls are also aligned.

Its just my opinion, but I think showing 3 places of precision past
the decimal for resolution is a bit excessive and I would hazard
rarely adds any useful information.

The alignment of 'Y' seems different than that of 'X' in 'Resolution
X.'  Maybe just an odd font rendering, but it looks to me like
Resolution X has an extra space between X and ':".

I disagree on the vertical separator - I think the absense of such
noise is welcome in the dialog, and its pretty clear without it due to
the bolded headings.

Seth


On Mon, 3 May 2004 13:40:03 -0700 (PDT), Nathan Carl Summers
<[EMAIL PROTECTED]> wrote:
>
> On 3 May 2004, Sven Neumann wrote:
>
> > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost
> > HIG compliant file-new dialog. This is a screenshot from the HEAD
> > branch.
>
> Looks fantastic!  I really like the "hideaway" Image Comment section.
>
> Here are just a few minor suggestions that I think would improve the
> dialog:
>
> * The "extra title bar" seems to take up a lot more space than it needs.
> * Center "Create a New Image" vertically (perhaps horizontally as well)
> * Put the size in bytes either flushed right to or directly under the
>"Image Size" label.  Flushed right will probably look better.
> * Move the portrait/landscape controls to the right of the template
>dropdown.  Grey them out when no template is selected.
> * Merge the two Width and Height entries, or make the second one
>hideaway.  If you make the second one hideaway, make the top one have a
>dropdown units menu, so that you don't have to use the hideaway to
>specify image size in units other than pixel.
> * Consider making Resolution hideaway as well.
> * Resolution should have its own outdent, just like Image Size does.
> * The units dropdowns should be centered vertically between the two entry
>boxes to which they apply.  (It would be better if they were aligned
>horizontally as well, but the presence of the link control in the
>resolution area makes that impractical.)
> * Consider putting a GtkVSeparator between the "Image Type" and "Fill
>   Type" combo box lists.
>
> These are pretty easy to do; I would make the changes myself except that
> the universe seems to be conspiring against me ever having a machine that
> I can follow gimp-development work with.  Poor Rockwalrus.
>
> Rockwalrus
>
> ___
> 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

[Gimp-developer] Re: new file-new dialog (Was: Joining the GNOME Foundation)

[Nathan Carl Summers]

On Mon, 3 May 2004, Seth Burgess wrote:

> Also, from the HIG:
>
> Its just my opinion, but I think showing 3 places of precision past
> the decimal for resolution is a bit excessive and I would hazard
> rarely adds any useful information.

Good point.

> I disagree on the vertical separator - I think the absense of such
> noise is welcome in the dialog, and its pretty clear without it due to
> the bolded headings.

Asthetics is such a fickle thing. :)

I suggest the separator for two reasons:
1) It's not so clear to my eye that the two lists aren't related in some
way.

but more for:

2) It distracts from the fact that the two lists are asymetrical.

I think that if Resolution is outdented, that will be somewhat less of an
issue.

Also, a separator was what was clearly suggested in earlier drafts of the
HIG for this exact kind of case, although that language seems to have been
watered down to something to the effect of add a separator if you need one
in the current version.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Joining the GNOME Foundation

[Nathan Carl Summers]

On Sat, 1 May 2004, David Neary wrote:

> Hi all,
>
> Myself and Dan Rogers will be meeting with someone from the GNOME
> Foundation this week with the intention of having greater
> co-operation with them on things like money.
>
> For the moment, I am working under the supposition that the best
> option available to us is to join the GNOME Foundation.
>
> The alternative is that Dan continue with the work involved in
> creating an independent GIMP Foundation.
>
> The short term effects of doing this would be that we wouldn't
> have any way to accept tax-deductible donations in the US for
> this year, and it is unlikely (given Dan's current availability)
> that the foundation would have cleared up all paperwork issues
> and elected a board before the end of the year.
>
> On the other hand, a partnership with the GNOME Foundation would
> give us federal tax exempt status in the US now. We could probably
> work out an arrangement where contributions made to the GIMP get
> used for GIMP events.
>
> Are there any people opposed to closer ties with the GNOME
> Foundation?

I don't see any reason why we can't do both: work closely with the GNOME
Foundation now, while the GIMP Foundation is getting off the ground, and
then continuing to work with them to some extent once the GIMP Foundation
is a reality.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: new file-new dialog (Was: Joining the GNOME Foundation)

[Nathan Carl Summers]

On 4 May 2004, Sven Neumann wrote:
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> > > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost
> > > HIG compliant file-new dialog. This is a screenshot from the HEAD
> > > branch.
> >
> > Looks fantastic!  I really like the "hideaway" Image Comment section.
> >
> > Here are just a few minor suggestions that I think would improve the
> > dialog:
> >
> > * The "extra title bar" seems to take up a lot more space than it needs.
>
> This dialog is a GimpTemplateEditor packed into a GimpViewableDialog.
> It's GimpViewableDialog that creates the title and the extra space is
> in other GimpViewableDialogs used to display the name of the viewable
> (which could for example be an image or a layer). We could of course
> change GimpViewableDialog to show a smaller title when no name is set
> but I think consistency makes more sense here. Not sure though, what
> do others think?

It looks seems a little awkward the way it currently is here.  There are
probably several ways to make it look nicer.  Maybe one of the graphic
artists could give more productive suggestions.

> > * Center "Create a New Image" vertically (perhaps horizontally as well)
>
> This also needs to be reviewed with respect to other dialogs using the
> same viewable-dialog widget.

See my comment above about graphic artists.

> > * Put the size in bytes either flushed right to or directly under the
> >"Image Size" label.  Flushed right will probably look better.
>
> I am afraid the HIG disagrees with this. But perhaps it needs to be
> seen on a mockup. I think the memory size is rather well placed, but
> let's see how this would look like.

My concern is that currently the image size is visually associated most
closely with the portrait/landscape control.  Perhaps the best solution is
to have a "Memory Required" outdent at either the top or the bottom, and
have the size after that.

> > * Move the portrait/landscape controls to the right of the template
> >dropdown.  Grey them out when no template is selected.
>
> But they also make sense when no template is selected and allow you to
> easily flip width and height. Why bind them to the template selection?

I thought that they didn't work without templates, but it turns out that I
just tested them on a square image. :)  OK, they are useful for
non-templated images, so instead, I suggest that we keep them where they
are, and grey them out if the image is square.

> > * Merge the two Width and Height entries, or make the second one
> >hideaway.  If you make the second one hideaway, make the top one have a
> >dropdown units menu, so that you don't have to use the hideaway to
> >specify image size in units other than pixel.
> > * Consider making Resolution hideaway as well.
> > * Resolution should have its own outdent, just like Image Size does.
>
> IMHO resolution and the second size group belong together. I could
> imagine having "Pixel Size" at the top and "Print Size" below. The
> "Print Size" group would contain size and resolution.

This makes a whole lot of sense.  Make "print size" and "print resolution"
be one hideaway group.

> > * The units dropdowns should be centered vertically between the two entry
> >boxes to which they apply.  (It would be better if they were aligned
> >horizontally as well, but the presence of the link control in the
> >resolution area makes that impractical.)
>
> /me shudders


OK, so alignment isn't plausable, but the units still should be centered
between the width (or x) and height (or y) entry boxes so that it is more
clear that it applies to both of them.

> > * Consider putting a GtkVSeparator between the "Image Type" and "Fill
> >   Type" combo box lists.
>
> The idea was to make the dialog HIG compliant. The HIG clearly
> suggests not to use any separators and I agree that spacing is a
> better choice since it adds less visual noise.

The HIG guidelines suggest that "[b]efore you add a frame with a visible
border or separator to any window, consider carefully if you really need
it. It is usually better to do without, if the groups can be separated by
space alone. Do not use frames and separators to compensate for poor
control layout or alignnment."  It's not an ironclad prohibition.

(http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-frames)

I refer to my reply to sjburges for my rationale in this suggestion, but
I'll point out here that it's not because of poor control layout or
alignment.  I'll also

Re: [Gimp-developer] status report from the development branch

[Nathan Carl Summers]

On 4 May 2004, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> > > What I didn't address yet is the fact that the HIG suggests to
> > > left-align labels of UI controls while we currently consistenly
> > > right-align labels so that they are close to the control they are
> > > describing. I am not sure if I can follow the HIG argumentation for
> > > this. I guess we should create some screenshots or mockups of standard
> > > GIMP dialogs and discuss this change here before we start to work on
> > > this.
> >
> > It seems like the HIG suggests left-alignment for controls whose labels
> > are roughly equal in length, and right-alignment for dissimilarly-sized
> > labels.  While this probably does result in the most pleasant appearance,
> > it's an internationalization nightmare.  I suggest we stick with the Palm
> > usability guidelines here.  I suggest that the next version of the HIG do
> > the same.
>
> Since we use a whole lot of those labels that say something like
> "Scale X:" and below "Y:" I think we should generally stick to the
> right-aligned labels that we use now. What does the HIG say about the
> colons? Are they needed? Due to kerning the "Y" tends to crawl under
> the trailing colon so I'd rather get rid of the column and increase
> the spacing from the currently used 4 pixels to 6 pixels.

Colons are definitely required; the HIG states that they help screen
readers identify which component is being labeled.  On the other hand,
labeling the two components "X Scale:" and "Y Scale:" seems to conform
better to the independent-labelling guideline while also conveniently
working around the kerning problem.

(For those unfamiliar with the independent-labeling guideline, the HIG
suggests that the entire meaning of a control be contained in the label,
because those with screen-readers cannot tell that (in this case) the
"Scale X:" and "Y:" labels are arrainged analogously, and that both refer
to the scaling parameters.)

> > And while we're talking about the HIG, I still wonder what they were
> > smoking when they suggested that Gnome lay out all of its buttons
> > opposite to the way that common sense and every other set of UI
> > guidelines I've ever read suggests.
>
> If you are refering to the button order in the action area, I have to
> say that I am very happy about this decision. Mac OS uses this button
> order and I always found it to be more logical than the Windows way of
> arranging the buttons.

It seems to me that it makes sense to order the buttons so that when they
are scanned in normal reading order, the most likely button press is the
one that is read first.  If you know you want to "Launch Spaceship", why
should you have to skip over "Help", "Surrender Game", and "Cancel Launch"
first?  I know that you can train yourself to scan the buttons backwards,
but this is inherently less efficient, unless you learn to llew sa
sdrawkcab dear.

I didn't know that the Apple said something different.  I'll have to read
their guidelines again.  They probably have some good rationale.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Joining the GNOME Foundation

[Nathan Carl Summers]

On 3 May 2004, Sven Neumann wrote:

> Hi,
>
> Dave Neary <[EMAIL PROTECTED]> writes:
>
>
> > There are only a very small number of people who really believe this
> > to be still the case. It may still be called the GIMP Toolkit (but
> > more & more I've heard it called the GNOME Toolkit), but that is a
> > historical nod.
>
> I disagree. Every time we port GIMP to new features of the GIMP
> toolkit I get the strong impression that we are the first using the
> new API. There's certainly a lot of interaction between GIMP and GTK+,
> way more than between GIMP and the gimp-print project.

It should be pointed out that Sven is our main point of contact between
GTK and GIMP, so I'm sure he's much more aware of the continuing
interaction between the two projects.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Re: more GIMP foundation stuff

[Nathan Carl Summers]

On Thu, 29 Apr 2004, Daniel Rogers wrote:

> The second structure is the officers.  These are the people like the
> president, tresurer, and secratary.  The duties of these officers are
> set in the bylaws.
> The board members can be officers and [officers] are generally appointed
> by the board.

This clears things up a lot, but before I can make any meaningful comments
on the bylaws, I have to ask the question that we seem to have been
skirting around for a while -- do we want the maintainer and/or release
manager to be officers of the foundation?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Gimp Menu Reorganization

[Nathan Carl Summers]

Hmm, the last message I sent seemed not to get through, so here it is
another time.

Noting that several people have expressed desires to improve GIMP's menu
structure, I have started a Wiki page which we can use as a whiteboard for
rearraigning the menu items.  I have even started to group the menu items,
although it still needs a lot of work.

You don't need a special account or anything -- just visit
http://wiki.gimp.org/gimp/GimpMenuReorganization and hit "EditText" to
edit the page.  You can move things around, rename items,  or just add
commentary!  Here is your chance to help make gimp more usable.

Rockwalrus

PS -- Carol, please forward this to gimp-user.  I don't subscribe there,
but this is a good way for the users to contribute to making GIMP better,
since you don't even need to know how to program to make a real
difference.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] OpenGL under GIMP ??

[Nathan Carl Summers]

On 30 Apr 2004, Sven Neumann wrote:

> Hi,
>
> "Pablo Quinta Vidal" <[EMAIL PROTECTED]> writes:
>
> > This is my first post to the list and I want to know if its possible
> > to use OpenGL under GIMP.
>
> GIMP doesn't use OpenGL but of course a GIMP plug-in can use whatever
> library it wants to use as long as it's possible to integrate it with
> the GLib main loop.

Try GtkGLExt.  It's at http://gtkglext.sourceforge.net

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CVS statistics

[Nathan Carl Summers]

On 23 Apr 2004, Sven Neumann wrote:

> Hi,
>
> for those of you that are into statistiscs, have a look at this:
>
> http://libresoft.dat.escet.urjc.es/cvsanal/gnome-cvs/index.php?menu=Modules&module=gimp

Obviously, the top 21 on that page should get special privileges. ;)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: [Gimp-user] Environment settings & big images

[Nathan Carl Summers]

On 23 Apr 2004, Sven Neumann wrote:

> Hi,
>
> David Neary <[EMAIL PROTECTED]> writes:
>
> > > Photoshop handles large images better than GIMP. That's a known
> > > fact and it's not trivial to improve.
> >
> > How, exactly?
>
> AFAIK they don't load the full image into memory. If you open a large
> image, only the preview is loaded and if you zoom in, then only the
> necessary parts are pulled into memory. Of course this doesn't work
> with all file formats.

There are already bugzilla entries about this -- most prominantly #107246.
I have a feeling to do this right it would have to be a fairly
sophisticated GEGL node.  Why aren't I on gegl-developer again?  :)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] status report from the development branch

[Nathan Carl Summers]

On 22 Apr 2004, Sven Neumann wrote:

> > - A plug-in to load and save windows icon files has been added.
>
> I figured that the plug-in is not working correctly at the moment. Not
> sure what exactly is going wrong but there's some debugging needed
> here.

I'm not sure what the problem you are having is, but I can say that last
time I looked at the windows .ICO plugin it didn't support
multiple-bitdepth icons, at least on saving.  ImageMagick produced bogus
.ICO files as well.  I ended up saving BMPs in GIMP and using a very early
alpha of IconShop to create the icons I needed.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Nathan Carl Summers]

On Thu, 22 Apr 2004, Carol Spears wrote:

> i have a bad opinion of someone who so easily gets to change things on
> an established list.

If I recall correctly, it was Dave who was asking for changes to the list,
or rather, a return to the civility that once was here.

> if you want a friendly mail list about gimp,
> gimp-user list totally fullfills this.

There is no reason why gimp-developer can't fulfil it as well.  Besides,
what if someone wants a friendly list to talk about gimp development
related issues?

> is this person with the smutty mind a developer?

I don't think he has a smutty mind, just is painfully mindful of those
that do.  And there should be no chinese wall between the developers and
the users.  How else can the developers know what the users think, need,
and want?  With no feedback, it's hard to know if changes to the gimp make
it more useful and usable.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Nathan Carl Summers]

On Wed, 21 Apr 2004, Carol Spears wrote:

> while i appreciate someone else being the new person to really abuse the
> mail lists (try cc and one time multiple mailings). ((check to see if it
> is sent to the list or not)).  (((forgive me when i screw up, sometimes
> -- all i get is mail list mail))) and send the email carefully. more
> carefully than me.

Ek!  I feel like I am reading sentences written in scheme!

:-P ;-) :-)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp usability tests

[Nathan Carl Summers]

On Wed, 21 Apr 2004, Juhana Sadeharju wrote:

> >From: Roman Joost <[EMAIL PROTECTED]>
> >
> >Tasks for the first test (all-day-usage; all of the are common tasks for
> >all people, except the one where the indicated group is mentioned):
>
> Could you also make a proper usability test for the rectangular
> selection? I seem to be forced to use the re-try approach where
> I start making the rectangular selection from scratch if it goes
> wrong (and the initial fine-tuning never goes right at first time!).
>
> It also seems to be impossible to make precise selections in large
> images (e.g., 800x800 to 6000x6000). Both large selections and long
> narrow selections on large images are trouble. If zoom-in is used,
> even relatively small images becomes "large".

This is a good idea for a usablilty test subtask. While the difficulties
with the selection tools are well known by the developers, that doesn't
change the fact that a usablilty test can show the extent to which it is a
problem. (In fact, usablilty tests often start with known or suspected
weaknesses.)  I for one would be interested in seeing the results, should
your suggestion be added to the test.

> Test the crop tool too -- it fails for large images as well, or when
> zoom is used for seeing image details.

It would be very useful if we can determine which are the biggest
impediments to usability here.  There are three factors which come to the
top of my mind:

1) The extreme brokenness of autoscroll. Autoscrolling tools currently
scroll far too quickly to be useful in most cases.

2) Users may not be aware of how to change zoom levels without loosing
tool state.  Or, in the case of the rectangular select tool, there is no
real way to usefully change the zoom, since the entire operation must be
performed in a single drag manuver.

3) The interface mechanics (feel) of the tools may need some redesign.
For instance, maybe the crop tool should automatically size itself to the
bounds of the current selection.  Perhaps the rectangular selection tool
should work somewhat like how the old bezier select tool did (where you
could edit the outline of the selection by clicking at the right points,
or cause the selection change to actually occur by clicking in the
center.)  This would, of course, make selection CSG operations more
difficult, so perhaps a third method, where the only selection operations
are select the interior of a path, invert, and QuickMask, may actually be
more useable, and should be tested as well.

> I'm puzzled: do you people make perfect initial selections or how
> you scope with the problem?

Generally what I do is make a "rough cut" in the large and then adjust the
selection using the CSG operations.  This is pretty unsatisfying
sometimes, as you mention, like when you need to move the boarder of a
wide selection up a few pixels.  Often that requires a lot of adding and
subtracting before you get it right.

> If anyone wants implement the unirectangular selection tool and/or
> improve the crop tool, please don't hesitate ask my improved designs.
> (No patent pending.)

If you have any suggestions I haven't covered here, I would be interested
to hear them.


> (GIMP does not anymore compile in my Linux -- we should work out the
> tools together, if at all.)

I'm having a difficult time understanding what "we should work out the
tools together, if at all" means, but I assume you meant to say that you
wouldn't mind help getting GIMP to compile on your machine, which of
course the GIMP developers are more than happy to help with.
Unfortunately, due to the fact that there are many things that could
potentially be at issue here, and Burrito, the GIMP developers' official
psychic, has been a little vague as of late, it would probably help us to
know more specifically what problem you are having.  The last error
messages you got (other than the annoying "Make [56872165]: leaving subdir
foo/bogus/stuff:  Error 1" messages) are most likely to be useful.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] software patent protest?

[Nathan Carl Summers]

On Mon, 19 Apr 2004, Henrik Brix Andersen wrote:

> Hi,
>
> On Mon, 2004-04-19 at 14:57, Branko Collin wrote:
> > I noticed that  has gone 'black', in order to
> > protest European software patents. A noble cause, for sure, but
> > should this not have been announced at least, perhaps even debated?
> > Or did my trigger-happy, spam-seeking delete-finger erase that
> > message accidentally?
>
> This was discussed on the gimp-web mailing list.

It should also be noted that last time we did this it was discussed on
gimp-developer as well.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] interface nomenclature

[Nathan Carl Summers]

On 1 Apr 2004, Sven Neumann wrote:

> This linked state does not only affect movement, it also applies to
> transformations.

Interesting.  I did not know that.  You learn something every day.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?

[Nathan Carl Summers]

On 25 Mar 2004, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
>
> > Not Found
> > The requested URL /~tml/index.html was not found on this server.
>
> IIRC the URL is either http://www.gimp.org/~tml/gimp/win32/ or
> http://www.gimp.org/win32/.

Yeah, I know that.  That url wasn't working either.  Now it is.  Perhaps
some cache needed to expire.

Actually, I said that urls of the form ~tml weren't working, because my
goals were twofold.  I noticed that ~rock didn't work, and then at that
point I realized that if ~rock didn't work, ~tml probably wouldn't either,
which means that one of the most visited gimp-on-windows pages wasn't
working at release time.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?

[Nathan Carl Summers]

On 25 Mar 2004, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> > Also, urls like http://www.gimp.org/~tml don't work, but you probably
> > already knew that.  http://wilber.gimp.org/~tml does work still.
>
> It works again now.

Hmm, not for me:

Not Found
The requested URL /~tml/index.html was not found on this server.

Additionally, a 500 Internal Server Error error was encountered while
trying to use an ErrorDocument to handle the request.
Apache/1.3.26 Server at mmmaybe.gimp.org Port 80

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?

[Nathan Carl Summers]

On 25 Mar 2004, Sven Neumann wrote:

> Hi,
>
> "Branko Collin" <[EMAIL PROTECTED]> writes:
>
> > As some of you may have noticed, for a short while there was a
> > www.gimp.org that claimed a release of GIMP 2.0.0., and Slashdot
> > confirms it, so it may be true.
> >
> > The corpse of the Slashdot story has grown decidedly cold and rigid,
> > yet http://www.gimp.org still seems to be down (or just very, very
> > slow).
>
> The new machine seems to have some problems. It remains to be figured
> out what kind of problems. But it went alive yesterday after the
> slashdot attack and when it's there, it's very responsive :) No idea
> why it's not avaiable at the moment, but rest assured, we know about
> the problem and it will be taken care of.

Also, urls like http://www.gimp.org/~tml don't work, but you probably
already knew that.  http://wilber.gimp.org/~tml does work still.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] PDB requirements (was: PDB named and default parameters)

[Nathan Carl Summers]

On Sun, 21 Mar 2004, Manish Singh wrote:

> On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:
> > How far along is the planning? I have heard of Rock's libpdb,
> > which I believe he wants to finish for 2.2, but I hadn't heard
> > any concrete plans for the often-mentioned forthcoming PDB
> > re-write.
>
> There hasn't been any real planning, other than planning to do some planning
> after 2.0 is out. All I was saying is that we haven't forgot about it.

2.0 is out now. :)

> > What requirements would the new PDB have?
>
> There's a number of issues to be addressed, like GEGL node support,
> efficiency, UI generation, distributed processing, and macro recording
> support.

Macro recording is already trivial with libpdb: you just connect to the
appropriate signal of the Pdb object.

Distributed processing will soon be supported by libpdb using the
WireSocket backend; this will be done by early May.  Implementing
WireSocket is one of the group projects chosen by some of the students in
a class I am taking, so it will be done if they want a good grade. :)

UI generation is mostly out of the scope of libpdb.  I would have to know
more what is specifically meant by "UI generation" before I could comment
on it.


Efficiency has yet to be addressed by libpdb, although some easy
optimizations have been put in place.  Serious optimization should
probably wait until the feature requirements are more in place and
reasonable profiling can be done.

GEGL node support opens a big can of worms, and there probably is no best
solution.  The first big decision to make is whether plug-ins should be
written as GEGL nodes objects directly, or whether there should be a shim
GEGL node that translates the operations into procedural calls not unlike
those in the traditional GIMP api.

If we do use a translating shim, Libpdb seems like a good fit for this as
well.

It seems like a real shame to lose GIMP's ability to run plug-ins out of
process, so my vote is we rule out dynamically loading gegl nodes using
GPlugIn as the only method, although we may want to be able to do it as
an additional extra-fast method.

CORBA seems like a flexible choice here if we decide to make plug-ins
implemented directly as gegl nodes. Although my guess is it would add
somewhat more overhead than a hand-rolled gimp-specific method, it has the
advantage of being more flexible than anything we could do, and also it
would be something maintained by an outside group instead of another
burden for us.

If we do decide to have plug-ins be native GeglNodes, I recommend that we
still have a PDB for scripting purposes.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] PDB Named Parameters

[Nathan Carl Summers]

On Fri, 19 Mar 2004 [EMAIL PROTECTED] wrote:

> On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote:
> [stuff deleted]
> >
> > The only thing that struck me as missing was the work involved with
> > porting the plug-ins to the new API, but Raphaël already pointed that
> > out in another reply to this thread.
>
> I very much hope that at least this time around, since so much is anyhow
> changed, the PDB will finally get the face lift and use named parameters
> instead of positional ones.

FYI: the version of libpdb in CVS already uses named parameters instead of
positional ones.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] The GIMP Foundation

[Nathan Carl Summers]

On 8 Mar 2004, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> > In my mind one of the major reasons to have a Gimp Foundation is to put
> > all of our IP ducks in a row.  As I've said before I don't think that
> > having contributors sign over copyright to TGF would be the best plan.
> > Instead, I would like to see the ability to give TGF power-of-attorney to
> > sue copyright violators in their behalf.
>
> Does IP mean what I think it means? Let's hope it doesn't because
> there simply is no such thing as intellectual property. Knowledge must
> not belong to anyone.

I believe that intellectual property is a natural right, but should be
limited in scope for the same kind of reasons that you are not allowed to
invite someone onto your property and then kill them, even though you own
the weapon and the land.  More specifically, I think that the number of
years copyrights last should be counted on one hand, and that if you have
access to software, you should have access to its source.

I could go on with more detail about my views about copyrights and
patents, but that is really offtopic for this list.

I agree with RMS that lumping several somewhat dissimilar aspects of law
together under the same title can lead to confusion, but in this case, it
causes no confusion, since the gimp foundation should indeed hold all gimp
related copyrights, trademarks, and patents.  GIMP can't have trade
secrets, obviously.  And a service mark might be more appropriate than a
trademark; i dunno.  Having a patent or two for protection might be
pragmatic, even though I think that software patents are stupid.

> If sueing copyright violators is the main goal, I'd rather let the
> Free Software Foundation do this job. It is probably in a lot better
> position when it should ever come to a law-suit.

Well, the FSF cannot sue unless it has copyright assignment from us, and I
don't think we can really do a credible job unless it gets assignment at
least from Spencer, Peter, Sven, and Mitch.  (All other substantial
contributors are also listed here, your eyes just skip over them every
time you read the list :)

> Also, so far the FSF has done a great job at funding our developer
> conferences. So we should really have good reasons to form our own
> foundation since I don't expect the FSF to grant any more fundings as
> soon as The GIMP Foundation has been created. This is not a vote against
> the TGF; it's just something to keep in mind...

Perhaps we should bring the FSF into the discussion.  We are, after all,
an official GNU project, even though FSF gives us complete autonomy.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] The GIMP Foundation

[Nathan Carl Summers]

On Mon, 8 Mar 2004, Daniel Rogers wrote:

> Hello again,
>
> It has been awhile since I have done a GIMP Foundation update.   There
> is quite a bit that must be decided on at this point.  Also, people need
> to decide how invovled they would like to be.
>
> My goals for The GIMP really boil down to three things.  First, I really
> want to see The GIMP to be a household name for professional image
> editors.  Second, I want to the GIMP as easy as possible for volunteers
> to contribute to.  Third, I want to be able to turn The GIMP into a
> real, paid, career for a team of people, including myself.

I would add usability for all and ease-of-getting started for new and
casual users to the list of gimp goals.

> If you are a board member you must:
> Attend board meetings.

Is this required to be in person, or is conference call/irc/email/etc
sufficient?  Furthermore, is it possible for board members to be
reimbursed for expenses?  I can see this being a major obstacle for non-us
residents otherwise.

> WHAT THE ORGANIZATION CAN DO
>
> Here are a few of the things, that given the oppurtunity and funds I
> would like to do with TGF.

In my mind one of the major reasons to have a Gimp Foundation is to put
all of our IP ducks in a row.  As I've said before I don't think that
having contributors sign over copyright to TGF would be the best plan.
Instead, I would like to see the ability to give TGF power-of-attorney to
sue copyright violators in their behalf.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Press pack requests

[Nathan Carl Summers]

On Mon, 8 Mar 2004, Dave Neary wrote:

> Hi all,
>
> The 2.0 release is getting closer, and there are still some thing missing from
> the press pack we want to send out.
>
> - Could native english speakers who have a few minutes please look at the
> "What's new in GIMP 2.0" page (http://wiki.gimp.org/gimp/WhatsNew) and correct
> any grammar problems?

There weren't really any major grammar problems, at least when I got to
it, but there were some punctuation problems and some awkward sentences,
which I improved.  I didn't make any stylistic changes; perhaps someone
like Bex should take a look at it and make the style consistent.  I'm just
a computer programmer, no mas.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Costs estimates

[Nathan Carl Summers]

On Mon, 23 Feb 2004, Dave Neary wrote:

>
> Hi all,
>
> For funding requests for GIMPCon in Norway, it will be very useful to
> have cost estimates for the event for the GIMP.
>
> Could everyone planning to go to Kristiansand send an estimate of how
> much money they will need to get there?

Ugh!  I can't find airfare there any cheaper than about US$1500.  Has
anyone from the US found a much better deal?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp on OS X

[Nathan Carl Summers]

On Wed, 11 Feb 2004, Daniel Egger wrote:
> On Feb 11, 2004, at 4:06 pm, Sven Neumann wrote:
>
> > Daniel recently posted a list of X extensions supported by the Apple
> > X11 server. The MIT-SHM extension was part of this list but today I
> > found that at least in darwinports gtk2 is compiled with the
> > --disable-shm configure option. Does anyone know if fink does this as
> > well?
>
> I can confirm it does.
>
> > Is there a particular reason to disable the use of the XShm
> > extension on OS X? This would explain at least some of the slowness
> > that people reported here lately.

IIRC, didn't early versions of OS X have truly pitiful amounts of shared
memory available?  Perhaps that is the reason.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] The GNU Image Manipulation Program

[Nathan Carl Summers]

On Wed, 28 Jan 2004, Dave Neary wrote:

> Hi all,
>
> Dave Neary wrote:
>  > Because of its continued excellence and longstanding presence as a key
>  > free program, I think that the GIMP deserves an OSA.
>
> Apologies for jumping the gun, I hope I didn't step on anyone's toes
> doing this.
>

I personally would never be upset with anyone trying to obtain money for
gimp, as long as it is done legally.  :)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Anti-counterfeit software: implications for Open Source

[Nathan Carl Summers]

On 21 Jan 2004, Sven Neumann wrote:

> What is especially worrying me is that there seems to exist a proposal
> for EU legislation to require devices and software to include
> counterfeit deterrence technology:
>
>  http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf
>
> This document explicitely asks for comments and IMO it would be a good
> idea to prepare such a comment. We could do this as the GIMP developers
> or try to corporate with the FSF Europe.

Yes, I think it would be best to do it as a joint GIMP/FSF Europe comment.
I would include something akin to the following:

* GIMP is a popular image-manipulation program that is used in many
different applications, such as web design.

* Should legislation be enacted requiring currency detection, GIMP would
effectively be outlawed from the European Union, since, due to its open
source nature, it is trivial to modify it to skip the currency detection
step.

* The legislation would not have its desired effect anyway, since it is
not significantly more difficult for a dedicated individual to modify a
closed-source program to skip the currency detection.  Once a program is
modified once, it is trivial for instructions on how to modify the program
to be spread to others.

* There are many legitimate and legal uses for images of currency. FSF
Europe and the GIMP developers are greatly opposed to any measure that
would restrict the freedom of expression of the citizens of European Union
member nations.

It would then of course be signed by all the GIMPers who are members of
the EU.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Status of gegl, gimp 3.0?

[Nathan Carl Summers]

On 5 Nov 2003, Sven Neumann wrote:

> Hi,
>
> Piotr Legiecki <[EMAIL PROTECTED]> writes:
>
> Indeed. Websites do rarely say anything useful about the state of
> development of an open source project. If you had a look at CVS, you'd
> have noticed that there is indeed development going on.

Which brings up an interesting question -- how can an open source project
accurately represent what is going on in developmentland on its web site?
It's more of a question to ponder -- I don't have the answer myself.  On
first thought, a todo list with progress bars and lists of current scarry
bugs would be good, and a Kernel Cousin-like newslog could be good, too.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Difference between 1.2 .gih and 1.3 .gih files?

[Nathan Carl Summers]

On 23 Sep 2003, Jeff Trefftzs wrote:

> On Tue, 2003-09-23 at 04:10, Michael Natterer wrote:
>
> > Just open the failing brushes with ->Open and save them again.
> > The plug-in is still able to read these files and will save the new
> > format.
>
> Thanks to Dave, Simon, and Mitch for the prompt replies.  I'm converting
> the old brushes now.

Hmm, this should make it into the release notes.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)

[Nathan Carl Summers]

/me returns from the hurricane, finally able to catch up on several days
worth of email.

On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote:
>
> However I *love* the Ctrl-R binding, especially because it lets me quickly
> compare the done and undone versions of an image using a single hand with
> very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll find
> that you need either very good coordination between fingers (better than the
> one I have at least) or to use both hands.

I agree.  Gimp's undo and redo feature differs from many other programs in
that when comparing subtle changes it is useful to switch rapidly between
the "before" and "after" views, while for a program such as a word
processor, that is probably not a useful thing to do.  This being the
case, this particular need of GIMP users was probably not considered by
the HIG.

Personally, I compare between the "before" and "after" by holding down
control and hitting z or r as necessary.  For some changes, I switch
several times a second, as the human eye is remarkably able to detect
small differences when they are animated.

Switching between views this fast with accuracy is simply not possible
using Shift-Ctrl-Z due the the physiology of the human hand. The optimal
hand position is left on the shift and control and right on the z, with
the finger on the shift moving every other beat of the other hand and the
finger on the control key staying still.

Here the body's natural cordination works against switching views quickly,
as the nervous system will assume that the finger on the R key and
that on the shift key should really be synchronized.  This leads to
errors. With the old bindings the natural cordination system helps to
acomplish the task accurately and faster.

> So, if it's possible to have two different keybindings for the same command
> I'd like very much to have both.

Unfortunately, it is not.  Really, GTK should be made more flexable in
this regard, but it is not a trival problem, due to how GTK handles
accelerators.

Since we only can choose one, it makes sense that we choose the one that
ergonomics favors.  I'm sure that in this case most usability people would
say that actually being able to use the feature is more important than
consistancy with some other apps.  Especially because this particular
funciton isn't particularly consistant between apps.

On the other hand, we could go for both ergonomics and consistency by
using MS Office's Ctrl-Y.  Note that I am not recommending it.  I think
keeping redo the way it is in 1.2 is the best policy.

> BTW, the mail program I'm using right now (Forte Agent) uses Ctrl-R to redo.

There we go, between that and tradition, we have all the justification we
need. ;)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Screenshot plug-in status

[Nathan Carl Summers]

On Thu, 11 Sep 2003, Alan Horkan wrote:

> I only ask that you take a moment and consider if there might be a way to
> make things faster for the user which is where speed really counts.
> Could some of the handling of the system clipboard be done automatically
> and only when needed to mitigate the speed tradeoff?  If is impractical
> fair enough, I was just asking because the code was being changed anyway.

It seems to me that using the system clipboard, but using the internal cut
and paste instead of the system functionality whenever it is detected that
the sender and reciever are the same process would be the best solution.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Proposal for protesting against softwarepatents in Europe

[Nathan Carl Summers]

On Tue, 26 Aug 2003, Raphaël Quinet wrote:

> Well, this may be a bit controversial,

I don't think that there is any disagreement about software patents among
the major gimp developers.

> but I thought about supporting the demonstration against software
> patents in Europe by replacing the GIMP home page by the following page:
>   http://www.gimp.org/nopatents.html
> I prepared that page a couple of days ago, but now I see that the
> announcement about the protest has been posted on Slashdot and several
> other sites.  So maybe it is time to put it on the home page, unless
> most people here are against this kind of online protest.

> The GIMP web site is in the U.S. so this may not be so relevant.  But on
> the other hand, several of the most active GIMP developers are living
> and working in Europe.

I doubt anyone cares where the server is physically located.  I'm an
USsian, and I care about software patents in europe (as well as the US).

> Is anybody against that kind of action on the GIMP web site?

No, I'm very much for it.

> If there is any strong opposition against it, then there is no need to
> have a long debate: I will simply forget about it.  Otherwise, I would
> like to replace the home page of www.gimp.org later today (let's say in
> three or four hours).

Before doing that, please correct two nits:
1. Change "well-documented" to "well-researched" or "well-written,"
depending on what you meant.  Well-documented is not idiomatic English.

2. Make the "no ePatents" graphic point at something.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Documentation of the GIMP-1.3 internals

[Nathan Carl Summers]

On Mon, 18 Aug 2003, Sven Neumann wrote:

> Hi,
>
> there is something I hacked up during GimpCon and I thought it might be
> of interest to some of you although it's not yet finished (and perhaps

YEY!

(This is a very good thing.)

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Portable XFC

[Nathan Carl Summers]

On Thu, 14 Aug 2003, Sven Neumann wrote:

> Hi,
>
> I never understood the reasoning for this discussion anyway. IMHO the
> format that Nathan suggested seems like something from the dark ages of
> file formats (where TIFF and the like originated from).

PNG is something from the dark ages?

>  I haven't heard a single good argument for it except that it can do
> most of the things that the XML/archive approach can do.

s/most/all, and many other good things besides.

> There was however nothing mentioned that it can do better. Or did I miss
> something?

XML is a text markup language.  If the designers thought of using it for
raster graphics, it was an afterthought at best.  XML is simply the wrong
tool for the job.  The XML/archive idea is the software equivalent of
making a motorcycle by strapping a go-cart engine to the back of a
bicycle.  It will work, of course, but it's an inelegant hack that will
never be as nice as something designed for the job.

But to answer your question:

1. Putting metadata right next to the data it describes is a Good Thing.
The XML "solution" arbitrarily separates human readable data from binary
data.  No one has yet considered what is to be done about non-human
readable metadata, but I imagine it will be crammed into the archive file
some way, or Base64ed or whatever.  Either way is total lossage.

2. Imagine a very large image with a sizeable amount of metadata.  If this
seems unlikely, imagine you have some useful information stored in
parasites.  The user in our example only needs to manipulate a handfull of
layers. A good way of handling this case is to not load everything into
memory.  Say that it just parses out the layer list at the start, and then
once a layer is selected and the metadata is requested, it is read in.
With the XML proposal, the parser would have to parse through every byte
until it gets to the part it is interested in, which is inefficient.
Frankly, this wouldn't be feasable.  Only two crappy ways would be
possible to get around this: store everything in memory (hope you have
plenty of virtual memory!) or write out a temp file with the metadata in
it, for later use, and in a random-accessable format.  If you're going to
do that, why not do it right the first time and save yourself the trouble?

3. None of the current suggestions for archive formats do a good job with
in-place editing.  AR can't even do random access.  Zip can do an ok job
with in-place editing, but it's messy and often no better than writing a
whole new file from scratch.  This means that a program that makes a small
change to a file, such as adding a comment, needs to read in and write a
ton of crap.

4. Implementing a reader for the XML/archive combo is unnecessarily
complex.  It involves writing a parser for the semantics and structure of
XML, a parser for the semantics and structure of the archive format, and a
parser for the semantics and structure of the combination.  It is true
that libraries might be found that are suitable for some of the work, but
developers of small apps will shun the extra bloat, and such libraries
might involve licensing fun.  The semantics and structure of the
combination is not a trivial aspect -- with a corrupt or buggy file, the
XML may not reflect the contents of the archive.  With an integrated
approach, this is not a concern.

5. Either the individual layers will be stored as valid files in some
format, or they will be stored as raw data.  If they are stored as true
files, they will be needlessly redundant and we will be limited to
whatever limitations the data format we choose uses.  If we just store raw
data in the archive, then it's obvious that this is just a kludge around
the crappiness of binary data in XML.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Portable XFC

[Nathan Carl Summers]

On Thu, 14 Aug 2003, Sven Neumann wrote:

[Note: quote blocks have been reordered for clarity]
> Hi,
>
> I'd like to mention that none of the proposed formats except the XML
> approach would be capable of supporting the stuff we want to add to GIMP
> with GEGL.

On the contrary, my proposal would handle graphs as easily as XML would.

> We are not talking about simple layer lists or trees any longer but we
> need to be able to store complex processing intructions with each node.
> XML seems to be the only reasonable choice here.

My proposal is tree-based just like XML.  And you can do graphs in it
exactly the same way it is done in XML -- by labeling elements of the tree
and using the labels to denote the links between the nodes on the graph.

> I don't think any existing format could be sanely extended to
> support complex render graphs as will be introduced with GEGL.

Depends on what you mean by "sanely extended."  Of course it is unlikely
that you could create something that interoperates well with existing
applications, but there is nothing inheritly wrong with takiing an
existing format, or more than one, and using it for the basis of the new
XCF.

> According the library that reads and writes the new format, GEGL should
> provide this functionality. The basic file format should be defined by
> GEGL and GIMP will only add some user interface specific things in its
> own namespace.

I can imagine that parasites, at the minimum, would also go in the GIMP
namespace.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Sat, 9 Aug 2003, Leonard Rosenthol wrote:

> >I see fast loads as an absolute requirement.
>
>   Then we need to also look at the GIMP itself and what can be
> done there.

Of course.

> >Hopefully, GIMP's file handling will improve to the point where it will
> >load thing on an as-needed basis.  Therefore, fast random access is
> necessary.
>
>   Having load on demand via random access is what will really
> get you the fast loads!!   If you don't solve that, then any work on
> the file format will be a waste towards your goal.

Exactly, it's a big priority.

> >  Being compact is nice as
> >well, because not everyone has 3 terrabyte harddrives and a T3 line into
> >their house.
>
>   Agreed, but what does this really mean in "real world" terms.
> Are we willing to sacrifice functionality to get a couple of bytes
> here and there?  The image data is the big hit in this format - the
> structure will end up as a small fraction of any XCF file.

We certainly shouldn't sacrifice high-priority stuff for size, but size
should still be a consideration.

> >  > * incremental update
> >>just update a single layer w/o rewriting the whole file!
> >
> >This seems like an excellent goal.  It seems like you are suggesting a
> >database-like format.
>
>   Not necessarily.  You should be able to do it with any format
> with a good catalog system, but some will be easier than others.

How would you handle resizes?  Either we could do immediate compaction or
garbage collection.  Both have their disadvantages.

> >  >  I think sub-chunks is a bad idea.  Although a common way to
> >>  represent hierarchical relationship, they can also put overhead on
> >>  random access and also slow down read/write under certain conditions.
> >
> >How about a TIFF-like directory chunk at the beginning (except
> >hierarchical)?
>
>   That would be one solution - sure.

Can you think of a better one?

>   I just think that doing a full "reinvent" of an image format
> seems like a waste of time.  Let's look at Photoshop...
>
>   Photoshop is able to do 100% round-tripping of ALL of its
> functionality in three formats - PSD, TIFF and PDF.  PDF is done via
> throwing their private info into an undocumented blob - so it doesn't
> really count.  So let's look at the other two.
>
>   Both PSD and TIFF are rich image formats that already address
> most of your original list and are well defined and supported by many
> existing tools (including GIMP itself).  Both are extensible (TIFF
> more so) and would allow for additional blocks to meet our needs.
>
>   Is there a good reason not to use either PSD or TIFF as the
> native format?   The only possible argument for either is that Adobe
> controls them both.  However, I would state that TIFF has pretty much
> taken on a life of its own outside Adobe (via libtiff).

I think the goal of the XCF redesign is to become the de-facto standard
for interchange of layered images.  Certainly one aspect of this is
freedom from Adobe, but in addition to being an open standard, it needs to
be a standard that people have confidence in.  In other words, any XCF
reader should be able to read any XCF writer's output.  A layered TIFF by
that name wouldn't cut it, because most tiff readers don't support layered
images.  Of course, we could always use TIFF internally but call it XCF.
We might want to change the magic number as well.

I have no problem with basing Portable XCF on TIFF.  It seems to be well
designed without really being too overdesigned.  On the other hand, I
think there are a few improvements that we could make to make it better
for the purposes of GIMP.

/me wonders if the CinePaint people have any thoughts...

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

RE: [Gimp-developer] Re: GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Tue, 12 Aug 2003, Austin Donnelly wrote:

> > > How is the serialization done then, just a raw 32-bit IEEE float
> > > dump with a predefined endianness?  64-bit doubles just as easy?
> >
> > Yup.
>
> The real problem comes when your code is running on a system without IEEE
> float support, and you need to manually convert from IEEE float to your
> local weird-ass machine float.  Not common, I grant you, but a real pain
> when it bites.

Well, since my day job is working with a non-IEEE machine, I can tell you
about that pain first hand.  It probably took about three days to write
conversion functions between the native format and IEEE float and double.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Mon, 11 Aug 2003, Adam D. Moss wrote:

> Nathan Carl Summers wrote:
> > On Mon, 11 Aug 2003, Adam D. Moss wrote:
> >>IIRC, the Loki guys.  Some ramblings a few years ago on the
> >>problems of interoperability of game data between
> >>windows/mac/linuxx86/linuxalpha/etc over network and on disk.
> >>They made a special point of saying something like 'never, ever
> >>serialize floats' and it sounded like the voice of experience.
> >
> > Java doesn't seem to have a problem with it.  Even poor fools like me who
> > are working on VM's for machines with non-IEEE floats don't have too much
> > of a problem.
>
> That's good to know, it helps me out with some of my
> own stuff...
>
> How is the serialization done then, just a raw 32-bit IEEE float
> dump with a predefined endianness?  64-bit doubles just as easy?

Yup.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Wed, 20 Aug 2003, Leonard Rosenthol wrote:

> At 11:42 PM + 8/13/03, Phil Harper wrote:
> >well, it'd be interesting to see if Adobe added XCF to Photo$hop,
> >after all, GIMP is the competition, it wouldn't be in their
> >interests to support a multilayered image format that it controlled
> >by someone else(although they might support PSP, i don't know
> >haven't checked.)
>
>   They support a number of formats that they don't control -
> because they are standard formats that their customers are
> requesting.   But today XCF isn't one of them, and probably won't be
> for a while.

AFAICT, there is nothing stopping Gimp developers from creating a
potatoshop plugin that can read XCF.

>
> >it'd be nice if your app could read and render a flat version of the
> >image if you don't support layers i supose, this is an interesting
> >one since all these different target apps will handle things like
> >layermodes differently, and some wouldn't even be supported.
>
>   EXACTLY my point!
>
>   Whatever file format we end up with, we need to accept that
> not all consumers of that file format will be able to support 100% of
> the features (perhaps not even GIMP itself).
>
>
>
> >no, that simply wouldn't be flexible enough, surely, i mean you
> >could have extra data about how do use the layers in the TIFF but if
> >those aren't recognised by other readers you just get a strange
> >result and a confused decoder.
> >
>
>   You could get that just as easily with XCF when a given
> consumer/reader doesn't support 100% of the features of the format...

With a PNG style format, this becomes much less of an issue.  First, PNG
requires all readers to be able to interpret a core subset -- anything
that can't interpret it violates the standard.  Second, all chunks are
tagged "optional" (meaning that they can be safely ignored if not
understood" or "mandatory" (in which case the reader will give up if it
doesn't understand the chunk.)  This means that a baseline PNG can be read
by any compliant program (hello, IE!) without problem, and any extensions
will either degrade gracefully or cause an error, but in no case will  the
decoder become confused and return a strange and wrong result.

In this way, for example, someone could create a PNG chunk that indicated
that the data was in Lab space, and a decoder that didn't recognize that
feature would just give up instead of returning some garbage where the red
channel gets luminence, etc.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] GimpCon RFC: Portable XCF

[Nathan Carl Summers]

Several XCF formats have already been proposed; why should I propose
another?  It seems to me like the existing proposals have all missed the
main point.  While they have nice properties for certain extreme cases,
they miss the boat when it comes to the main point of a graphics format,
which is to efficiently store (and load) graphical information.  This has
lead to proposals that are neither elegant nor simple; instead they are
cumbersome, with redundant, and superficial information stored,
along with potential for confict between different sections of the file.

But rather than detail these problems, let me suggest my own solution.

Let us start with an existing graphics format, for inspiration if nothing
else.  The format I chose is PNG, because it is arguably the best existing
lossless portable graphics format available.  Before we continue, though,
allow me to ennumerate what charactoristics the Gimp native format should
possess, in no particular order:

1 lossless
2 portable between architectures and programs
3 extensible
4 capable of representing trees and graphs
5 recoverable from corruption
6 fast random access of data
7 able to support many color depth and spaces
8 able to represent any state that gimp maintains
9 fast loads and saves
10 compact
11 good compression of graphical data

PNG certainly supports 1,2,6,7,9,10, and 11.  Let us examine the other
issues in more detail.

Extensablity: PNG supports some degree of extensiblity, but the namespace
available is quite small, being only four letters.  While we could use the
same chunk type name for all of our additions, say 'GIMP', and then have
the first field in the chunk contain which kind of chunk it really is.
But this is an inelegant hack.

Capablitity of representing trees and graphs: Obviously, png's
minimal extension facilities could be used to implement chunks that
envelope an entire tree of chunks, but this would be difficult to
reconsile with PNG's current order-based approach to metadata association,
and would be awkward for GIMP-aware and non-GIMP-aware PNG readers alike.

Corruption Recovery: PNG has good corruption detection, but little to
facilitate corruption recovery.

Representation of GIMP state: see extensibility.

While PNG's faults aren't serious, we can do better.

A pure XML format, by way of comparison, would fulfill requirements
1,2,3,4,7, and 8.  Requirement 5 in practice would be difficult to fulfill
in a pure XML format without hand-hacking, which is beyound the skills of
most users.  A zlib-style compression step could make some progress
towards 10.

An archive with XML metadata and png graphical data, on the other hand,
would satisfy requirements 1,2,3,4,7,8, and 11.  Requirement 6 is
fulfilled for simple images, but for more complex images XML does not
scale well, since every bite from the begining of the XML file to the
place in which the data you are interested in is.

It seems like all we have to do is combine the strengths of PNG and the
strengths of XML to create a format that satisfies our requirements.  What
we really need is not an extensible text markup language, but an
extensible graphics markup format.

Such a format would bear strong resemblence to both PNG and XML.

Portable XCF would use a chunk system similar to PNG, with two major
differences.  First, chunk type would be a string instead of a 32-bit
value.  Second, chunks can contain an arbitrary number of subchunks, which
of course can contain subchunks themselves.

At the end of each chunk is a checksum, as well as a close-chunk marker.
The purpose of the close-chunk marker is to help recover in case of
corruption; if no corruption is detected, the close-chunk marker is
ignored.

One of the major advantages of this hybred technique is that if an
implementation does not understand or is not interested in a particular
chunk, it can seek to the next chunk without having to read or parse any
of the data in-between.

image data chunks should use png-style adaptive predictive compression.
They should also use adam-7.

An example is worth a thousand words.  Here is a simple RGB image with two
layers (one with a parasite) and a comment.  This is just a rough sketch
of what it would look like:

(labels in all capitial letters are for illustrative purposes and do not
take up any space in the file.)

FILE HEADER:
"portable xcf file"
version major - 1 byte
version minor - 1 byte

CHUNK:
chunk start, optional - 2 byte bitmask with some png-like flags
"xcf-comment"
total size of chunk and subchunks - 4 bytes
size of chunk - 4 bytes
"This is the comment"
chunk end (flags) - 2 bytes
"xcf-comment"
1 (subchunk depth) - 1 byte
crc32 - 4bytes

CHUNK:
chunk start, manditory - 2 bytes
"xcf-layerstack"
total size - 4 bytes
size - 4 bytes

SUBCHUNK:
chunk start, manditory - 2 bytes
"xcf-colorspace"
total size - 4 bytes
size - 4 bytes
"xcf-sRGB"
chunk end (flags) - 2 bytes
"xcf-colorspace"
2 (depth) - 1 byte
crc32 - 4 bytes

SUBCHUNK:
chunk start, manditory - 2 bytes
"xc

Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Sun, 10 Aug 2003, Leonard Rosenthol wrote:

> At 7:18 PM +0200 8/10/03, Guillermo S. Romero / Familia Romero wrote:

> >About TIFF, every now and then someone appears with an horror story about TIFF
> >files, so while better than PSD, I dunno if enough. :/
>
>   There are programs out there that generate bad TIFF - for one
> reason or another.   But we already have to deal with that in our
> native TIFF coder...

This is what I mean by a standard that people can have confidence in --
people should trust that if their program writes good XCF's that a good
program will be able to read it.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Second try

[Nathan Carl Summers]

On Fri, 8 Aug 2003, Joao S. O. Bueno wrote:

> hmm...Agreeded.
>
> I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy
> workload week, 5 days could not be enough to make my points, if they
> need soem expermenting on the codebase), But since the decision was
> taken, so mote it be - it's not gonna hurt.

I would say that contentous issues that cannot be settled by consensus and
cannot be decided by technical merit should be put up to a vote of the
foundation members.

Things that can be decided on technical merit should be decided by a
bake-off, of course.

Well, should the bake-off not show a clear winner, I guess a vote would be
necessary.

> As for the foundation., I'd be happy if it was in Europe. USA is
> getting more and more of those stuppid laws, including states passing
> "super-DMCAs¨ , that if enforced would stop the Internet alltogether.

That would be best.  We might need to set up a shadow organization in the
US, but let's leave that up to the lawyers.

> The foundation has to care off one other thing I did not see on the
> summary: most, or all of the codebase must be owned by it. It would
> legally allow small adjusts in the license, like the recently one
> that clarified that there could be proprietary plug-ins for the GIMP.
> (Strictly in terms of the GPL, as currently the copyright holder is
> each individual author, there would be the need to have express
> permission from each author for this change). Also, there is the GNU
> motive - if the need arises to defend GIMP's IP in court, it is
> easier if the foundation is the owner, and not a lot of people spread
> over the world.

Exactly.  Really, we haven't been dotting our i's and crossing our t's
with regards to licensing.  We should clean everything up just in case we
get SCO'ed sometime.

> Off course there must be foolproof safeguards to keep the foundation
> from doing non-wanted things to the codebase. So, that GIMP should be
> free software should be specified in the "reason of being"of such a
> foundation.

Personally, I would be wary of signing away my rights to the GIMP
foundation, especially if my continued membership was not assured.
Instead, I propose that some sort of power of attorney be assigned,
instead of transfering all rights.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Mon, 11 Aug 2003, Guillermo S. Romero / Familia Romero wrote:

> [EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700):
> > Portable XCF would use a chunk system similar to PNG, with two major
> > differences.  First, chunk type would be a string instead of a 32-bit
> > value.  Second, chunks can contain an arbitrary number of subchunks, which
> > of course can contain subchunks themselves.
>
> PNG 32 bit names are char... or at least all them can be read. :] And
> I think the purpose of this was, among other ideas: easy to parse
> (always four chars) and makes sense with some rules about chars (caps
> vs normal). Even the magic of PNG had a reasoning (part binary to
> avoid confusion with text and capable of detecting non 8 bit
> transmision or bad byte order). IOW, why not make it similar, but just
> bigger (four char for name space and 12 more for function)? Arbitrary
> size strings does not seem a good idea to me.

This seems like a good proposal.

> Another thing, alignment (and thus padding), is worth the problems it
> could cause? If the format has to be fast, maybe this should be taken
> into account, and not only about small sizes in memory (ie 32 bit),
> but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too.
> Would the format be used just as storage, or would it be used as
> source / destination when memory is scarce. Remember that some apps
> are capable of working in areas instead of the full image, to improve
> global troughput.

Right.  To be mmappable, the format should be aligned.  I think with
careful design, there won't be too much overhead from this.

When I wrote that the example was just a rough sketch, part of what I
meant was that I didn't pay too much attention to bit sizes and alignment,
because that would have been premature optimization.

One issue with alignment is which platform's alignement rules should be
used.  I think a good common-denominator format can be found.  It won't
get the wierd ones, of course.  I work on a Cray, and nothing follows
cray's alignment rules. :)

> > image data chunks should use png-style adaptive predictive compression.
> > They should also use adam-7.
>
> I would avoid compression inside the format. Files can be compressed
> as a whole

It does complicate in-place image manipulation, true.  OTOH, you can get
much better lossless compression using image-specific techniques such as
predictive compression than you can using general purpose techniques.

> and IIRC Adam7 is about interlacing, not compression,
> dunno why an editor should do progressive load. Load smaller res in
> case of problem? I would try to avoid that instead of try to fix it,
> with proper storage and transmission. Load with proxy images? Too
> rough, IMO, it is not a scaled down version.

Well, working a scaled-down version of large files is an important
optimization.  It's true that not all image manipulation functions can
credibly be approximated with working on a scaled-down version, but that's
for the gegl people to worry about.

My guess is that it will be easier to use interlaced data than true
scaled-down images, and the savings in terms of computational time and
pipeline flexablity will be worth it.

> PNG compression is the one provided by zlib

PNG's use zlib compression on the overall file, but the entropy is first
significanty reduced by using predictive encoding.  It's not the same as
just running gzip on raw data.

> and I can show you cases in which other compressors have done a better
> job with my XCF files (anybody can try bzip2), and if computers keep
> evolving the same way, the extra CPU load is better than the disk or
> network transfer.

True.

> Letting other apps do it means those apps could be general, reducing
> work load.

Of course, but we should not sacrifice functionality for convenience.  :)

> Or better, custom, but once the "look" of the data is well
> known and there is plenty of test cases (like FLAC but for XCF2,
> compression targeted at some kind of patterns).

Conformance testing is very important.  That is a good idea.

> Realize too that this links to aligment things, if you know that a layer
> is always somewhere and requires X MB, you can overwrite and reread
> without problems.

This will have to be worked out.

> >
> > CHUNK:
> > chunk start, optional - 2 byte bitmask with some png-like flags
> > "xcf-comment"
> > total size of chunk and subchunks - 4 bytes
> > size of chunk - 4 bytes
>
> For all these sizes... why not 64 and be avoid future problems? If
> someone likes it and uses it for really big things, segmentation is a
> negative point. Or maybe force a small max size for each chunk
> (forcing segmentation) which would give more CRCs. Options, options,
> options...

Both have their plusses and minuses.

> > "This is the comment"
> > chunk end (flags) - 2 bytes
> > "xcf-comment"
> > 1 (subchunk depth) - 1 byte
> > crc32 - 4bytes
> [...]
>
> I would add unique chunk ID to each, so then can make references.

Good idea.

Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Thu, 14 Aug 2003, Øyvind Kolås wrote:

> * Adam D. Moss <[EMAIL PROTECTED]> [030814 09:59]:
> > Stephen J Baker wrote:
> > >So, I think what is needed to make a reliable file format is to provide
> > >a well written library for reading and writing the files that's freely
> > >available and properly maintained on every modern platform FROM DAY ONE.
> >
> > I agree with this -- I think it's really important.

[SNIP]

> > but in any case it makes sense to library-ise the XCF load/saver just
> > from a technical abstraction standpoint.)
>
> Which is why I in an earlier mail suggested developing a GEGL file format
> that gimp could extend and use a subset of. By doing it this way, gegl
> would be the aforementioned file loading, and compositing library,.
> (e.g. if an application needs to load an XCF2 file, but don't support
> layers, the library would be capable of compositing it, putting the
> logic to do compositing of layers, layer groups, adjustment layers, u8,
> u16, float, double, cmyk, rgb, ycbcr and spotcolors into a file loading
> library,. makes very little sense

It actually makes a lot of sense to have GEGL support loading XCFs.  It
would probably be a good idea to have a separate library as well, for
those apps that already have their own compositors and don't want to have
another one as well.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Portable XFC

[Nathan Carl Summers]

On Thu, 21 Aug 2003, Leonard Rosenthol wrote:

> At 1:47 PM +0200 8/14/03, Sven Neumann wrote:
> >I'd like to mention that none of the proposed formats except the XML
> >approach would be capable of supporting the stuff we want to add to GIMP
> >with GEGL.
>
>   Well, that pretty much settles that discussion...

Not really, since that reasoning is based on an untruth.  And even if it
wasn't, it's a logical fallocy to assume that because no graph-capible
proposal was made, that XML was the only possible way of representing a
graph in a file format.

> >According the library that reads and writes the new format, GEGL should
> >provide this functionality.
> >
>
>   Requiring an application to incorporate all of GEGL in order
> to read/write an XCF file is, in my opinion, a recipe for it not
> getting used by other applications.  (and I say this as one of those
> other application developers).

That is why I suggest both a lightweight library and gegl routines for it.
Actually, gegl can use the lightweight library for the loading.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GimpCon RFC: Portable XCF

[Nathan Carl Summers]

Good to get some high-quality feedback.

On Sat, 9 Aug 2003, Leonard Rosenthol wrote:
> At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote:
> >Let us start with an existing graphics format, for inspiration if nothing
> >else.
>
>   OK.
>
>
> >The format I chose is PNG, because it is arguably the best existing
> >lossless portable graphics format available.
>
>   Well, I would argue that TIFF has the "crown"...
>
>   However, PNG is an excellent standard, regardless.

Good point.  It can't hurt to take a look at several graphics formats and
take the best parts from each of them.

> >4 capable of representing trees and graphs
>
>   Trees, yes - for things like layers.   But why a graph??

GEGL supports graphs.  If we use GEGL graphs, we'll need a representation
;)

> >5 recoverable from corruption
> >6 fast random access of data
> >9 fast loads and saves
> >10 compact
>
>   Good goals, but not a requirements.  Perhaps you should
> separate those two things out...

I see fast loads as an absolute requirement.  Being compact is nice as
well, because not everyone has 3 terrabyte harddrives and a T3 line into
their house.

Hopefully, GIMP's file handling will improve to the point where it will
load thing on an as-needed basis.  Therefore, fast random access is
necessary.  A VIPS-like demand-driven pipeline would increase gimp
responsiveness a lot.

>   And I can think of other goals that I'd like to see:
>
> * incremental update
>   just update a single layer w/o rewriting the whole file!

This seems like an excellent goal.  It seems like you are suggesting a
database-like format.

> * rich metadata
>   (this may be your 7, but needs to be spelled out)

Well, that was what I meant by extensibility and the ablity to represent
anything GIMP can.  I agree that this is important.

> >PNG certainly supports 1,2,6,7,9,10, and 11.  Let us examine the other
> >issues in more detail.
>
>   I would argue that PNG doesn't do 7 - it has no native
> support for CMYK, for example.  (but yes, it does RGB,  Gray and
> indexed).
>
>
>   And for comparison, I would offer that TIFF does the same
> list and REALLY does 7, including CMYK, Lab, ICC and Spot color
> spaces.   It's extensibility is similar to PNG (in fact, PNG's chunks
> were modelled on TIFF chunks).

Indeed.

> >A pure XML format, by way of comparison, would fulfill requirements
> >1,2,3,4,7, and 8.
>
>   I'd add 9, just being in XML doesn't mean it can't be fast.

I guess if you used raw image data instead of base64 or something similar

> >  Requirement 5 in practice would be difficult to fulfill
> >in a pure XML format without hand-hacking, which is beyound the skills of
> >most users.  A zlib-style compression step could make some progress
> >towards 10.
>
>   But gzipping the entire XML block would then pretty make 6
> impossible unless you want to seriously increase in-memory
> requirements.

right.

> >An archive with XML metadata and png graphical data, on the other hand,
> >would satisfy requirements 1,2,3,4,7,8, and 11.
>
>   An archive (zip, tar, ar) with XML metadata plus raster image
> data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11.   5 &
> 10 are related to the archive format of choice since some are better
> at these than others.  But yes, I suspect that it would probably be a
> bit slower.
>
>
>
> >Requirement 6 is
> >fulfilled for simple images, but for more complex images XML does not
> >scale well, since every bite from the begining of the XML file to the
> >place in which the data you are interested in is.
>
>   But the XML is just a "catalog" of what's in the archive (at
> least in my proposal).  So you read the catalog up front and then use
> it to quickly find the part of the archive you want and viola - fast
> random access to data.
>
>
> >It seems like all we have to do is combine the strengths of PNG and the
> >strengths of XML to create a format that satisfies our requirements.  What
> >we really need is not an extensible text markup language, but an
> >extensible graphics markup format.
>
>   That's what TIFF and PNG were designed for.
>
>
> >Portable XCF would use a chunk system similar to PNG, with two major
> >differences.  First, chunk type would be a string instead of a 32-bit
> >value.  Second, chunks can contain an arbitrary number of subchunks, which
> >of course can contain subchunks themselves.
>
>   I think sub-chunks is a bad idea.  Although a common way to
> represent hierarchical relationship, they can also 

Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF

[Nathan Carl Summers]

On Mon, 11 Aug 2003, Adam D. Moss wrote:

> IIRC, the Loki guys.  Some ramblings a few years ago on the
> problems of interoperability of game data between
> windows/mac/linuxx86/linuxalpha/etc over network and on disk.
> They made a special point of saying something like 'never, ever
> serialize floats' and it sounded like the voice of experience.

Java doesn't seem to have a problem with it.  Even poor fools like me who
are working on VM's for machines with non-IEEE floats don't have too much
of a problem.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Third big serious meeting from GIMPcon

[Nathan Carl Summers]

> Like in any Free Software project, developers are leaving from time to
> time to pursue other projects.  And from time to time, new developers
> are joining the team and starting to contribute.  However, it looks
> like the number of new developers joining the GIMP development has
> been decreasing in the recent years.

Probably one of the main reasons is that Gimp isn't the only major
open-source end-user app anymore.

But yes, I would not be surprised if Gimp was percieved as stagnating.

> There should be a section on www.gimp.org or developer.gimp.org titled
> "How to contribute?" or "How to get involved?".  It should be easy for
> potential new developers to see where to start and how they can help.

Absolutely.  We need to make it as easy as possible.

> It would be very nice to have Windows binaries for the development
> version.

I would say that Mac users and Windows users are much more likely to
expect and use binaries.

> Is Bugzilla too hard to use for new users?
> --
>
> It was suggested to make it easier for users to submit bug reports,
> for example by having an e-mail address to which bug reports can be
> sent without having to register to Bugzilla (we already have such an
> address, although it is not widely known).

Personally, I'd like to see Bugzilla be the only place for gimp bugs.

> This proposal was rejected because most of the bug reports (especially
> from new users) are incomplete and require additional information.  If
> the user does not have a Bugzilla account, it is not possible to rely on
> the automatic notification system to send messages to the user when a
> comment is added to their bug report or when the status of their bug
> report changes.

Agreed.

> Most developers consider Bugzilla to be a very valuable tool that
> works well.  Instead of trying to hide Bugzilla from the users, we
> should try to make it as easy as possible for the new users to join.
> This is already done to some extent by the bug submission wizard
> available from http://bugs.gimp.org/.  There is a small problem with
> the GNOME2 keyword that prevents the open GIMP bugs from being
> displayed to the user and we should try to get this fixed.

A good wizard would go a long way towards making first-time Bugzilla
submission not so overwhelming.

> List of open tasks
> --
>
> There are many open bug reports or proposals for enhancements that
> would be relatively easy to fix or implement.  We should make it
> easier for potential contributors to see the list of easy tasks that
> are open.  The "easy tasks" should include anything that can be done
> in one or two hours by an average developer or maybe a bit more if the
> contributor is not familiar with the code.
>
> The best way to keep the list of open tasks up-to-date is probably to
> base it on Bugzilla.  We could for example use a Bugzilla keyword for
> all bugs that are easy to fix (there is already a keyword "easy-fix"
> reserved for that, although we could invent our own).  It would then
> be easy to create a Bugzilla query showing the list of easy tasks.

I think that this is the best solution. I have already marked some easy
bugs with the easy-fix keyword.

> Another solution would be to have a page on www.gimp.org or
> developer.g.o containing a list of all these bugs, with direct links
> to the corresponding bug reports.  The second solution may require a
> bit more work because it would have to be maintained by someone, but
> it might be a bit easier to use.

I doubt there would be much advantage to doing this.
>
>
> The following items should be available in the web site:
> - "How to contribute?" / "Getting involved"
> - List of tasks

I propose that other outstanding tasks, like things that we would like to
see in the next version, be available as Bugzilla query links.  When
necessary, we can add keywords or tracking bugs.

> - List of sources of contains some useful items such as "Bugs", "FAQ",
> etc.  information (mailing lists, newsgroup, ...) - FAQ
>
> As with the other documents summarizing what is happening here at
> GimpCon, comments are welcome...

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A fresh pair of eyes.

[Nathan Carl Summers]

On Thu, 31 Jul 2003, Sven Neumann wrote:

> Hi,
>
> Jay Cox <[EMAIL PROTECTED]> writes:
>
> >> You have a point, I dont much like the proposed solution though.
> >
> > Any other solution would probably be too complex to implement at this
> > point in the release cycle.
>
> We finally got rid of the palettes being copied to the users dir and
> now you want to copy all files? You must be kidding.

Not necessarily related, plus how was Jay supposed to know about that?
Secret gimp omniscence sauce?  He's been back for what, a day? and you
expect him to know everything that has been done...

But I think that having a list of undesired
pallete/gradient/brushes/textures/plugins(?)/etc saved in the gimprc file
and having the interface not show them would be the best way of doing
things, and shouldn't be that hard to implement.  You could even have a
button to make them visable again.

If that doesn't seem feasable, at least we should ln -s the entries
instead of copying them.  But that will not work on wincrap :(

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A fresh pair of eyes.

[Nathan Carl Summers]

On 30 Jul 2003, Jay Cox wrote:

> This was the first chance I've had to spend quality time with gimp in
> several years.  After this long separation from gimp, I feel that my
> eyes are pretty fresh.

Whho!  I think I speak for all of us old fogies when I say,
"Welcome back!"

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1

[Nathan Carl Summers]

On Sat, 26 Jul 2003, Adam D. Moss wrote:

> 2) It might be argued that the basic dependance and interconnection
> of a not-GPL-compatible plug-in with the GPL GIMP core via libgimp
> and the wire protocol is intimate enough that the two cannot be
> considered independent and separate works.  (Yeah, really.)

>From my reading of the exogen---oh, I don't know how to spell that
word--of the GPL, that is mitigated by the fact that there exist
(existed?) programs other than gimp that can use gimp plugins.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1

[Nathan Carl Summers]

On Fri, 25 Jul 2003, Joao S. O. Bueno wrote:

> Hi.
>
> I do not know the X11 license, but changing the license of
> the plugin template recalls me of one thing:
>
> If the GIMP is under the GPL, with no exceptions listed were
> appropriate, them it is ilegal for non GPL-compatible plugins to be
> installed.

Gimp plugins do not link with the Gimp and thus do not fall under Gimp's
licence.  Gimp plugins do link with libgimp*, which is licensed under the
LGPL.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] tentative GIMP 2.0 release plans

[Nathan Carl Summers]

On Fri, 18 Jul 2003, Sven Neumann wrote:

> Hi,
>
> I'd like to inform you about our plans for the GIMP 2.0 release.
>
> First of all, Mitch and me are not willing to raise the 2.0 versus 1.4
> discussion again.

Gimp is more than "Mitch and me," isn't it?

> Both sides have expressed their arguments. We took quite some time to
> think about all of them and to reconsider our decision. We came to the
> point that it should be called 2.0. It's just a number, so please,
> before you start the discussion again, think twice if it's worth it.

It really is worth it.  We will loose *A LOT* of trust with our users if
we disappoint them.  There are many more than a trivial number of people
whe expect CMYK, 16-bit, etc in gimp 2.0. These people are our *MOST
ACTIVE USERS* and those who are waiting for gimp to have these features.
Any time in the past two years that someone has asked on IRC or mailing
lists when gimp will have these features.

The second group mentioned I worry about more; the people who need these
features, when they hear that 2.0, will check it out and sorely be
disappointed.  I don't know how well a reference to the story of the Boy
Who Cried Wolf communicated cross-culturally, but I can tell you that once
lied to once, these people will probably not trust the gimp developers
again.  They will go elsewhere.  This is a big loss to us -- imagine what
contributions would come to gimp if people who professionally need
features like deep images would be using the software.  The lack of deep
image support up to this point has already cost us a lot; those who
flocked to the program formerly known as FilmGimp would have flocked to us
instead.

Yes, calling the new release 2.0 is a LIE.  I cannot emphasize this
strongly enough.  It is a lie because we have told many, many people what
2.0 will do.  To release a 2.0 without these features is pure
misrepresentation.  It is much too late to put the worms back into the
can.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]

[Nathan Carl Summers]

On Wed, 16 Jul 2003, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> Fullscreen mode was added to be able to view the image in a neutral
> environment w/o being distracted by any user interface elements.
> Adding a menubar would completely ruin this effort.

I'm sure any UI expert you talk to (or really, anyone who thinks about it
for twelve seconds) will tell you that putting up a fullscreen image
without any obvious method of exiting is likely to inspire panic in the
user, who doesn't know how to get out.

> The fact that you can edit the image in full-screen mode and that we
> even decided to allow you to tweak what gets hidden and what not is
> just an additional nicety and I'm actually tempted to remove it.

Don't!  Fullscreen mode is useful for more than that.  It is nice when
working on a large image, or a smaller image with high magnification, to
get rid of superfluous stuff like the window decoration, but in that case
the user may still want to use of the stuff that would otherwise be
hidden.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]

[Nathan Carl Summers]

On Wed, 16 Jul 2003, Alan Horkan wrote:

>
> On Wed, 16 Jul 2003, Sven Neumann wrote:
>
> > Date: Wed, 16 Jul 2003 13:57:18 +0200
> > From: Sven Neumann <[EMAIL PROTECTED]>
> > To: Alan Horkan <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Menubar in fullscreen mode [Re: [Gimp-developer] the user
> > installer]
> >
> > Hi,
> >
> > Alan Horkan <[EMAIL PROTECTED]> writes:
> >
> > >> Go to the menu and toggle "View Menubar". How did you miss this?
> > >
> > > (Gimp 1.3.4) I had the menubar turned on I expected to still have the
> > > menubar in fullscreen mode.
> >
> > I don't understand your answer but just to clarify my sentence I will
> > describe the behaviour of fullscreen mode for you. By default, if you
>
> I expected the menubar to stay on in fullscreen mode.  I just wanted to
> point out that my expectations were different from what happened, which I
> realise is unneccessary information from your point of view.  (I only have
> a recent build at home so it takes me a while to check these things).

This actually could be a serious usablity issue, since a user who has the
menubar on (which a distro might set as default) after going to fullscreen
mode might not be able to figure out how to get the menubar back, or even
how to return to windowed mode.

(bah, watching actual real users in usablity tests at work stumble around
when using really fairly simple interfaces has caused me to loose all
faith in the intelligence of humanity.  Then again, our users are actual
real users, too.)

Seriously, though, it would be a much better behavior to keep the menubar
when the window is made fullscreen.  A user that prefers a menubar will
probably prefer one in fullscreen mode also.  Besides, a user with a clue
will be able to turn off the menubar anyway.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec

[Nathan Carl Summers]

On Fri, 11 Jul 2003, Leonard Rosenthol wrote:

>   But the fact is that you're going to end up having to Base64
> encode all the image data - which will blow the physical file size
> WAY out of proportion.  And if don't do that (ie. attempt to leave in
> binary data), then you are violating the spirit of XML's design goals.

Honestly I can't think of a way to put image data into a file format at
all that wouldn't violate SGML's design goals.  XML may differ in some
aspects from SGML, but the fact is that SGML was designed to be a markup
language for documents written in human languages, and the design
decisions that created that also make storing binary in *ML cumbersome.

GIMP needs a file format that is extensible, and a native representation
for tree structures is essential, but there are plenty of ways to do this
other than the XML method.  Storing images, which ar almost all binary
data, in true XML is a lesson in inefficiency.

Oh wait, I take it back.  I can think of a image format that retains the
spirit of XML:


 Created by the GIMP!
 
  
   






   
   
.
.
.
   
  
 


Determining whether this is a good format is left as an exercise to the
reader.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] MMX in 1.3 tree

[Nathan Carl Summers]

On Fri, 11 Jul 2003, Steinar H. Gunderson wrote:

> On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote:
> I don't think there should be a % in the list of clobbered registers. What's
> worse, I don't even think most versions of gcc know about MMX registers at
> all (I might be mistaken, though :-) ) and thus you'd need to simply clobber
> the entire FPU stack (which the MMX registers get aliased upon).

How hard would it be to write an autoconf test for that?

Rockwlrs

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Macro Recorder 2nd Try

[Nathan Carl Summers]

On Mon, 23 Jun 2003, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> >> In short the approach (more info in bugzilla) :
> >> - Intercept every PDB call if a macro recorder instance is running.
> >
> > The cvs version of Libpdb already provides a flexible mechanism for
> > intercepting pdb calls.  I designed it with macro recording in mind.
>
> When I read this mail, an idea came to my mind that I hadn't thought
> of before. I'm bringing it up here for discussion:
>
> Is the PDB really the right place for a macro recorder? As a user I
> would expect it to be tightly coupled with the Undo system. I would
> want to be able to go back five steps and change the brush I used for
> that paint-stroke, then replay the actions I had performed so far.

You're absolutely right!  It seems to me that since we already have the
undo system in place, and it is called in all the right places, that that
would be a better place to put the macro recorder.


> But perhaps this just means that the Undo system needs to be hooked
> into the PDB as well ?!

That could be cool.  You could Undo a couple of times, change the source
image a bit, and then Redo, and the Redo would call all the appropriate
functions again.

> This would also avoid the mentioned problem with PDB functions called
> from plug-ins.

True, although it's really not that hard to implement a call depth
tracker.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Macro Recorder 2nd Try

[Nathan Carl Summers]

On Fri, 20 Jun 2003, Hans Breuer wrote:

> I'm about to give it another try with current cvs code
> base, but before I would like to get some information
> to avoid (if possible) fast rotting bits.
>
> In short the approach (more info in bugzilla) :
> - Intercept every PDB call if a macro recorder instance is running.

The cvs version of Libpdb already provides a flexible mechanism for
intercepting pdb calls.  I designed it with macro recording in mind.

>   (try to guess the call stack depth to avoid recording functions
>called by a plug-in)

I had a solution to that problem, but I don't remember what it was anymore
;(

> - deliver PDB calling information to the temp_proc installed by
>   the macro recorder
> - extend the Gimp Protocol to allow to deliver typed parameter
>   information after an interactive plug-in has fininished it's
>   work.
> - long-term : replace the gimp_set_data/run-with-last-values
>   mechanics with the typed parameter information

I'll illustrate the way I imagine this will work with libpdb in an
example:

Say that the user calls the Gausian Blur IIR plugin.  Gimp calls the pdb
function gimp_plugin/gaussian_blur_iir/interactive, which returns an
argument list with the user's desired parameters.  Gimp then calls
gimp_plugin/gaussian_blur_iir with the appropriate values.  The macro
recorder catches the call and records it.

Almost all of the work necessary for this situation has been done and is
present in the CVS version.

> - build a first full blown script recorder in the prefered
>   scripting language (mine is Python)

It would be nice eventually to have a language-neutral frontend that feeds
ASTs to the language-specific backends.

> - maybe : allow to let plug-ins register default parameters
>   along with their procedures

This would be a good addition.

> - use default parameters to reduce 'forced dialogs', i.e. make
>   them optional. Best example is png-save where the user - at
>   at least I - almost never changes any values.

Sounds nice, but how would the user change the values when needed?

> Now for my questions :
> - are there further huge changes planned for the plug-in/pdb
>   code (time involved to maintain my patch) ?

Libpdb will be used in the next version of gimp.  It probably makes the
most sense to concentrate on implementing this functionality there.  We
have already made a good start on it.

> - is the outlined approach mature enough to be at least
>   considered for acceptance if I have a first working version ?

It would certainly be accepted in libpdb.  ;)

Nathan

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New thread on GIMP 1.3+

[Nathan Carl Summers]

My vote is for 1.4.  Otherwise, the Slashdot headline we will get is "GIMP
2.0 Fails to Deliver Promised Features"

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] running gimp withou't make install?

[Nathan Carl Summers]

On Sun, 1 Jun 2003, Joao S. O. Bueno wrote:

> But what I do need now is a faster way to go from edit code to running gimp.
> Make Install asctually eats out a lot of time on my system. Is it possible to
> run the gimp-1.3 binary generated from make straight, without make-installing
> it?

Of course you can, as long as all the data is installed in the right
places (which the first make install took care of for you.)

> How can it be done?
cd app
./gimp-1.3

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Tool API [LONG!]

[Nathan Carl Summers]

Here is a list of all the symbols currently used by the current tools,
courtesy of
nm tools/*.o paint/*.o | cut -b 10- | grep ^T | cut -b 3- | sort | uniq

stdlib, glib, gdk, pango, and gtk calls have been eliminated from this
list.

The big things that stand out are accessing the global "the_gimp", and
calling tile and tile manager functions.  "the_gimp" should not be
accessed directly, and tile_manager is probably too ugly for tool
developers with weak stomachs.

Rockwalrus


active_color
add_alpha_region
apply_mask_to_region
blend_region
brightness_contrast_lut_setup
brush_scale_mask
brush_scale_pixmap
color_balance
color_balance_create_lookup_tables
color_balance_init
color_balance_range_reset
color_pixels
color_region
combine_mask_and_region
convolve_region
copy_region
curves_calculate_curve
curves_channel_reset
curves_init
curves_lut_func
find_mask_boundary
floating_sel_anchor
floating_sel_relax
floating_sel_rigor
gdisplays_check_valid
gimp_base_config_get_type
gimp_bezier_stroke_extend
gimp_bezier_stroke_get_type
gimp_bezier_stroke_new
gimp_brush_get_spacing
gimp_brush_get_type
gimp_brush_select_brush
gimp_brush_want_null_motion
gimp_bucket_fill_mode_get_type
gimp_channel_add_segment
gimp_channel_invalidate_bounds
gimp_channel_new_mask
gimp_channel_ops_get_type
gimp_channel_value
gimp_color_area_get_type
gimp_color_area_new
gimp_color_area_set_color
gimp_color_panel_get_type
gimp_color_panel_set_context
gimp_config_connect
gimp_config_copy_properties
gimp_config_deserialize
gimp_config_disconnect
gimp_config_duplicate
gimp_config_reset
gimp_config_serialize
gimp_container_add
gimp_container_add_handler
gimp_container_get_child_by_name
gimp_container_remove_handler
gimp_container_thaw
gimp_context_copy_properties
gimp_context_define_properties
gimp_context_get_brush
gimp_context_get_display
gimp_context_get_gradient
gimp_context_get_opacity
gimp_context_get_paint_mode
gimp_context_get_pattern
gimp_context_get_tool
gimp_context_get_type
gimp_context_new
gimp_context_set_background
gimp_context_set_display
gimp_context_set_foreground
gimp_context_set_parent
gimp_context_set_tool
gimp_context_tool_changed
gimp_crop_type_get_type
gimp_cursor_new
gimp_devices_get_current
gimp_dialog_create_action_area
gimp_dialog_factory_dialog_raise
gimp_dialog_get_type
gimp_directory
gimp_display_config_get_type
gimp_display_coords_in_active_drawable
gimp_display_flush
gimp_display_flush_now
gimp_display_get_type
gimp_display_shell_draw_guide
gimp_display_shell_get_type
gimp_display_shell_scale_by_values
gimp_display_shell_selection_visibility
gimp_display_shell_set_cursor
gimp_display_shell_set_override_cursor
gimp_display_shell_transform_xy
gimp_display_shell_transform_xy_f
gimp_display_shell_unset_override_cursor
gimp_display_shell_untransform_xy
gimp_dock_get_type
gimp_double_adjustment_update
gimp_drawable_blend
gimp_drawable_bucket_fill
gimp_drawable_bytes
gimp_drawable_calculate_histogram
gimp_drawable_data
gimp_drawable_get_color_at
gimp_drawable_get_type
gimp_drawable_has_alpha
gimp_drawable_height
gimp_drawable_is_indexed
gimp_drawable_is_rgb
gimp_drawable_mask_bounds
gimp_drawable_offsets
gimp_drawable_push_undo
gimp_drawable_transform_cut
gimp_drawable_transform_matrix_perspective
gimp_drawable_transform_matrix_rotate_center
gimp_drawable_transform_matrix_scale
gimp_drawable_transform_matrix_shear
gimp_drawable_transform_paste
gimp_drawable_transform_tiles_affine
gimp_drawable_transform_tiles_flip
gimp_drawable_type
gimp_drawable_width
gimp_enum_option_menu_new
gimp_enum_radio_frame_new
gimp_get_current_context
gimp_get_mod_name_alt
gimp_get_mod_name_control
gimp_get_type
gimp_get_user_context
gimp_gradient_get_color_at
gimp_gradient_type_get_type
gimp_gui_config_get_type
gimp_help_connect
gimp_help_set_help_data
gimp_histogram_box_get_type
gimp_histogram_box_new
gimp_histogram_calculate
gimp_histogram_channel_get_type
gimp_histogram_free
gimp_histogram_get_count
gimp_histogram_get_mean
gimp_histogram_get_median
gimp_histogram_get_std_dev
gimp_histogram_nchannels
gimp_histogram_new
gimp_histogram_view_get_channel
gimp_histogram_view_get_type
gimp_histogram_view_new
gimp_histogram_view_set_channel
gimp_histogram_view_set_histogram
gimp_histogram_view_set_range
gimp_hls_to_rgb_int
gimp_image_active_drawable
gimp_image_add_guide
gimp_image_add_hguide
gimp_image_add_layer
gimp_image_add_vectors
gimp_image_add_vguide
gimp_image_apply_image
gimp_image_contiguous_region_by_seed
gimp_image_crop
gimp_image_crop_auto_shrink
gimp_image_delete_guide
gimp_image_find_guide
gimp_image_floating_sel
gimp_image_flush
gimp_image_get_active_layer
gimp_image_get_background
gimp_image_get_color
gimp_image_get_foreground
gimp_image_get_type
gimp_image_map_abort
gimp_image_map_apply
gimp_image_map_clear
gimp_image_map_commit
gimp_image_map_get_color_at
gimp_image_map_new
gimp_image_mask_boundary
gimp_image_mask_bounds
gimp_image_mask_clear
gimp_image_mask_float
gimp_image_mask_is_empty
gimp_image_mask_select_by_color
gimp_image_mas

Re: [Gimp-developer] Plug-in preview API proposal

[Nathan Carl Summers]

On Thu, 3 Apr 2003, Ernst Lippe wrote:

> On the contrary, there appear to be lots of acceptable
> names.
> I am suprised that nobody has suggested YetAnotherGimpPreview :)

How about GimpPluginView?
GimpSample?
GimpTheWidgetFormerlyKnownAsPreview?
GimpFancyPreview?
GimpMcPreview?
GimpExample?
GimpView?

Actually, GimpThumbnail is more reasonable for the core widget's name than
it is for the plugin widget's name.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Plug-in preview API proposal

[Nathan Carl Summers]

On 31 Mar 2003, Sven Neumann wrote:


> I'd even prefer to have everything that is related to this widget be
> under the same namespace. Unfortunately GimpPreview is already taken, so
> we either need to change the name of the core object or find a new one
> for the plug-in preview.

(off-the-cuff) Perhaps GimpThumbnail?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] blizzards, mononucleosis, and tool plug-in TODOitems

[Nathan Carl Summers]

On 30 Mar 2003, Sven Neumann wrote:

> Hi,
>
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
> What needs to be done for the next release is a major cleanup of the
> tools.

I agree.

> Part of this cleanup should be a proper documentation on how to
> write a GIMP tool.

Providing source for a sample tool was supposed to be on the list I sent.
I don't know why I didn't remember to put it on last thing.

> I believe that it doesn't make sense to even think about pluggable tools
> before this has happened.

While we should have a good specification of the "tool api," not thinking
about plugging issues would be counterproductive.  Many of the existing
issues are related to the nonextensiblity of the current api.

> I'd rather start the tool cleanup by moving GimpToolControl back into
> the core

I think that we should get the advice of the win32 developers because of
the braindead behaviour of winbloat's dynamic linker before we move
anything.  Note that tool plugins will need to make calls to
GimpToolModule code and GimpToolControl code and who knows what else.

> and I'd like to remove the cheesey hacks that were added all over the
> place.

Which "cheesey hacks" are you refering to?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] blizzards, mononucleosis, and tool plug-in TODOitems

[Nathan Carl Summers]

I'm sorry that I haven't been able to do much GIMP participation in the
last several months.  I don't want to bore everyone here with details of
my personal life, so suffice it to say I haven't been able to spend much
time hacking or even replying to email.  I regret any inconvenience this
has caused.

The last time I checked, in-process tool plugin loading worked with only
a handful of mild issues to be resolved.  I have no doubt that it can be
in perfect working order in less than two weeks.

Out-of-process tool plug-ins are an entirely different matter.
Implementing them would still require a fair amount of work.  It would
also involve some changes to the gimp protocol which, while I would not
really term them to be kludgy, add more complexity in places they
shouldn't be.

Given our time constraints, that in-process tool plug-ins already work,
and that out-of-process tool plug-in communication can be handled much
more cleanly in libpdb (which I sincerly hope will be used in GIMP 2.0), I
would not be opposed to the removal of out-of-process tool plug-ins from
the list of goals for 1.4.  While I still believe that out-of-process tool
plug-ins are the Right Thing to do, they can wait for 2.0.  Regardless of
whether out-of-process tool plug-ins make it in 1.4, I now feel that the
best developmental proceedure is to make in-process tool plug-ins work as
well as possible.

Without further ado, here is a list of things that must be done to make
tool plug-ins useful:

* the loop in tools.c that loads tool modules should be uncommented and
moved before the loading of the built-in tools, so that they appear last
in the toolbox. (perhaps it would be good to allow tools to be reordered
by the user.)

* cheesey_module_loading_hack needs to stop leaking memory and handle
errors sanely.  It could also use a better name.

* a dialog box should be able to show the tool modules loaded, and tool
modules shoulde be loadable and unloadable at runtime.  Specifically,
any tool not currently being used should be unloadable. That would make
tool plug-in development significantly less painful.  The current module
dialog would be a sensible location for this additional functionality.

* tool plug-ins need the ability to supply a custom icon.  Themes should
be able to supply a replacement if they "know about" that particular
tool plug-in.

* likewise, tool plug-ins should be able to supply their own mouse
cursors.

* the back-end pixel-crunching code usable by both the gui and pdb
interfaces should be better separated from the interface-specific code.  I
have long felt that the paint tool refactoring is a good example of how
this can be better accomplished, and feel that similar measures would be
useful in the rest of the tools.

* tool plug-ins need a mechanism to expose their functionality to the PDB.

I will file these items in Bugzilla if consensus is that this is the best
course of action.  I look forward to your comments.

Respectfully,
Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GimpToolGui

[Nathan Carl Summers]

On 30 Jan 2003, Sven Neumann wrote:

> Hi Nathan,
>
> when I updated my gimp tree this morning I was surprised to see this
> commit:
>
> 2003-01-30  Nathan Summers  <[EMAIL PROTECTED]>
>
> * app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended
> from GimpObject to be used to separate GUI from logic.  Heavily
> inspired by GimpDrawTool.  Not actually used by anything yet.
>
> Would you mind to explain what you have in mind here?

Not at all.  I think I posted this before, but basically, I'd like to have
a GimpToolGui class and a GimpToolLogic class, which both inherit from
GimpObject.  The appropriate GimpToolInfo structure would then have to
have the GType for both the gui and logic classes.  A GimpTool can then be
created that contains a pointer to both a GimpToolGui and GimpToolLogic.

> Looks a lot like the GimpDrawTool actually and I'd like to hear about
> your plans for the tools since of course Mitch and me have a plan as
> well. I must admit that we haven't told you about it neither but we are
> actively working towards a massive tool redesign for quite some time
> now.

I would love to hear what you have in mind.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] New Gimp FAQ: Call for Answers

[Nathan Carl Summers]

This is the the Call for Answers for the "clean room" reimplementation of
the GIMP User FAQ.  Please send [EMAIL PROTECTED] a message stating your
intent to write an answer, and CC it to the lists so that no one else
takes that question.  If I do not recieve an answer within three days, I
will open that question up again.

Once all the questions are answered, I will send a final draft out for
comments.  The final version of the FAQ will be placed under the GNU Free
Documentation Licence.

Soon thereafter we will start with the Call for Questions for the
Developer FAQ.

I must reiterate that copying from the current GIMP FAQ's is simply not
acceptable.  Such submissions will be rejected.

If English is not your first language, don't feel that you can't take
part.  Any grammar mistakes will be lovingly corrected, so even if your
English is not perfect, you can still contribute significantly.

FAQ entries should be written with respect to 1.2.x, but should also
contain any significant changes in 1.3.x.  If you don't use 1.3.x, it is
not neccessary to mention differences in 1.3.x -- they will be added by
the GIMP web team.

Please do not assume that all readers of this document will be Linux users
-- we want to treat users of all supported operating systems equally, to
the extent that our limited resources are capible of supporting.

Here is the list of questions:

I. About the GIMP.

1.  What is the GIMP?
2.  What does GIMP stand for?
3.  What features does it have?
3a. What limitations does GIMP have?  How many layers, channels, etc. can
GIMP handle?
4.  How close in functionality to PhotoShop is the gimp?
4a. Does it support CMYK?
 b. 16-bit per channel images?
 c. Floating-point channels?
 d. Does GIMP provide a "gamut warning" like Photoshop?
5.  What are the minimum system requirements?
5a. What operating systems is it available for?
6.  Where can I get it?
6a. There are some binary versions on the GIMP website. Should I download
them or build GIMP myself?
6b. Where can I get non-official gimp packages for foo?
7.  What version should I get?
8.  What documentation is available?
8a. Where can I find some "good" GIMP tutorials?
9.  Is there a GIMP mailing list?
10. How about an IRC channel?
11. Where can I find other GIMP stuff?
12. What books on the gimp are recommended?  Beginner and intermediate
level books would be great.
13. Is GIMP a true GNU program?
14. What is the history of GIMP?
15. What is the relationship between GNOME and GIMP?
16. What is that cute little animal's name?  Who drew him?
17. Easter eggs are fun. Does GIMP have any?

II. Hardware Support

18. Does GIMP support digital cameras?
19. Does GIMP support scanners?
20. Does GIMP support drawing tablets?

III. Installing From Source

21. I just downloaded this GIMP soure thing, and now I don't know what to
do!  Help!
22. Ok, I'm trying to compile gimp, and this `./configure' program
complains about missing or old libraries.  What gives?
22a.But I know I have the right version of libfoo!  Why can't configure
find it?

IV. Basic Usage

23. How do layers work?
23a.What are layer "masks" and how do they work?
24. How do channels work?
25. Paths?
26. Selections?
26a.What is this "Quick Mask"?
27. How can I draw basic shapes (straight line, circle, square, etc.)?
28. How can I change the color I draw in?
29. How can I change the foreground color of some text to a pattern?
30. Is it possible to align text along a curve in an image?  If so, how is
it done?
31. What does "feathering" mean?
32. What does "anti-aliasing" mean?
33. What about "subsampling"?
34. How can I make what I have selected into a separate image?
35. How can I add what I have selected into a new image?
36. How can I make part of my image transparent?
36a.How can I make all of a certain color transparent?
37. How can I do gamma correction?

V. Animation

38. Can I create animations with GIMP?
38a.Where can I find online resources/tutorials on creating animations
with GIMP?
39. What restrictions are imposed on animations created with GIMP?

VI. Plug-ins

40. What are plug-ins?
41. Where can I find new plug-ins?
41a.How can I add them to my GIMP?
42. EEEK! I downloaded the latest version of gimp, and my favorite plug-in
has dissappeared!
43. Are Photoshop Filters/Plugins supported?

VII. Scripting

44. What is Script-Fu?
44a.How does the "Xtns/Script-Fu" menu differ from the "Script-Fu" pop-up
menu?
45. Where can I learn more about it?
46. How can I find out the step-by-step process to make the logo effects
in the "Xtns/Script-Fu/Logos" menu?  I can see the resultant layer
data, but have NO idea of how to do that myself.
47. How can I call a plug-in in Script-Fu?  How about another script?
48. What in the world is a "Procedural Database Error?"
49. Is there a macro recorder that automagically creates Script-Fu scripts
for me?

VIII. Customizing GIMP

50. How can I change keybindings?
51. How can I ensure that certain of the GIMP's wind

Re: [Gimp-developer] How to Submit Fixes and Enhancements?

[Nathan Carl Summers]

On Mon, 13 Jan 2003, Kevin Myers wrote:

> Hi folks,
>
> I have a few simple enhancements bug fixes that I would like to provide for
> the GIMP, and I'm working with it enough that I anticipate more to come.
> How is the best way for me to provide these changes?  I've briefly checked
> into using CVS, but I can't figure out how to get a user ID and password for
> the real GIMP development CVS server (not the anonymous mirror).

The prefered way to submit patches is through attachments to bugs filed in
bugzilla (http://bugzilla.gimp.org).

If the maintainers like your work, they will arrange for you to get a cvs
user ID and password.

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Just managed to build HEAD GIMP with autotoolson Win32...

[Nathan Carl Summers]

On 31 Dec 2002, Sven Neumann wrote:

> Hi,
>
> Tor Lillqvist <[EMAIL PROTECTED]> writes:
>
> > Hmm. You mean libgimptool isn't really used at all currently? It would
> > be helpful to have some short READMEs in the libgimp* directories
> > (especially libgimpwidgets, libgimpproxy and libgimptool) telling what
> > the purpose of the libraries are, and what executables link to them.

> [snip]
> I think that Nathan should explain the purpose as well as the current
> state of libgimpproxy and libgimptool.

To explain the purpose of those libraries, here is a diagram:

-----
  |   gimp protocol||
  tool-safe-mode  |<-->|gimp|
  |||
-----
  plug-in process   core process

libgimptool is used by both gimp and tool-safe-mode.  It contains the
code that is used by both processes, and includes classes like
GimpToolControl.  All code in libgimptool is tool-related.

GimpTools in the core use objects like GimpDrawable and GimpDisplay that
are accessable by plug-ins through the plug-in api, but with a very
different interface.  libgimpproxy is autogenerated from parts of the
definitions of the objects in the core (to maintain binary compatiblity),
and will contain the code necessary to proxy the objects by making
appropriate calls over the pdb.

Libgimpproxy is only used by tool-safe-mode.  (FWIW, tool-safe-mode is
called that because a tool plug-in can't crash the core process.)

I put tool plug-in work on the back burner when I graduated, moved, and
got a job.  Right now I am on vacaion in another state, but when I get
back I should have some time to work on it again.  I have given up on
making UML diagrams of my plans because of the lack of any decent free UML
program.

Basically, I would create a GimpToolGUI class based loosely on
GimpDrawTool.  GimpToolCore would contain the essential stuff from
GimpTool, leaving the core-specific stuff in the GimpTool class.
Everything would be modeled on the system that Mitch designed for the
paint tools.

Rockwalrus


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] A more flexible last values system for the pdb

[Nathan Carl Summers]

Note: this message is crossposted to gimp-developer because several
developers interested in libpdb are not subscribed to libpdb-developer.
Please do not send followups to gimp-developer.

I've been thinking about a better way to implement the
RUN_WITH_LAST_VALUES functionality in libpdb.  The current method is
annoying and kludgy.  Depending on the first value passed to a procedure,
the number and meaning of the parameters change, and the scheme is not
readily generalizable.  It is also not possible for other procedures to
manipulate the values used, which would be desirable for macro recorders
and plug-in adaptors that run on multiple images.

I suggest the following:
* we add a "subfunction" field to PdbProc, which is NULL for the main
function.  The interactive version would use "interactive" for the
subfunction.

* to call a plugin interactively, first call its "interactive"
subfunction.  The "interactive" subfunction will return a list of
arguments to be used in the call to the main function.

What do you think?

Rockwalrus

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer