Re: [Gimp-developer] status report from the development branch
Hi, it's that time of the week again, so here's the weekly status report from the GIMP HEAD branch. There isn't too much exciting news this week because most of the work was done on finishing stuff started earlier. But let's see ... Mitch and me added a GimpContainerView interface that is implemented by the various container treeviews. The new GimpContainerCombobox provides a replacement for GimpContainerMenu which used to be based on the deprecated GtkOptionMenu widget. Mitch changed all those buttons in the dockables to connect to GtkActions. This makes the button sensitivity update automatically just like the menus do and it assures that clicking the buttons does exactly the same as choosing the respective item from the menus. Since this allows the buttons and the menus to share the same callbacks, it makes the code a lot cleaner. I've continued work on HIG-ifying the core. Some of the more complex dialogs will need a more thorough review though. I've also ported almost all plug-ins from GtkFileSelection to GtkFileChooser. Also HIG-ified those plug-ins while I was on it. Mitch improved configurability of the toolbox from the "Tools" dialog. I've changed all file load/save plug-ins to use the new menu registration API, changed their menu entries to be more descriptive (and translatable) and added mime-type information for most file plug-ins. The thumbnails created by GIMP now include mime type information if the file procedure used to load or save the file provided it. Mitch reenabled tearoff menus. This is probably the last regression that was introduced with the port to GtkUIManager. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 10 May 2004, at 18:49, Sven Neumann wrote: > Mitch added an option to clear the Undo history. May be useful if you > are running out of memory. This was requested in bug #136300. Cool, thanks. Sounds like a useful option. (The rest too, BTW :-)) -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
Hi, it's a week since the last report from the development branch, so I thought you'd be waiting for an update. Let's see what has happened... Mitch added an option to clear the Undo history. May be useful if you are running out of memory. This was requested in bug #136300. I've added the possibility to set the "keep-above" window manager hint for the toolbox and the dock windows (bug #131672). I started to HIG-ify the core dialogs. So far I've changed all frames to use the GimpFrame widget and I did the most important changes to the spacings in the dialogs. Since we decided to also change the label alignment, more work will be needed here. The main dialogs should probably all be reviewed. The File->New dialog (or actually the GimpTemplateEditor) is the only one so far that has undergone some more significant changes. Maurits and Brix joined the HIG-ification effort and started to work on plug-in dialogs. Mitch added a new scheme for registering menu entries from plug-ins. The new scheme is backward-compatible to the old API but it has some advantages over the old scheme. First of all, a plug-in can now register multiple menu entries for the same procedure. It registers the procedure once and gives it a name. This is represented internally as a GimpPlugInAction. Then the plug-in can register this action to the menus, in multiple places if it likes to. Combined with the placeholder feature of GtkUIManager this allows to have plug-ins in the "core" menus and in the Filters menu. This should allow us to choose more intuitive menu locations for our plug-ins. I've changed the unit system to allow pixels as an image unit. The image statusbar now has a nice little unit combobox next to the display of the cursor coordinates. The image unit can be conveniently changed from here. Some dialogs, most notably the "Scale" dialog, still need to be changed accordingly. The widget that I added for the statusbar unit selector is a prototype of a replacement widget for GimpUnitMenu. Will probably move it to libgimpwidgets later. Right now it's missing some features though. Mitch started to make the toolbox configurable. Needs code to save and load these settings as well as a more untuitive GUI. I guess you can expect this to work when I'll send the next status report... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
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] status report from the development branch
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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 4 May 2004, at 11:39, Sven Neumann wrote: > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > > (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.) > > IMHO repeating the "Scale" on the second line adds visual noise and Why? > makes it harder to understand that the two entries belong together and There are other methods of grouping controls, which are already being used, such as putting them together, aligning them the same way, et cetera. > give access to two dimensions of the same control. Please don't let us > change this. A whole lot of thought went into this, it's used > consistently and there's no compelling reason to change it. 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. I don't think that does any harm (as you mentioned, it reinforces the idea that there's a group of controls, namely 'Scale X' and 'Scale Y', that are related), but I wanted to point out that it is not as 'victimless' as you assume. So in the end you will have to make a choice between the extra mental transaction that visual noise may produce, versus the extra mental transaction that the abbreviation causes. Scale X: [ 0.00 ] Y: [ 0.00 ] vs. Scale X: [ 0.00 ] Scaly Y: [ 0.00 ] vs. +--Scale--+ | X: [ 0.00 ] | | Y: [ 0.00 ] | +-+ Each solution has its costs. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> writes: > 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.) IMHO repeating the "Scale" on the second line adds visual noise and makes it harder to understand that the two entries belong together and give access to two dimensions of the same control. Please don't let us change this. A whole lot of thought went into this, it's used consistently and there's no compelling reason to change it. If screen readers need this info, we can certainly add a hint for them using the ATK API. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
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] status report from the development branch
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. > 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
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] status report from the development branch
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. What's not yet working is global accelerators. The toolbox and the image window share accelerators already but it's not working from the dock windows yet. Mitch says we will need some ugly hacks to get it working :( In order to avoid duplications in the menu XML files, I've added some Makefile rules that call xsltproc to generate some of the XML files. So if you want to edit the menu hierarchy, keep an eye on the first lines of the XML file you are about to edit. If it's a generated file, there's a comment telling you so. You need to edit the respective foo.xml.in file then. This also means that xsltproc is now needed to build GIMP from CVS. The tarball will contain the generated files so this is solely a requirement for people who want or need to build from CVS. xsltproc is quite commonly installed nowadays and is available for Win32 as well, so I don't expect this to be a problem. Whenever you edit anything in the "menus" directory, please run 'make validate' to get your changes checked against the DTD. This ensures validity of the files which is important since GtkUIManager crashes badly on broken menu files. You need xmllint for this to work, so I strongly suggest you install that as well. 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. Of course it's not sufficient to simply replace gtk_frame_new() with gimp_frame_new(), the dialog spacings needs some adjustments as well. The dialogs may become slightly larger by this change but I think that's OK for temporary dialogs. It's a problem for permanent dialogs like the tool options though. We will probably have to come up with a more compact style for these. Jimmac and Tigert promised to do some mockups for tool options that go well with HIG compliant dialogs but are more compact than strictly following the HIG-suggested layout. We will see how this turns out... 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. Basically each plug-in dialog needs to be reviewed. Unneeded frames such as those saying "Parameter Settings" or "Preview" should probably simply be removed. Frames that do actually group controls should be changed to use the new GimpFrame widget. Separators should be replaced by empty space. The spacing of the main vbox needs to be changed to 12 pixels to clearly separate groups of controls. The dialog border width should also be 12 pixels (although I personally prefer 6 pixels, but see http://developer.gnome.org/projects/gup/hig/1.0/layout.html#window-layout-spacing). 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? 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
Sven wrote: > But it looks as if I introduced a bug when cleaning up the code and > porting to GTK+-2.4. I am classifying this one as NEEDINFO. What is the bug, please? Could you submit it to Bugzilla so that there is a place to put a fix should somebody happen to come up with one? Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > 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. Well, the plug-in that is now in CVS does support this. But it looks as if I introduced a bug when cleaning up the code and porting to GTK+-2.4. Shouldn't be hard to fix but someone needs to look at it. I mentioned this because I hope that someone else but me can have a look at this problem. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
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] status report from the development branch
Hi, although there was no sign that anyone would have cared about my last mail, here's another short status report from the HEAD branch. Perhaps this can bring the discussuib back to development since that's what this mailing list should be all about... > - Mitch is busy porting the menus to GtkUIManager and he has come a > long way already. The new system is going to be ready very soon now. This is still an ongoing effort but the new stuff looks promising. The menu XML files are all in place and so is the code that creates menus from them. What remains to be done is to adapt all callbacks to the new signatures. > - I've been working on providing a framework to migrate from the > deprecated GtkOptionMenu to GtkComboBox. The gimp_option_menu and > gimp_int_option_menu APIs have been deprecated and (almost) all code > has been ported to GimpIntCombobBox and GimpEnumComboBox. I've also > added code that provides an alternative API to libgimp/gimpmenu.h. > Not all plug-ins have been ported to this new API yet. But as soon > as this task is finished, gimp_[image|layer|channel|drawable]_menu() > will be deprecated. This is basically finished now. gimpmenu.h has been deprecated and I've also ported all plug-ins from GtkOptionMenu to GimpIntComboBox. The new API turned out to work very well and every plug-in I touched has less code now. Although I did a quick test with (almost) all plug-ins, I can't guarantee that I didn't break things. Extensive testing of the changed plug-ins will be very much appreciated. There are a few users of GtkOptionMenu left. In particular this is: (a) GimpUnitMenu (which is derived from GtkOptionMenu) (b) the Paint mode menu in the core (c) the option menus in the core that use GimpContainerMenuImpl (a) and (b) are non-trivial because GtkComboBox doesn't support separators. We might want to wait until this changes (perhaps with gtk+-2.6). I will look into addressing (c) next. > - 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] status report from the development branch
Hi, a week has gone by since GIMP 2.0.1 was released and the CVS tree was branched. Quite a few has happened since then and for all of you that aren't following development that closely, here's a short summary... - The version number has been changed to 2.1.0. We plan to have the gimp-2.2 plug-in API completely backward compatible to gimp-2.0. Nevertheless most versions have been bumped to 2.1 for now. This is to avoid confusion when both the gimp-2.0 and the development branch are installed. It does _not_ mean that you can install gimp-2.0 and gimp-2.1 into the same prefix. The two installations are _not_ disjunct, you need to keep them in separate prefixes! When we approch gimp-2.2, we will probably change most version numbers back to the GIMP API version which is 2.0. - The development branch now depends on glib >= 2.4.0, pango >= 1.4.0 and gtk+ >= 2.4.0. Whether to do this change now has been discussed on #gimp and we agreed that waiting doesn't make any sense, so we decided to do this change right now. This will give us more time to build on the possibilities opened by the gtk+-2.4 API provides. - The filechooser patch landed in CVS. This dialog will probably need some more work but it's now there for you to play with. - Mitch is busy porting the menus to GtkUIManager and he has come a long way already. The new system is going to be ready very soon now. - I've been working on providing a framework to migrate from the deprecated GtkOptionMenu to GtkComboBox. The gimp_option_menu and gimp_int_option_menu APIs have been deprecated and (almost) all code has been ported to GimpIntCombobBox and GimpEnumComboBox. I've also added code that provides an alternative API to libgimp/gimpmenu.h. Not all plug-ins have been ported to this new API yet. But as soon as this task is finished, gimp_[image|layer|channel|drawable]_menu() will be deprecated. Please note that deprecated does not mean that the functions are removed. The GIMP 2.2 plug-in API will be backward-compatible, so the deprecated API will stay. Similar to Glib and GTK+, you can define GIMP_DISABLE_DEPRECATED to have the compiler warn you when deprecated functions are being used. - The AlienMap plug-in has been removed (see bug #140079). - The GIcon plug-in has been removed (see bug #139160). - A plug-in to load and save windows icon files has been added. Please bear with me if I forgot something... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
