Gimp Traffic #15 For 24 Feb 2000

1. Save Copy As...
   with its own set of file paramaters including filename
2. Autosave
   option to save automatically at regular intervalls
3. Color History
   quick select from recent colors, either as popup menu in color section or by creating a new palette (optionally) to be saved - or both perhaps.

My first idea was to have it in the color part of the main toolbox as a pop-up menu bound to the color-buttons... Having an auto-palette that gets saved was my second idea - both appear good to me but the first option may be an inconsistent addition to the current user-interface.

I think I remember someone saying the toolbox already has too many buttons and therefore should be redesigned some day. I can't remember though if the suggested solution was by making popup boxes to more general buttons. This could make my first proposal for color history consistent with toolbox handling.

This is just something to think about if/how it would be implemented in the next version of The GIMP.

I just spoke to someone who tried to get rid of the alpha channel on their image before saving it (his gimp was pre-export stuff).

It's true that, even though I knew what I was looking for, it took me a while to find the flatten option.

The deceiving thing is that while "<Image>/Image/Alpha/Add alpha channel" exists, the corresponding "Remove alpha channel" is not on the same menu. This is deeply confusing. You have to go to the L&C dialog to get the "flatten" option. And only then, if you know what flatten does, will this make sense.

I suggest adding a "Remove alpha channel" option to the <Image>/Image/Alpha/ menu, which just calls the flatten routine.

Yes, I know this should be mostly solved with the export stuff, but there are still times when you want to get rid of an alpha channel.

Since you do not add the Alpha Channel to the image, but to a layer, the <Image>/Image/Alpha/Add Alpha Channel menu is completely misguiding.

Add Alpha Channel should be in the Layers menu and, oh, there is Flatten in there too. Surprise, surprise ;-)

That patch AS IS isn't going to work. On my system (using PrintPro/CUPS), lpstat -d -v prints out in a slightly different format:

$ lpstat -d -v
system default destination: epson
device for epson: parallel:/dev/lp0
device for epson-big: parallel:/dev/lp0
device for foo: /tmp/out
device for null: /dev/null

Note that it uses "device" rather than "system". If you want to figure out how to make it work in general, go ahead -- it's a reasonable idea for 3.0.

In the intermediate term, we're considering getting rid of all of this stuff and using some kind of printer definition dialog, partly because we haven't found any robust programmatic way of determining the list of printers on the system and partly because it's reasonable for users to want to define virtual printers with different combinations of settings. Something like that's likely to make it into 3.2 (after having been in 3.1 for a while) as part of a general overhaul of the UI.

During the make process on my Mandrake Linux 7.0 machine of Gimp 1.1.17 I received the following error.

Running Mkbootstrap for Gimp::Lib ()
chmod 644 Lib.bs
LD_RUN_PATH="/usr/local/lib/index.html" cc -o ../blib/arch/auto/Gimp/Lib/Lib.so
-shared -L/usr/local/lib -l./../../../libgimp.libs
-Lirprefix/../../libgimp -lgimp-L/usr/lib -lglib /intl/libintl.a Lib.o
cc: /intl/libintl.a: No such file or directory

I noticed this says /intl/libintl.a but no /intl directory exists on my machine and nor should it. So to test my theory I created the /intl directory and place libintl.a in /intl and ran make again. This time make continued on fine.

I thought this might be a bug. With my little bit of programming skills, I would have no idea where to begin fixing this.

Only commenting $INTLLIBS out made all perl plug-in to crash. Gimp.so needs to be linked with libintl.

** WARNING **: wire_read: unexpected EOF (plug-in crashed?)
/usr/libexec/ld-elf.so.1:
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Gimp/Gimp.so: Undefined symbol "bindtextdomain"

** WARNING **: wire_read: unexpected EOF (plug-in crashed?)

I guess you are having trouble with the anoncvs servers. There are four servers and I have the strong feeling that at least one of them is not updated any more for a couple of weeks now.

You may want to hardcode the IP of an anoncvs-server that works for you into your /etc/hosts file until this problem is solved.

Well, we're at least nominally in feature freeze for 1.2. I've seen more than enough projects boondoggle because people try to add more stuff in at the last minute and thereby delay things that I don't want to cause that to happen here. If we can ship 3.2 to high enough quality standards sufficiently far in advance of Gimp 1.2 that's fine; if not, I don't want to destabilize things further.

There has been a lot of talk on this list about not wanting to make major changes to further slow down 1.2. I happen to agree with that position. Gimp 1.2 needs to ship (IMHO), even if it isn't perfect, so we can clear the decks for 1.3. And while the print stuff is a plugin, it's close enough to core functionality (every bit as much as, say, .tif or .psd) that it needs to be responsible.

Despite this, if the gimp release management team were to announce that the Gimp 1.2 release is now scheduled for August (6 months), I would change my plans and aim for a 3.2 (or 4.0) release for early summer or thereabouts, with the GUI rewrite and all that. But that's not the announced state of affairs right now; it's claimed to be a fairly short term affair.

I didn't initially plan on 1.0 compatibility at all. However, as soon as the driver hit the street, a lot of people started asking about 1.0, and someone submitted a simple patch that worked. Whatever's going on in Gimp development land notwithstanding, there was a lot of demand to print to 3 year old printers (as opposed to the 5 year old printers that 2.0 supported). The Stylus Photo EX is now 2 generations behind the times, but right now it's about the only even remotely photo quality printer that works, and there are a lot of them around, and people really want that. If it's going to be another 6 months to a year before Gimp 1.2 comes out, then we really do need to support 1.0 with the new printers and the UI improvements that we already have. If we're a month away, then 1.0 support is less critical, but there's also no time to do serious UI work.

As for the matter of what's featureful, I guess it depends. If you have an Epson Stylus 740 or a Canon printer that isn't supported with the current release, I would venture to say that that functionality is a lot more important than the resolution info stuff, which after all does have an easy workaround and which I'm not even convinced is really that critical from anything other than a consistency standpoint. We really need core printers like the Stylus Color 740 and the Canon BJC series to work, and having really good printers like the Stylus Photo 1200 (or better yet, the 1270) work will go a long way to boosting the Gimp as a high quality graphics tool. There are already enough complaints that Linux doesn't support modern hardware, and those really need to be addressed or the Gimp will be useless for people who really want to do high end stuff such as photo manipulation.

Spinoffs such as the Ghostscript driver are probably even more important, for exactly the same reason.

Certainly the vast majority of comments we've received concern operation of specific printers rather than specific UI features, and the UI features I've heard the most about are things like CMY gamma (individual channels) and such that really matter for printing.

What WOULD help us get to 3.2 faster would be for more people here to check out 3.1 and the UI changes we've already made and give us feedback on that, and for the Gimp team itself to give us a schedule to help us plan our release timeframe. Better yet, why doesn't someone who wants this resolution stuff that badly code it up and submit it, or join our project?

as you might know that gettext solution works quite nice for GIMP itself but may cause trouble with plugins. To circumvent the problem that every plugin must have it's domain registered within the GIMP source, I'll offer you a new idea here:

0. Foreword

Basically we can't get away from gettext and switch to a better system (which would have to be written first, too) that short before a release like at the moment. Thus my goal was to change as little as possible. Like you'll see, we'll just have to add a line to every plugin outside the GIMP distribution to make this work; everything else stays the same like it is now, even the catalogs remain untouched.

1. Ideas

1.1 The config file

The current system is a very static one i.e. nothing can be changed neither without the sourcecode nor after compilation. What we need is a dynamic system to remove that deficiencies. A good way to bring some dynamic into a system is to make it configurable for example by having a config file. This configfile of course shouldn't have to be modified by an editor but automatically by the GIMP resp. libgimp.

1.2 Plugins with libgimp

To get this information in there we'll provide a funtion call in libgimp which registers the domain from the name and path the plugin CAN provide. If the domain hasn't been registered yet it'll its way into the configfile

1.3 The GIMP core

The GIMP uses the information from this file to bind the necessary catalogs to itself. To actually use this bound domains we'll have to provide a function which won't look up a message in one catalog but recurse through all of them. This function will replace the gettext call just in places where the GIMP would lookup a menuentry which is sometimes not in its own catalog.

2. Implementation

2.1 The configfile

Like all other configfiles this one will stay in ~/.gimp-<Version>. The first line contains ":gimp" to ensure that no one messed up this file. The next lines contain the name of the domain, a withespace and the location of the catalog. One catalog per line.

2.2 Plugins with libgimp

For the plugins we'll have two new functions in libgimp/gimpdomain.c which have the selfexplaining prototypes.

gimp_domain_add (gchar *)
and
gimp_domain_add_with_path (gchar *, gchar *)

Every plugin may register a domain but don't has to necessarily. The functions call another static one which checks whether the files already exists and whether the domain is already registerd. If so it won't be registered again else it will.

2.3 The GIMP core

GIMP will call initgettext() at startup which will initialise i18n if compiled with it and setup a default (and fallback) domain "gimp" and every domain that it'll read from localerc.

Every occurence of gettext which had been used to translate menunames will be changed to gimpgettext which consists of a loop which checks for a possible translation in all domains which were read from localerc. At the end GIMP'll call freegettext() to clean up everything.

3. Conclusion

This idea will cirumvent most of the problems which gettext alone just can't deal with. It's little and as such not very likely to introduce many new bugs. It would allow us to ship GIMP 1.2 with the possibility to add plugins which will also benefit from localisation without any hassle.

Patch against current CVS is appended. Please feel free to contribute further ideas and to comment this stuff.