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

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

Hi,

Nathan Carl Summers 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

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

Hi,

Nathan Carl Summers 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

Hi,

Nathan Carl Summers 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

Hi,

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

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

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