Fist of all, I want to thank Peter for his excellent work. I'm glad to see that several problems of GIMP's GUI are being revisited and most of the solutions suggested will be welcome in future releases. I don't agree with #1 request, though. I know that this has been a frequent request for years, but I think it's just a matter of habit. I'm a Photoshop user, and a Gimp user, too. After a couple of days I could understand the power of floating windows. Switching between floating windows and fullscreen with F11 is fast and easy, and my workflow is far better this way.
And when I connected a second monitor it was even better. Floating windows ROCK!
Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all.
I think it would be better to improve the way those floating windows work: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) - by making toolbox and dockers dependant of the "canvas" window. As it was discussed before, this brings a new problem: where should the menu bar be placed. Of course, the document window is the most ovbious choice, but as we use floating windows, it won't be any document window when we open the program.
Maybe the best option is to create a new kind of splashscreen, where we get as options:
-Create a new image (if you choose this, the new image dialog appears, with dimensions, templates, color mode, etc.) -Open existing image/s (if you choose this, the filer appears, letting you pick an image or a group of images). Once you made your choice, the toolbox and dockers will appear along the document/s window/s.
(I'm thinking about something like the latest Adobe Premiere Pro initial screen, for instance, but in the GTK/floating windows fashion)

Another thing that was covered in your work is the use of the screen space. I agree that the current menu layout is a waste of pixels. But this is already possible to improve in Gimp using the small theme and putting the tool options panel in the docker window. This allows you to shrink the toolbox, gaining much window space. You can see a screenshot of my current tool layout in gimp using that idea here:
http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg

Well, just my two cents. Thanks again for your work!

Gez

Guillermo wrote:

Fist of all, I want to thank Peter for his excellent work. I'm glad to see that several problems of GIMP's GUI are being revisited and most of
the solutions suggested will be welcome in future releases.

you're welcome.

I don't agree with #1 request, though. I know that this has been a frequent request for years, but I think it's just a matter of habit. I'm
a Photoshop user, and a Gimp user, too. After a couple of days I could understand the power of floating windows. Switching between floating windows and fullscreen with F11 is fast and easy, and my workflow is far
better this way.
And when I connected a second monitor it was even better. Floating windows ROCK!

you do have a good point with the second monitor angle.

Although we have to primarily work for the one monitor case, creating a solution that also works great over two monitors is important.

Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all.
I think it would be better to improve the way those floating windows work:
- by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing)

I say no item in the window list. inspectors do not match users' goals, image windows do.

- by making toolbox and dockers dependant of the "canvas" window. As it was discussed before, this brings a new problem: where should the
menu bar be placed. Of course, the document window is the most ovbious choice, but as we use floating windows, it won't be any document window
when we open the program.
Maybe the best option is to create a new kind of splashscreen, where we
get as options:
-Create a new image (if you choose this, the new image dialog appears, with dimensions, templates, color mode, etc.) -Open existing image/s (if you choose this, the filer appears, letting you pick an image or a group of images). Once you made your choice, the toolbox and dockers will appear along the
document/s window/s.
(I'm thinking about something like the latest Adobe Premiere Pro initial
screen, for instance, but in the GTK/floating windows fashion)

My intuition tells me that such 'ms outlook' approach would work against the goal of GIMP being a high-end expert tool.

I am much more enthusiastic about having the tip of the day in the main window in a 'no image' situation. And to have all new tips there, that can bring experienced users to the next level.

Another thing that was covered in your work is the use of the screen space. I agree that the current menu layout is a waste of pixels. But this is already possible to improve in Gimp using the small theme and putting the tool options panel in the docker window. This allows you
to shrink the toolbox, gaining much window space. You can see a screenshot of my current tool layout in gimp using that idea here:
http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg

We are investigating in the same direction at the moment, but I cannot decide for one million users that by default they can have either the tool options, or the color specifier. So I need to look for different compromises.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote:

Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all.
I think it would be better to improve the way those floating windows work: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) - by making toolbox and dockers dependant of the "canvas" window. As it was discussed before, this brings a new problem: where should the menu bar be placed. Of course, the document window is the most ovbious choice, but as we use floating windows, it won't be any document window when we open the program.
Maybe the best option is to create a new kind of splashscreen, where we get as options:
-Create a new image (if you choose this, the new image dialog appears, with dimensions, templates, color mode, etc.) -Open existing image/s (if you choose this, the filer appears, letting you pick an image or a group of images). Once you made your choice, the toolbox and dockers will appear along the document/s window/s.
(I'm thinking about something like the latest Adobe Premiere Pro initial screen, for instance, but in the GTK/floating windows fashion)

As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed.

Another thing that was covered in your work is the use of the screen space. I agree that the current menu layout is a waste of pixels. But this is already possible to improve in Gimp using the small theme and putting the tool options panel in the docker window. This allows you to shrink the toolbox, gaining much window space. You can see a screenshot of my current tool layout in gimp using that idea here:
http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg

Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. (Personaly, I learned the shortcuts for all frequently used tools, but I still use the tool palette at times)

Thorsten wrote:

On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote:

Turning Gimp into a MDI application will make several users happy, but
IMO it won't benefit Gimp at all.

As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed.

yep.

You can see a screenshot of my current tool layout in gimp using that idea here:
http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg

Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. (Personaly, I learned the shortcuts for all frequently used tools, but I still use the tool palette at times)

Thorsten has got a point with the preferred proximity of the tool options
to the tool palette. As it looks and feels at the moment, these need to be close to each other to show their connection. One solution for this is to start tying the options to what actually gets done with the tool to the image, and start putting the options in heads-up displays near to where one is working.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Peter said:

- by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing)

I say no item in the window list. inspectors do not match users' goals, image windows do.

I meant the items in the tray bar / lower panel of the O.S. desktop. The applications listing.
Just one item "Gimp" instead of toolbox, image, docker as it appears now.

My intuition tells me that such 'ms outlook' approach would work against the goal of GIMP being a high-end expert tool.

I am much more enthusiastic about having the tip of the day in the main window in a 'no image' situation. And to have all new tips there, that can bring experienced users to the next level.

To be honest, I had that idea when I was looking Ardour and Jokosher, then I realized "hey, that's the same that the latest Adobe apps have!". It doesn't look to be working against Adobe Premiere Pro, Adobe After Effects and Adobe Encore (almost in the exact way I suggested) and Photoshop and Illustrator (in a similar way). So I'm not sure if it's incompatible with a high end, pro application. The tip of the day could be in that window too, and you'd have a great one-window solution for the whole problem. I think I should make a mockup. :-)

We are investigating in the same direction at the moment, but I cannot decide for one million users that by default they can have either the tool options, or the color specifier. So I need to look for different compromises.

Then Thorsten said this:

As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed.

And this:

Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool.

Good points.
In the ideal world, Gimp would have MDI and floating as options, and presetable layouts by default.
But we know that gimp hasn't enough developers, and this kind of features were never adopted because of that. I was myself one of the guys asking for optional MDI/Floating some time ago, and Sven replied that: every option in the preferences carry an important effort in coding as well as several changes in documentation. That's why I'm suggesting this layout chnge. It would gain much screen space without the need of much coding and documentation changes. I'm pretty sure that most of the user asking for MDI wouldn't have much problems with the layout I'm proposing. It's more "photoshop-esque", and to be honest, users who ask for MDI so frequently are doing that because of Photoshop mostly (see the "trend" point in Peter's report). Most of the users got used to the default layout maybe because never knew that it could be changed. I'd like to know how they feel about getting a 15% more of work area. Maybe there should be a poll in the website, proposing a couple of tool layouts.

Oh, and about semi-transparent toolbox and docker... it can be really tricky.
IMO, Semi transparent windows in interfaces should be avoided because it's readability depends on the contrast between the foreground and background elements. Some combinations work great, some combinations simply don't.
And when they don't, the new problem is worse than the problem that was intended to solve: a confusing mix with deficient contrast is worse than a slight obstruction.
And why not to mention that semi-transparent windows are alien to the default GTK/gnome style guidelines.

Hi,

On Sat, 2007-05-26 at 11:32 -0300, Guillermo Espertino wrote:

I meant the items in the tray bar / lower panel of the O.S. desktop. The applications listing.
Just one item "Gimp" instead of toolbox, image, docker as it appears now.

I would actually want to have toplevel image windows listed in the task bar. But I don't see a point of having a GIMP item there. Palettes like the toolbox don't show up in the task bar anyway when they are set as utility windows. You can already configure GIMP to behave this way.

Sven

On Friday 25 May 2007 21:49, Guillermo Espertino wrote:

And when I connected a second monitor it was even better. Floating windows ROCK!
Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all.

I agree 100%. I had used Photoshop on a multimonitor setup for some time before moving to GIMP and had moved the tool "windows" onto the second monitor. So when I started using GIMP I liked the way this worked from the get go. One other thing that I also like is that each image is also in it's own window which I think is better the way Phototshop does this.

Hal

Sven wrote:

I would actually want to have toplevel image windows listed in the task bar. But I don't see a point of having a GIMP item there. Palettes like the toolbox don't show up in the task bar anyway when they are set as utility windows. You can already configure GIMP to behave this way.

Oh, I didn't know that.
That's much better, but if you set both toolbox and docker as utility windows, if you haven't any image open you don't have any window listed in the taskbar nor the task switcher (alt+tab). Default behaviour clutters the taskbar and the other setting makes the application almost invisible if you refreshed the desktop using the show destop applet. I think most users see the windows listed in the taskbar as "applications running or minimized" instead of "windows". That's why I find this behaviour to be quite confusing.

----

About the "image slicing for webmasters" subject... I'm against it. Save for web is a necessary tool because is a time saver and allows to see the balance between quality and filesize, which is a must-be for web design. But slicing is a horrible methodology created for home users. A real web designer designs a wireframe and the typographic structure before the graphic stage, then designs the elements needed, using the div placement and dimensions defined in the css layout. I mean: If you completed the wireframe stage and you defined the block elements with CSS, image slicing is not necessary anymore. And in that case, the current GIMP features are more than enough. A great tool for designers would be a CSS layout importer (able to import divs containers and place them as layers with guides in the right plces). Sort of CSS-to-template. But imo, it should be a plugin, not a core function.

Hi,

On Sat, 2007-05-26 at 21:53 -0300, Guillermo Espertino wrote:

That's much better, but if you set both toolbox and docker as utility windows, if you haven't any image open you don't have any window listed in the taskbar nor the task switcher (alt+tab).

If it would work nicely, it would be the default setting.

I think most users see the windows listed in the taskbar as "applications running or minimized" instead of "windows". That's why I find this behaviour to be quite confusing.

That's nothing that the application has to worry about. Most taskbars (even on Windows) can be configured to group windows of the same application into a single item.

Sven

gg@catking.net wrote:

A great tool for designers would be a CSS layout importer (able to import divs containers and place them as layers with guides in the right plces). Sort of CSS-to-template. But imo, it should be a plugin, not a core function.

That would seem like a good idea for plugin. Could you point to some definative info on this use of CSS "div containers"? It would have to be a well defined structure in order to be able to formalise it as a plugin.

/gg

The correct way to design a webpage using XHTML+CSS is separating contents and presentation.
Contents are divided in blocks (usually divs) and line elements that are styled in a separate stylesheet.
The interfase wireframe is defined by those divs, following the W3C visual formatting model.
My idea for that plugin consists in importing those divs (which have with, height and a relative or absolute position in the document structure, and background color), into solid color layers. Once the XHTML+CSS wireframe is designed, the design of graphic elements for incusion in the DIV (images, div backgrounds or dummy texts) would be very fast to achieve, letting the designer to create a mockup in a breeze. And that fast editable mockup would be ready for exporting the slices (I know, I said slices are a bad idea, but i mean "slices" as "image blocks") for the final webpage. Slices as they are meant in Photoshop are bad because you tend to design the whole page using the incorrect application. A webpage isn't bitmap images sliced. Is hypertextual content with bitmap decorations. Photoshop makes unexperienced people think that anyone can design a website, when in reality that's not true. If we focus in the right way, we'll be focusing in creating the bitmap decorations for a specific html element instead of creating the whole mockup and automagically export it to a html page. It's ok to listen to users feature requests, but if Gimp is going to be a professional application, IMO the un-professional features shouldn't be included.

> Thanks, I'm aware of the basic principals. But if something is to be formalised into a plugin there has to be some well defined > way of working. Preferably a standard, not just a couple of jargon words like slices and wireframe.

Oh, I'm sorry, I misunderstood you. I'm not a programmer. I was rather talking as a webdesigner and focusing on what would be really useful for webdesign. In this case, the image slicing process was mentioned as one of the top user requests, so I wanted to bring my point of view about it.

Please let me know if this kind of oppinions are not appropriate for this mailing list.
I know this list is for developers, but there are other topics discussed here, like program functionalities and interface related.

Gez

/gg wrote:

There's nothing wrong with your suggesting an idea to the list.

Your input as a web designer could be relevant if you can be specific.

Can you be more precise than "wireframe"? I still dont know what you are wishing to see implemented.

Ah, Ok.
Look, I said wireframe meaning the structure of divs (with their heights, widths and background colors and relative position beetwen them) in a xhtml+css document. My idea for a plugin is to parse (i don't know if this term is correct) that information creating a new document with layers with solid fill with the same dimensions and placement that the div blocks of the source document have. So, a plugin or script for this should read the document and its css, and place the new layers in a blank image template. As a xhtml is a text file, the order of the div blocks will be consecutive. The divs with their width, height, floating and other styles related to the visual formatting model will have a class, ID or style applied to read from. The divs with other purposes (conceptual delimitation) won't, so they can be skipped. I haven't a coder background, so I cannot say how (and if it can be easy to implement or not), but I think that it's, at least, an interest idea. And it sounds logical to me.
Maybe it would be possible to use an external rendering engine (gecko or so) for translating the html elements into graphical blocks.

Gez.

/gg wrote:

These are just assumptions you are making , not a standard of any kind.

They are not just assumptions: a DIV without class or ID or style is impossible to be visually formatted. So a clean div is just for conceptual delimitation.
A DIV with one of those attributes can be -or not- visually formatted, so it depends on which css styles are applied. If you read the css information you can easily realize which are visual blocks and which are not.
And about the standard thing, just refer to the W3C's Visual Formatting Model. There you can get information on which css attributes should be considered or not.

It is a good idea in itself but since there is no fixed way this will be implemented by any web designer it's far too vague to start writing a plug-on for.

If most of the web designers out there don't follow the standards, it doesn't make my suggestion too vague. Is a standard procedure. If programs like dreamweaver or even NVU skip the standards trying to make a "user friendly program" doesn't mean that those standards don't exist.

This seems firmly outside what gimp has decided to be as an image editor.

That's why I suggest a plugin. It seems that many people asked for slicing (which isn't a standard or a fixed way to design either, because there is no fixed ways to make things in design in general) as a core function of Gimp.
I'm aganist it. So I suggested that xHTML+CSS importer plugin as an interesting approach for a similar use, but as an external, optional function.
I'm not saying "it's a must-be" and Gimp must have it by default. It's just an idea.

Thank you for your comments. Gez.

-------- Original-Nachricht -------- Datum: Tue, 29 May 2007 12:27:39 -0300 Von: Guillermo Espertino
An: g2@catking.net, gimp-developer@lists.XCF.Berkeley.EDU Betreff: Re: [Gimp-developer] xHTML+CSS importer plugin

/gg wrote:

These are just assumptions you are making , not a standard of any kind.

They are not just assumptions: a DIV without class or ID or style is impossible to be visually formatted.

You can still reach it via adjacent sibling, child or descendant selectors, or - if it does have any other attribute - an attribute selector.

Michael