My congratulations as well, great to see the release out!

From: peter sikking

From my UI-redesign point of view, we need to get GEGL and Cairo in GIMP, else there is little chance of innovation in the UI. Also what the GIMP project needs right now is a short (< 6 months) development cycle. A short-distance run to get its heart beating faster.

I agree with you. The experience of many other projects, though, shows that it is very difficult to get short release cycles with a feature- based roadmap -- the only way to do it is to do time-based releases. I would suggest, then (since getting GEGL in is the one really essential thing at this point) that the way to proceed is to make an estimate of the time it will take to do the most basic GEGL intregration, expand it by 50% (because it is good to be realistic), and set that date as a soft feature freeze, with a hard feature freeze following say 2 months later. Things that aren't ready by the designated dates must be removed until the next cycle.

(By the way, unless I am very badly mistaken, there is zero chance of doing meaningful GEGL integration on a

(I also think that the first GEGL-based release should be called 3.0.)

Best wishes,

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

peter sikking wrote:

GIMPsters,
Half of the select/crop tools is still to-be-implemented, part of it (narrow situation) needs further specification and hmmm, Cairo is introduced. I say lets finish the select/crop tools making full use cairo, like transparency.

Hello

I have already started the work on completely implementing the spec and that's what I intend to keep on doing until it's more or less completely done. I suspect making use of Cairo won't impose significant changes to the spec?

Martin Nordholts

Hi,

On Fri, 2007-10-26 at 11:02 -0700, William Skaggs wrote:

(I also think that the first GEGL-based release should be called 3.0.)

There will most likely be zero user-visible changes or new features due to the port of the core to GEGL. It would be very stupid to make that a major release. We will most likely do the switch to 3.0 only after we have completely established our new plug-in APIs and want to get rid of the old ones.

Sven

----- Original Message ----

From: peter sikking
To: Gimp Devel List
Sent: Friday, October 26, 2007 6:42:17 PM Subject: [Gimp-developer] 2.6 roadmapping, the UI part of it...

Roadmapping what over-arching UI topics will be dealt with in this release will be necessary to have UI specifications ready _before_ implementation starts. During 2.4 it has already been shown that having a UI spec encourages new developer participation and that can only be a good thing.

I think to get new developers it will be necessary to adopt a more active recruitment policy. The current plan for 2.6 is necessary but not inspiring for new developers unless they know how Gimp will benefit from this in the long run- and showing is better than telling. So: extend the roadmap to versions 2.8 and 3.0. Create convincing mockups, and post them. Then once everything is in place, go public. Send press releases to websites such as linux.com and slashdot, explain and show the planned changes, and ask for help. Paste a big "wanted" ad on the website.

Working on the problems we have easily moving the contents of selections, you pretty soon hit the floating selection mechanism. We already identified in our evaluation that as something that needs to be transformed from a headache that makes you think into something that you never notice but just works.

Just as important is the layer boundary problem - this needs to be automated. But in both cases, I think even just committing to fixing it in a future version will benefit the project. Even if nothing is visible in the 2.6 release itself.

___

I agree what Peter Sikking wrote. It seems -to my user pov- that cairo migration is something that will provide new methods for addressing some maybe menor, but longstanding UI annoyances, and it's great putting that migration in the first place of the roadmap. What I'd like to propose is a change in the UI for 2.6 (part of it is already possible with the current interface) to gain more screen space.

The first thing I make every time I have a fresh install of gimp is taking the tool options to the right docker, and made a minor reorganization of tabs. Then I can stretch the toolbox to a two-column layout so I gain a lot of screen space to work. I'd like to propose at least that change as the default panels arrangement. It gains space, and it makes the interface more familiar for people who worked with other image manipulation packages. Plus, it's a totally reversible change, that users that like the current layout can roll back.

The other part of my idea is a possible solution of the behaviour of the application when there is no image open. I developed the idea further in my blog, so I invite you to read it and tell me if this change is feasible.
http://www.blog.ohweb.com.ar/?p=59

What is not covered there, but certainly would be an interesting idea to develop, is adding to those changes an optional wrapper window for the opened documents. I wouldn't use it, but it's the number one rant about gimp's interface.
Imo, it wouldn't have too much impact in the program usage (because it would be working just as the other way, but having a wrapper window for the opened documents) so it wouldn't be a problem for documentation, for instance.
Anyway, I'm one of the guys who think it's pretty useless so I won't mind if there is no gray background :-)

Of course I don't want to go over Peter and the UI team (this proposal was already sent to the UI brainstorming blog), so I propose this for discussion and I'd really like to know what do you think about it.

Hi,

On Sat, 2007-10-27 at 15:53 -0300, Guillermo Espertino wrote:

What I'd like to propose is a change in the UI for 2.6 (part of it is already possible with the current interface) to gain more screen space.

The first thing I make every time I have a fresh install of gimp is taking the tool options to the right docker, and made a minor reorganization of tabs. Then I can stretch the toolbox to a two-column layout so I gain a lot of screen space to work. I'd like to propose at least that change as the default panels arrangement. It gains space, and it makes the interface more familiar for people who worked with other image manipulation packages. Plus, it's a totally reversible change, that users that like the current layout can roll back.

The other part of my idea is a possible solution of the behaviour of the application when there is no image open. I developed the idea further in my blog, so I invite you to read it and tell me if this change is feasible.
http://www.blog.ohweb.com.ar/?p=59

This looks pretty much like the solution that we have been discussing for quite a while already. The mockup is very nicely done also.

In general I like this change. But we absolutely need to discuss how we want to handle multiple images with this approach. Things are getting complicated as soon as you have more than one image window. You can try the "transient-docks" feature (see gimprc). It makes the toolbox and dock windows transient to the active image window. Unfortunately this approach has shown to not work well with most window managers. But perhaps this is something that can be figured out.

Sven

BTW, you can already try the unified menu if you pass the --disable-toolbox-menu option to configure. You will have to do this with a fresh installation though, or things won't work correctly.

Currently this is only done when building on OS X for the Quartz GTK+ backend. But we will want to consider making this the default for all platforms. However we then absolutely need a window to stick the menu to. This can probably best be done as outlined in your mockup.

Sven

Hi;

Great Mockup. I really like the idea.

2007/10/27, Sven Neumann :

Hi,

On Sat, 2007-10-27 at 15:53 -0300, Guillermo Espertino wrote:

In general I like this change. But we absolutely need to discuss how we want to handle multiple images with this approach. Things are getting complicated as soon as you have more than one image window. You can try the "transient-docks" feature (see gimprc). It makes the toolbox and dock windows transient to the active image window. Unfortunately this approach has shown to not work well with most window managers. But perhaps this is something that can be figured out.

Maybe the idea of "TABs" (like in Firefox) is a good solution for this. Grouping all images in Tabs can save you from the problem of many Task Bar buttons and is a "know solution" (for interface) for the most users.

Felipe:
Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at 100%) . If we use tabs we have only one image open at a time and that's mostly a problem for pros.
Another common procedure is to have two images opened and drag and drop elements (layers) from one to the other. That's not possible with gimp currently, but it would be a nice addition that would be impossible with tabs.
Imo, image windows should remain independant. I guess that there are two options to deal with the problem of the taskbar buttons. 1) As I proposed in my mockup, just make the toolbox and docker dependant of the active image.
- When there is no image open: use the splash (one button in the taskbar named GIMP)
- When there is one image open: panels attached to the image (one button in the taskbar named GIMP-[document name]) - When there is two+ images: panels attached to the focused image (one button per image in taskbar).
Pretty similar to the current behaviour, but removing the extra buttons of the panels.

2) Create (well, it's in part already done) a switcher between opened images. The problem is... where do we place it. Right now there is a button that allows to choose which of the opened images will be displayed in the panels (by default it is set to aouto). Maybe it would be nice to redesign that dialog making it more graphic, and make it work as an "opened documets switcher".

I'll try to find some convenient way to make it, but I'd love to know what the UI team think about it.

Regards, Gez.

Filipe Soares Dilly escribió:

Hi;

Great Mockup. I really like the idea.

2007/10/27, Sven Neumann >:

Hi,

On Sat, 2007-10-27 at 15:53 -0300, Guillermo Espertino wrote:

In general I like this change. But we absolutely need to discuss how we
want to handle multiple images with this approach. Things are getting complicated as soon as you have more than one image window. You can try
the "transient-docks" feature (see gimprc). It makes the toolbox and dock windows transient to the active image window. Unfortunately this approach has shown to not work well with most window managers. But perhaps this is something that can be figured out.

Maybe the idea of "TABs" (like in Firefox) is a good solution for this. Grouping all images in Tabs can save you from the problem of many Task Bar buttons and is a "know solution" (for interface) for the most users.

Guillermo Espertino writes:

Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at 100%) . If we use tabs we have only one image open at a time and that's mostly a problem for pros.

Clearly it wouldn't be good to have tabs as the only way of using multiple images. But there are lots of cases for which one tabbed image window would be great. For instance, you're editing several images from your camera. They're all the same size, you probably aren't going to be doing much with layers or separate views, and you're only going to be working with one at a time. A tabbed interface would be ideal for that.

I'd love to see tabs as an option in image windows. As with Firefox, you'd be able to choose "Open in new window" versus "Open in new tab" in the same window. And of course you'd always have the "New view" option regardless of whether you were using tabs.

Then people who only want one window (the people who ask for MDI, or who don't have window managers with multiple desktops and have trouble managing lots of windows) could put all their images in a single tabbed window. Add menu integration and a way of docking the toolbox and layers/paths/etc. dialogs, and you can get down to one window, like the MDI fans want, without having to take away the nice multiple-window multiple-view capability that current GIMP users enjoy.

Loo wrote:

I'm not a developer, but I am a pro, and I would love to see some kind of tab implimentation--as long as the individual images can be undocked or detabbed allowing more than one image open at a time. In fact, that's the most profound idea I'd read about for the UI.

Yes, sure. But detachable tabs aren't too different to the photoshop "windows in a window" approach, and maybe it's a better idea to choose that instead of tabs (for people who usually rant because Gimp UI isn't like photoshop's).
Creating a tabbed interface would require to completely transform the current one, and at that point seems to be more feasible to go with the window in window idea, and make several people happy. But personally, I think it would be nice to reach a better solution using the current floating windows. Better for the coders, who won't need to rework the UI completely, better for the existing users who are comfortable with the floating windows thing, and it is well done, better for new users who will find a different way to use an image manipulation program.
The good thing about free/open source program is innovation. Great things can appear, not just free-of-charge clones of commercial apps.

Regards, Gez

On 28/10/2007, Guillermo Espertino wrote:

1) As I proposed in my mockup, just make the toolbox and docker dependant of the active image.
- When there is no image open: use the splash (one button in the taskbar named GIMP)
- When there is one image open: panels attached to the image (one button in the taskbar named GIMP-[document name]) - When there is two+ images: panels attached to the focused image (one button per image in taskbar).
Pretty similar to the current behaviour, but removing the extra buttons of the panels.

If I understand what you mean by "attached," then if you set the docks to be "utility" windows this is the behaviour that you get already (except when no image is open). This is the setup I usually use.

2) Create (well, it's in part already done) a switcher between opened images. The problem is... where do we place it. Right now there is a button that allows to choose which of the opened images will be displayed in the panels (by default it is set to aouto). Maybe it would be nice to redesign that dialog making it more graphic, and make it work as an "opened documets switcher".

Isn't this what the "Images" dialog does? You can even set it to display as a grid without the filenames.

Henk Boom

(I apologize if this is duplicate, I used the wrong from address in my previous email so it doesn't seem to be getting accepted by the list)

On 28/10/2007, Guillermo Espertino wrote:

1) As I proposed in my mockup, just make the toolbox and docker dependant of the active image.
- When there is no image open: use the splash (one button in the taskbar named GIMP)
- When there is one image open: panels attached to the image (one button in the taskbar named GIMP-[document name]) - When there is two+ images: panels attached to the focused image (one button per image in taskbar).
Pretty similar to the current behaviour, but removing the extra buttons of the panels.

If I understand what you mean by "attached," then if you set the docks to be "utility" windows this is the behaviour that you get already (except when no image is open). This is the setup I usually use.

2) Create (well, it's in part already done) a switcher between opened images. The problem is... where do we place it. Right now there is a button that allows to choose which of the opened images will be displayed in the panels (by default it is set to aouto). Maybe it would be nice to redesign that dialog making it more graphic, and make it work as an "opened documets switcher".

Isn't this what the "Images" dialog does? You can even set it to display as a grid without the filenames.

Henk:
Yes, I knew that (both the "utility" setting and the image dialog). What I meant was to polish those two features and make them work correctly in every platform (afaik the "utility" setting seems to have some problems in windows, for instance) so can make them available as the default behavior.
When I asked Sven some time ago why the "utility" setting wasn't the default behavior, he answered that it wasn't because it didn't worked completely as intended.

I'm talking about trying to address some problems using the existing resources as much as possible, as a realistic short-term solution. Many people ask for a complete UI redesign, but I think that much can be accomplished improving the existing. I think that making this at least would move the UI some steps forward and prepare the field for further changes in the future.

Gez

Henk Boom escribió:

If I understand what you mean by "attached," then if you set the docks to be "utility" windows this is the behaviour that you get already (except when no image is open). This is the setup I usually use.
...

Isn't this what the "Images" dialog does? You can even set it to display as a grid without the filenames.

Henk Boom

Date: Sun, 28 Oct 2007 14:25:38 -0300 From: Guillermo Espertino

Loo wrote: > I'm not a developer, but I am a pro, and I would love to see some kind > of tab implimentation--as long as the individual images can be > undocked or detabbed allowing more than one image open at a time. In > fact, that's the most profound idea I'd read about for the UI. >
Yes, sure. But detachable tabs aren't too different to the photoshop "windows in a window" approach, and maybe it's a better idea to choose that instead of tabs (for people who usually rant because Gimp UI isn't like photoshop's).

Personally, I'd greatly prefer tabs to nested windows for anything like this (in general, I detest nested-window MDI interfaces for any purpose). I find the two interface paradigms completely different -- nested windows have all of the clutter problems as individual windows, without the advantages of floating windows (ability to be independently managed, using my existing window manager paradigm which may be very different from what the MDI designer selected).

My two use cases for this are:

* I have multiple photos of the same subject with slightly different composition, lighting, what have you and I want to decide which one to work on. Nested windows don't help me; I still have to hunt for the multiple images. Tabs let me easily alternate and compare the two (or more) images, at the same size and position on the screen.

* I have selected multiple photos to process sequentially. The photos aren't related, other than being part of the same job. In this case, having all of the photographs as separate tabs makes the screen a lot less cluttered than having multiple windows, whether independent or nested. It's like separate pages in a book.

I may well open extra floating windows to work on the individual images, but I don't need each image to have its own window.

There is *no* situation I can think of where I'd like to have multiple floating sub-windows within a larger workspace window.

Date: Sun, 28 Oct 2007 10:18:12 -0700 From: Akkana Peck

I'd love to see tabs as an option in image windows. As with Firefox, you'd be able to choose "Open in new window" versus "Open in new tab" in the same window. And of course you'd always have the "New view" option regardless of whether you were using tabs.

It would also be nice to be able to drag and drop tabs into other tabbed windows or onto the desktop (in which case they'd become independent windows).

Hi,

On Sun, 2007-10-28 at 15:06 -0300, Guillermo Espertino wrote:

Yes, I knew that (both the "utility" setting and the image dialog). What I meant was to polish those two features and make them work correctly in every platform (afaik the "utility" setting seems to have some problems in windows, for instance) so can make them available as the default behavior.

The problem is though that I consider it impossible to make this work on all platforms and all window managers. We couldn't even get this to work on a Linux GNOME desktop where we are dealing with a window manager that implements the EWMH spec. But please prove me wrong. I would love to find out that this is possible after all.

Sven

Hi,

On Sun, 2007-10-28 at 14:25 -0300, Guillermo Espertino wrote:

Creating a tabbed interface would require to completely transform the current one

I don't see how a tabbed image window would be difficult to implement. It would even fit nicely with your proposal.

Sven

----- Original Message ----

From: Guillermo Espertino
To: Filipe Soares Dilly
Cc: Sven Neumann ; gimp-developer@lists.xcf.berkeley.edu Sent: Sunday, October 28, 2007 6:51:58 PM Subject: Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...

Felipe: Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at

As an alternative, I'd like to suggest a UI setup I filched from Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of starting an application with just a toolbar.

here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png

After the application starts, all you see is the menu dialog at the top. It's not that different from the current setup, but a top-level "menu" is more reasonable than a top-level "toolbox". You get a single menu instead of the duplication in menus you have today (toolbox menu and image menus). You can still have the pop up dialog appear when you start Gimp, but when you close all the currently open images, you don't need to pop it up again as the menu is still there. And you can add toolbars for file operations and common dialogs.

The idea of a single menu for all open documents also solves the problem of accessing menu item on small images. Imagine you are working on 10 small web buttons at the same time - currently, either some menu items will be trimmed or you have to have an image window with a lot of padding beyond the actual image size. This way, the entire menu is always visible.

I'm not 100% supportive of it - it seems like a bit of a cludge - but it's an option.

Oh, on more thing - taskbar buttons. if this idae is considered seriously, perhaps a move to a single taskbar button for Gimp, no matter how many images are open concurrently, should be considered.

___

On Sunday, October 28, 2007, 17:51:58, Guillermo Espertino wrote:

Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at 100%) . If we use tabs we have only one image open at a time and that's mostly a problem for pros.

On the contrary, tabs would be perfect for the way I work - if I need to compare a set of images, I align their windows, then switch between them, and tabs would make this work without me having to manually align (or maximize) the windows.

However, if the tabs are implemented, I'd like to see them done the way Opera does it - it allows you to drag a tab out of the main window to have the document open in it's own (free-floating) window, or it lets you drag it to another top-level window, and "dock" it there.

Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) From: Micahel Grosberg

----- Original Message ---- > From: Guillermo Espertino
> To: Filipe Soares Dilly
> Cc: Sven Neumann ; gimp-developer@lists.xcf.berkeley.edu > Sent: Sunday, October 28, 2007 6:51:58 PM > Subject: Re: [Gimp-developer] 2.6 roadmapping, the UI part of it... >
> Felipe:
> Tabs don't work for image manipulation because is frequent to compare > between two+ images or work with two views (one zoomed and the other > at

As an alternative, I'd like to suggest a UI setup I filched from Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of starting an application with just a toolbar.

here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png

After the application starts, all you see is the menu dialog at the top. It's not that different from the current setup, but a top-level "menu" is more reasonable than a top-level "toolbox". You get a single menu instead of the duplication in menus you have today (toolbox menu and image menus). You can still have the pop up dialog appear when you start Gimp, but when you close all the currently open images, you don't need to pop it up again as the menu is still there. And you can add toolbars for file operations and common dialogs.

What image does the menu apply to? In particular, how does this work with focus strictly follows mouse?

I understand. It's clear that everyone's preference may vary on this subject:

-Photoshop users will ask for floating windows nested in a container window. -Other users will ask for tabbed windows in a single window. -Gimp orthodox users will ask for individual windows

Obviously it's impossible to please everyone. But we should look for a consistent solution that, at least, doesn't exclude completely a group of users.
Reading all the comments (including Sven's saying that tabbed windows isn't too difficult to implement) I can see that maybe a switchable interface between tabbed and floating would be the most appropriate solution. The question here is how to make them live together without damaging the UI consistency. And how to deal with some of the current problems with overlapping windows (how the utility windows obstaculize the working canvas when it is maximized, dragging the canvas beyond the image borders to avoid overlapping, etc). But tabbed windows only don't help. A tabbed window should be able to be detached as a floating window and that's were my concern is. This change (just take my idea and add tabs to the document window) may look not too radical but I'm sure that it brings some collateral risks with it that must be carefully addressed before going ahead.

I'll try to design some mockups with a possible solution, but this definitively needs the expert eye of Peter, Kamila and the UI team.

Regards, Gez.

Date: Sun, 28 Oct 2007 16:59:03 -0300 From: Guillermo Espertino

Reading all the comments (including Sven's saying that tabbed windows isn't too difficult to implement) I can see that maybe a switchable interface between tabbed and floating would be the most appropriate solution. The question here is how to make them live together without damaging the UI consistency. And how to deal with some of the current problems with overlapping windows (how the utility windows obstaculize the working canvas when it is maximized, dragging the canvas beyond the image borders to avoid overlapping, etc).

I don't think that making tabbed and floating live together is a very hard problem -- Firefox does that just fine (and it sounds like Opera does it even better).

As far as overlapping windows go, I live with it -- I use focus strictly follows mouse

On Sun, 28 Oct 2007 21:12:33 +0100, Robert Krawitz wrote:

I don't think that making tabbed and floating live together is a very hard problem -- Firefox does that just fine (and it sounds like Opera does it even better).

Not only do OPera do it better they invented tabbed browsing.

One other detail they do better than the ffx clone is defocus a tab the same way it is focused. Clicking on the tab brings it to the top , another click pushes it back. This means you can toggle two tabs' contents without moving the mouse.

This would be a good feature to implement in Gimp since it would allow comparison two images without moving the eye away from the point of interest to aim the mouse.

Now whether ffx did not copy that detail because they use gtk+ and the "widget" does not have that capability remains to be checked. (Linux Opera is qt).

regards.

--

Hi,

On Sun, 2007-10-28 at 17:06 -0300, Guillermo Espertino wrote:

Inkscape uses utility windows that aren't confined to the main window limits.

Utility windows are never confined to any window. It's just a window manager hint. And it is even clearly defined how the window manager should behave when this hint is set. If it cares at all.

http://standards.freedesktop.org/wm-spec/wm-spec-latest.html

Nevertheless, if we can make sure that there's always a leader window, then using the utility hint is going to work much better than it does currently.

Sven

On Sunday, October 28, 2007, 22:30:55, gg@catking.net wrote:

Now whether ffx did not copy that detail because they use gtk+ and the "widget" does not have that capability remains to be checked. (Linux Opera is qt).

It's probably because Opera is still MDI under the hood - it just hides this detail if you don't want it (it's possible to de-maximize the "tabs", and have them as floating windows in the container, and while Qt [and Win32] allow this natively, Opera seems to have written it's own implementation, since the behaviour is different, IMHO better than native Qt and Win32).

Sven Neumann escribió:

Nevertheless, if we can make sure that there's always a leader window, then using the utility hint is going to work much better than it does currently.

Oh, I understand.
I can see why Inkscape hasn't the same problem. But in their case they have a complete instance of the whole interface for every document opened, which is not an acceptable thing for a Gimp (well, it isn't acceptable for Inkscape either, I read that they're planning to change for a tabbed interface soon).
Thanks for the clarification.

-- I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

Gez

On 10/29/07, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

http://curlyankles.sourceforge.net/widgets_docking.html

Alexandre

On 10/28/07, Robert Krawitz wrote:

Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) From: Micahel Grosberg

As an alternative, I'd like to suggest a UI setup I filched from Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of starting an application with just a toolbar.

here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png

What image does the menu apply to? In particular, how does this work with focus strictly follows mouse?

I think the easiest way is with a "last-clicked" policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows.

Chris

Date: Sun, 28 Oct 2007 20:29:49 -0400 From: "Christopher Curtis"

On 10/28/07, Robert Krawitz wrote: > Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) > From: Micahel Grosberg
>
>> As an alternative, I'd like to suggest a UI setup I filched from >> Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of >> starting an application with just a toolbar. >>
>> here's the mockup (I made it long ago): >> http://www.geocities.com/preacher_mg/UI_gimp_menu.png >
> What image does the menu apply to? In particular, how does this work > with focus strictly follows mouse?

I think the easiest way is with a "last-clicked" policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows.

So then what happens if I'm using focus strictly follows mouse and I put the mouse over another window (giving it focus)? What if I don't click in the window, but do type a key (select a tool, for example)?

Personally I prefer having the menu bar on each image window. It sounds like this proposal would work well for click to focus, but not so well for focus follows mouse and particularly not for focus strictly follows mouse (where taking the mouse out of a window removes focus from that window even if the mouse is over the desktop).

On 10/29/07, Alexandre Prokoudine wrote:

On 10/29/07, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

http://curlyankles.sourceforge.net/widgets_docking.html

Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.)

Date: Mon, 29 Oct 2007 11:34:54 +1030 From: "David Gowers"

On 10/29/07, Alexandre Prokoudine wrote: > On 10/29/07, Guillermo Espertino wrote: >
> > I looked at Opera, as it has been suggested here. It has very good > > options for managing tabs (manage different views and make tiles or > > cascades for multiple views, detach windows from the tabbed environment, > > etc.)
> > I have to agree that it seems pretty convenient for GIMP. > > Now, the question is, as gg pointed out, if GTK allows that kind of > > solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. >
> http://curlyankles.sourceforge.net/widgets_docking.html

Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.)

I'd rather not have that kind of "auto-raise", but there's a Firefox extension named "Tab Scope" that shows previews (pop-up thumbnails) of a tab when the tab is moused over. That is very useful.

Hi,
ccurtis0@gmail.com (2007-10-28 at 2029.49 -0400):

On 10/28/07, Robert Krawitz wrote:

Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) From: Micahel Grosberg

As an alternative, I'd like to suggest a UI setup I filched from Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of starting an application with just a toolbar.

here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png

What image does the menu apply to? In particular, how does this work with focus strictly follows mouse?

I think the easiest way is with a "last-clicked" policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows.

For now "focus follows mouse" worked acceptably with click or keypress anywhere in the image (mod keys like control were enough) to select which will the layer stack show, for example.

It makes the system slightly "click to focus", but still acceptable IMO. Personally that is what I do, as one hand is normally near the mod keys already, and I am sure it is unable to trigger anything like click or drag could do, so a quick shake of mouse and press & release key goes fine (target is as big as the window, bad side effects zero).

Part of the reason it also works is the fact there is a clear display of what is going on (selector changes and so does the layer stack), so maybe the menu window should show such info too.

GSR

Hi,

On Sun, 2007-10-28 at 19:20 -0300, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this?

gedit would be an example of a GTK+ application that uses tabs to handle multiple documents.

Sven

Hi,

Sven Neumann escribió:

Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this?

Yes, we're talking about two different things :-) I meant detachable tabs and different views like Opera's or Scribus' ones. Not JUST tabs.
I (and as far as I could understand the other people that mentioned Opera) was talking about the ability to show the tabbed windows as tileable windows in the workspace (QT and Windows have that kind of options for child windows).
That is important when you need to have side by side comparisions of different images (examples of this are grading and gama matching, two views at different zoom ratios, etc.)

Is that possible with the current GTK widgets?

Gez.

Hi,

On Mon, 2007-10-29 at 04:47 -0300, Guillermo Espertino wrote:

Yes, we're talking about two different things :-) I meant detachable tabs and different views like Opera's or Scribus' ones. Not JUST tabs.

How is that different? We already have detachable tabs in the GIMP user interface. So why are you asking if this is possible?

Making it possible to have several images in one image window using tabs would be a nice improvement, IMO. It needs some thoughts on the details but perhaps this can be done off-list to that we can concentrate on getting the roadmap for 2.6 done?

Sven

On Mon, 29 Oct 2007 08:30:53 +0100, Sven Neumann wrote:

Hi,

On Sun, 2007-10-28 at 19:20 -0300, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this?

gedit would be an example of a GTK+ application that uses tabs to handle multiple documents.

Sven

Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence.

Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away.

/gg

On Mon, 2007-10-29 at 11:34 +1030, David Gowers wrote:

On 10/29/07, Alexandre Prokoudine wrote:

On 10/29/07, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

http://curlyankles.sourceforge.net/widgets_docking.html

Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.)

Gimp 2.4 already does that.

ciao, --mitch

Date: Mon, 29 Oct 2007 09:40:45 +0100 From: gg@catking.net

Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence.

Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away.

There's a Mozilla Firefox extension that does this. Mozilla extensions don't make direct GTK+ calls (as far as I know), but evidently it's possible for Firefox to know that someone has clicked on the current tab.

On 10/29/07, Michael Natterer wrote:

On Mon, 2007-10-29 at 11:34 +1030, David Gowers wrote:

On 10/29/07, Alexandre Prokoudine wrote:

On 10/29/07, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

http://curlyankles.sourceforge.net/widgets_docking.html

Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.)

Gimp 2.4 already does that.

How? Where?
I'm currently using 2.4-rc3; it does not happen here. If i hover over a tab, it just shows a tooltip, never makes that tab active.

ciao,
--mitch

What Mitch is referring to is that tabs are raised when doing drag-n-drops. I wish to thank Mitch for his brilliant implementation of this at the last minute of the 2.4 release. This functionality is already extremely useful for d-n-d'ing colors, channels, and layers between tabs and would also be necessary if GIMP provided tabbed image interface.

-------------

Though this discussion of UI issues is academically interesting (and will eventually prove fruitful), if GEGL is to be integrated into GIMP then that needs to be the primary focus for the next version. Potential developers will not be interested in spending a month of Sundays learning and programming for a system which is soon to be deprecated, requiring that their efforts be duplicated in the future or obviated completely.

Attracting users with alternative UIs or the concerns of "graphics professionals" will not mean more developers. Having a stable structure to the representation and access of GIMP's internal image data is a necessary precursor to attracting developers.

If GEGL can be integrated in less time than "GEGL + something else" then, unless "something else" can be justified as being more efficiently implemented at the same time, "something else" needs to be considered ancillary to GEGL integration.

========================== Quoting David Gowers:

GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.)

Quoting Michael Natterer:

Gimp 2.4 already does that.

Quoting David Gowers:

How? Where?
I'm currently using 2.4-rc3; it does not happen here. If i hover over a tab, it just shows a tooltip, never makes that tab active.

On Mon, 2007-10-29 at 22:01 +1030, David Gowers wrote:

On 10/29/07, Michael Natterer wrote:

On Mon, 2007-10-29 at 11:34 +1030, David Gowers wrote:

On 10/29/07, Alexandre Prokoudine wrote:

On 10/29/07, Guillermo Espertino wrote:

I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.)
I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't.

http://curlyankles.sourceforge.net/widgets_docking.html

Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.)

Gimp 2.4 already does that.

How? Where?
I'm currently using 2.4-rc3; it does not happen here. If i hover over a tab, it just shows a tooltip, never makes that tab active.

As Saul already responded that happens only if you use DND. Why on earth would a UI control activate just because you hover some seconds over it? That strikes me as utterly useless, what's the problem with pressing the mouse button if it is not otherwise occupied (e.g. by doing DND).

ciao, --mitch

On 10/28/07, Robert Krawitz wrote:

From: "Christopher Curtis"
> From: Micahel Grosberg
>> here's the mockup (I made it long ago): >> http://www.geocities.com/preacher_mg/UI_gimp_menu.png

I think the easiest way is with a "last-clicked" policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows.

So then what happens if I'm using focus strictly follows mouse and I put the mouse over another window (giving it focus)? What if I don't click in the window, but do type a key (select a tool, for example)?

Don't focus on the word 'click'. This has nothing to do with pointer focus. It's simply that the menu applies to the last image you did something with. And when you read "did something with", think "clicked on" and not "moved mouse over". Changing a tool or tool option does not change what image you're working on. The GIMP already does something similar with the layers dialog.

Chris

On Mon, 29 Oct 2007 12:28:07 +0100, Robert Krawitz wrote:

Date: Mon, 29 Oct 2007 09:40:45 +0100 From: gg@catking.net

Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence.

Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away.

There's a Mozilla Firefox extension that does this. Mozilla extensions don't make direct GTK+ calls (as far as I know), but evidently it's possible for Firefox to know that someone has clicked on the current tab.

Many thanks, I misunderstood your previous comment.

this is good news in several ways.

1. I can get ffx to do this as well , it's the sort of feature that you rely on after a while and miss badly.

2. Presumably Gimp can do the same sort of trick using std GTK+ widgets.

3. The code should be available as an example to make implentation simple and quick.

regards.

Hi!

On Sunday 28 October 2007, gg@catking.net wrote:

On Sun, 28 Oct 2007 21:12:33 +0100, Robert Krawitz

wrote:

I don't think that making tabbed and floating live together is a very hard problem -- Firefox does that just fine (and it sounds like Opera does it even better).

Not only do OPera do it better they invented tabbed browsing.

No they didn't:

* http://en.wikipedia.org/wiki/Tabbed_document_interface

* http://weblogs.mozillazine.org/asa/archives/008433.html

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

I'm not an actor - I just play one on T.V.

Sven Neumann escribió:

How is that different? We already have detachable tabs in the GIMP user interface. So why are you asking if this is possible?

Sven:
http://www.ohweb.com.ar/screenshots/Opera-tabs.png I know there are tabs wich are detachable already. I was talking about the way that Opera as well as QT apps can manage different views of the tabbed windows.
In Firefox you have tabbed windows or a new window (with the whole chrome and buttons). In QT apps and Opera you can do the same, but also you can display views of the tabbed windos (as cascade or tiles). That results in a sort of window in window interface. That's what I asking if it is possible in GTK. Not just the tabs. That's why Alexandre posted the link to CurlyAnkles too.

Making it possible to have several images in one image window using tabs would be a nice improvement, IMO. It needs some thoughts on the details but perhaps this can be done off-list to that we can concentrate on getting the roadmap for 2.6 done?

Ok, let's follow it in the IRC channel.

Hi,

On Mon, 2007-10-29 at 09:40 +0100, gg@catking.net wrote:

Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence.

The discussion of how exactly a widget should behave is out of scope here. At this point we are trying to get an idea of the goals we want to set for 2.6. Details will be discussed by the UI designers who take the job of creating and writing down the spec for this particular task.

Sven

Hi,

On Mon, 2007-10-29 at 08:52 -0400, saulgoode@flashingtwelve.brickfilms.com wrote:

Though this discussion of UI issues is academically interesting (and will eventually prove fruitful), if GEGL is to be integrated into GIMP then that needs to be the primary focus for the next version.

Integrating GEGL is a job for not more than one or two developers and it is extremely local, at least in the first step that is planned for 2.6. We should definitely use this time to also work on other areas.

Sven

On Monday, October 29, 2007, 14:15:28, Michael Natterer wrote:

As Saul already responded that happens only if you use DND. Why on earth would a UI control activate just because you hover some seconds over it? That strikes me as utterly useless, what's the problem with pressing the mouse button if it is not otherwise occupied (e.g. by doing DND).

Hey, if people are selling extensions for popular programs that do exactly that, why wouldn't GIMP do it for free?

On 10/30/07, jernej@ena.si wrote:

On Monday, October 29, 2007, 14:15:28, Michael Natterer wrote:

As Saul already responded that happens only if you use DND. Why on earth would a UI control activate just because you hover some seconds over it? That strikes me as utterly useless, what's the problem with pressing the mouse button if it is not otherwise occupied (e.g. by doing DND).

It allows more casual inspection of tabs (move move move, not move click move click), and works particularly well with vertically-stacked tabs or tabs whose content is in a folded away NoteBook. I regard it as useful for inspectors, such as the Cursor tab and Histogram tab, that I do tend to check casually, and selectors, such as brushes, patterns, and brush editor, that can be used casually.

Of the seven tabs I have docked to the toolbox, three (palette editor, pattern selector, brush selector) would be useful to access in this way.

Ideally, each could be a fold-out window (like tooltips), which would be accessed by hovering or clicking on an icon, rather than blocking other dockables that *should* remain visible (eg. Colors, Layers).

If tabs could behave in this way, trying to avoid covering the dockbook they are expanded from, and automatically reset to the previously selected tab when done, this would work rather neatly.

Guillermo Espertino wrote:

I understand. It's clear that everyone's preference may vary on this subject:

-Photoshop users will ask for floating windows nested in a container window.

They ask for an MDI structure because that's what they know, but I suspect they'll be happy with any solution to their problem that works well.

All Mac software ported to Windows uses the parent window model because - I suspect - it's the simplest solution to the "where goes the omni-present menu bar?" problem. You put it at the top of an omni-present window that has to be maximised and you've got a makeshift Mac desktop. It's not elegant and it usually doesn't work very well (see Photoshop pre CS2 for details). Most (if not all) Unix WMs already share MS Windows's behaviour of every window containing its own menu bar, so why try and solve a problem that's already fixed?

Windows users hate the Gimp's current layout because it forces them to work using scaled windows. Windows users like to maximise *everything*, in case you hadn't noticed. I wouldn't be surprised if a large fraction of Windows/Gimp users maximise their canvases and then use alt-tab to access their tool dialogues. It also doesn't help that the default layout is very hungry of space. The first thing I do after installing Gimp is to reduce the size of the toolbox to something that leaves some room on my screen.

I think your own mock-up is a far superior solution to an MDI layout, especially if slave windows could be rolled up or otherwise made invisible. It allows one to work full screen, removes the confusing CDI structure and also reduces the problem of task bar clutter. I also think that extending the tool dialogue's tabbing feature to the canvas windows would be very natural and help the clutter problem as well. You could have several canvas windows each containing many images in tabs. You could even go as far as allowing tabs to be moved between the tool dialogues and canvas windows so that an overview could be nested directly beneath the layers tab, for example.

I'd address the short comings in GIMP's window implementation first and then see if MDI is actually still demanded before thinking about implementing it. Of course, you'll always get some criticism, but I think the majority would be satisfied with a solution that works, even if it isn't like how PS does it.

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

On Oct 30, 2007, at 2:44 PM, David Marrs wrote:

They ask for an MDI structure because that's what they know, but I suspect
they'll be happy with any solution to their problem that works well.

I believe that the main reason is legacy behavior from Windows 3.x.

As I've mentioned before, Microsoft officially deprecated the MDI approach with the introduction of Windows95, but allowed existing apps to be grandfathered in.

So I think your assessment is correct. They ask for what they are used to, and aren't aware of alternatives.

On Oct 28, 2007, at 11:49 AM, Sven Neumann wrote:

On Sun, 2007-10-28 at 15:06 -0300, Guillermo Espertino wrote:

Yes, I knew that (both the "utility" setting and the image dialog). What I meant was to polish those two features and make them work correctly in every platform (afaik the "utility" setting seems to have
some problems in windows, for instance) so can make them available as the default behavior.

The problem is though that I consider it impossible to make this work on
all platforms and all window managers. We couldn't even get this to work
on a Linux GNOME desktop where we are dealing with a window manager that
implements the EWMH spec. But please prove me wrong. I would love to find out that this is possible after all.

I know this is one thing we've been fighting with for quite some time with Inkscape. If someone is willing to look into it on the GIMP side of things, I would very much like to coordinate effort.

We've had bits and pieces of progress over the last release or so, but working together can help fix things sooner.

Date: Tue, 30 Oct 2007 21:44:56 +0000 From: David Marrs

All Mac software ported to Windows uses the parent window model because - I suspect - it's the simplest solution to the "where goes the omni-present menu bar?" problem. You put it at the top of an omni-present window that has to be maximised and you've got a makeshift Mac desktop. It's not elegant and it usually doesn't work very well (see Photoshop pre CS2 for details). Most (if not all) Unix WMs already share MS Windows's behaviour of every window containing its own menu bar, so why try and solve a problem that's already fixed?

Windows users hate the Gimp's current layout because it forces them to work using scaled windows. Windows users like to maximise *everything*, in case you hadn't noticed. I wouldn't be surprised if a large fraction of Windows/Gimp users maximise their canvases and then use alt-tab to access their tool dialogues. It also doesn't help that the default layout is very hungry of space. The first thing I do after installing Gimp is to reduce the size of the toolbox to something that leaves some room on my screen.

I think your own mock-up is a far superior solution to an MDI layout, especially if slave windows could be rolled up or otherwise made invisible. It allows one to work full screen, removes the confusing CDI structure and also reduces the problem of task bar clutter. I also think that extending the tool dialogue's tabbing feature to the canvas windows would be very natural and help the clutter problem as well. You could have several canvas windows each containing many images in tabs. You could even go as far as allowing tabs to be moved between the tool dialogues and canvas windows so that an overview could be nested directly beneath the layers tab, for example.

As long as we're talking about all this, I'd rather see things go the other way -- each image has its own toolbox, set of dialogs (perhaps in a sidebar, or as slide-outs or slide-ins), etc.

Let's take layers as an example (because this is one of the more annoying ones to me). Having only one layers dialog has two undesirable consequences:

1) I can only see the layer stack of one image at a time.

2) If I move the mouse from one image to another (even if the mouse is in transit), GIMP switches which image's layers are displayed.

One way of looking at this is that this is a problem with focus follows mouse (actually focus strictly follows mouse in my case, but I don't think that that matters here). The other way of looking at it is that this is a problem with dialogs that are related to a document being shared between multiple documents, so there's only one "active" document at a time.

My preferred way of working is to have lots of open windows at a time. Sometimes a window that I'm working in at the moment (emphasis on "at the moment" -- I don't really have a notion of "this is what I'm working on now", I jump around between things) may be partially obscured by another window, but that's how I like it. I do use multiple virtual desktops, but not in a very organized way. I rely on screen real estate (currently 1600x1200 on my laptop, and 1920x1200 on my desktop except when I bring the LCD upstairs and stick it on my laptop to get 1920x1200). I'll be a good candidate for QXGA or even HXGA when it becomes affordable -- it will just give me that much more space to expand my clutter onto.

I personally do not like the Macintosh interface one bit -- it gets all the key interfaces wrong for the way I work. At least to me, it emphasizes that there's one thing that it expects you to be working on at a time (click to focus and raise rather does that, especially combined with the single menu bar that's tied to whichever application is "active" at the time), and that one thing is front and center no matter what.

Be all that as it may, I suspect that having separate layers, channels, etc. dialogs for each image might be very attractive in a lot of cases, but it's not going to be to everyone's taste.

Hi,

On Tue, 2007-10-30 at 21:59 -0400, Robert Krawitz wrote:

Let's take layers as an example (because this is one of the more annoying ones to me). Having only one layers dialog has two undesirable consequences:

For the rare cases where you need more than one Layers dialog, you can open a second (or even a third one). At least currently GIMP doesn't keep you from doing that.

Sven

Hi Jon,

On Tue, 2007-10-30 at 17:10 -0700, Jon A. Cruz wrote:

I know this is one thing we've been fighting with for quite some time with Inkscape. If someone is willing to look into it on the GIMP side of things, I would very much like to coordinate effort.

It would probably help if you could describe exactly what Inkscape is doing, both from a user interface point of view and from the developer's point of view.

I looked at the Inkscape code some time ago and implemented something similar in GIMP (see
http://svenfoo.geekheim.de/index.php/2005-05-12/transient-docks/). It doesn't work so well, but that is mainly due to the lack of a leader window when no image is opened.

I suspect though that the approach of using transparent windows violates too many assumptions made by the authors of window managers and it certainly feels like an abuse. And it will almost certainly lead to problems on other platforms where transient windows are either not implemented at all or implemented with slightly different semantics.

Sven

On 10/28/07, Akkana Peck wrote:

Guillermo Espertino writes:

Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at 100%) . If we use tabs we have only one image open at a time and that's mostly a problem for pros.

Clearly it wouldn't be good to have tabs as the only way of using multiple images. But there are lots of cases for which one tabbed image window would be great. For instance, you're editing several images from your camera.

I completely agree. Though I love the SDI for most other purposes, I have felt the need for such an optional tabbed window for images.

vote = vote + 1

There are flexible layout options for almost all dialogs. For almost all dialogs you have these option:
1) Show it a seperate window.
2) "Snap" it under/over another dialog. 3) "Snap" it along another dialog as another tab.

You can also pull a tabbed dialog out and make it a window .. and I can go on with more options currently possible for dialogs.

Now why not have these same options for Image windows? It is your choice what you want to do. I nice feature as a side effect would be "Open all images in directory in tabs". We can have as many "Image container" dialogs as we want.

Other UI features I would love in 2.6: 1. Save project / Open project.
2. Side panel toolbar. - why not have the toolbar in the image window like the mozilla's/konquerer's side panel.

From: Sven Neumann
Date: Wed, 31 Oct 2007 08:54:11 +0100

On Tue, 2007-10-30 at 21:59 -0400, Robert Krawitz wrote:

> Let's take layers as an example (because this is one of the more > annoying ones to me). Having only one layers dialog has two > undesirable consequences:

For the rare cases where you need more than one Layers dialog, you can open a second (or even a third one). At least currently GIMP doesn't keep you from doing that.

Using 2.4.0, I tried opening three images, and typing ctrl-L in each to open a layers dialog. It only opened the one dialog (and again, as soon as I move the mouse into one of the images, the image in the layers dialog changes).

Nor was I able to do it from either the file menu on the toolbox or the dialogs menu on the images.

On Wed, 2007-10-31 at 07:20 -0400, Robert Krawitz wrote:

Using 2.4.0, I tried opening three images, and typing ctrl-L in each to open a layers dialog. It only opened the one dialog (and again, as soon as I move the mouse into one of the images, the image in the layers dialog changes).

Ctr-l or menu does not open another layers dialog, true. Do you see the "Auto" button next to the image list menu-box ...?

Nor was I able to do it from either the file menu on the toolbox or the dialogs menu on the images.

It can be done from the tab menu -> Add Tab -> Layers.

Anyway, I see two approaches for dealing with the image / layers (or similar dialog) relation:
- Always attach everything relating to just one image to its image window
- Use inspectors like now

The former has the potential to be less confusing and would make showing several layer stacks straightforward. Size requirements for an image and its layer stack might be quite different, though.

-- Thorsten Wilms

thorwil's design for free software: http://thorwil.wordpress.com/

Quoting Robert Krawitz :

From: Sven Neumann

For the rare cases where you need more than one Layers dialog, you can open a second (or even a third one). At least currently GIMP doesn't keep you from doing that.

Using 2.4.0, I tried opening three images, and typing ctrl-L in each to open a layers dialog. It only opened the one dialog (and again, as soon as I move the mouse into one of the images, the image in the layers dialog changes).

Nor was I able to do it from either the file menu on the toolbox or the dialogs menu on the images.

All of the tabs in a particular dock are associated with the same image. If you change the image that is associated with the dock (either through a change in focus or explicitly in the 'Image Selection' drop-down), each of the dialog tabs of that dock are updated with the corresponding information. If you add an additional Layers tab to a dock, it would end up being just a mirror of the original Layers tab because it is associated with the same image.

However, if you place that second Layers dialog in a different dock, the other dock can be associated with a different image from the original dock.

To create a second Layers dialog, use the "Add Tab->Layers" command in your Layers window's menu and then drag the newly created tab off the dock. Alternately, you could create your new dock by opening any dialog which is not already open (for example, using "/Dialogs->Histogram"), and perform the "Add Tab->Layers" in that new dock. You will want to configure the new dock so that the "Image Selection" drop down is visible and not set to Auto.

From: Thorten Wilms
Date: Wed, 31 Oct 2007 13:10:31 +0100

On Wed, 2007-10-31 at 07:20 -0400, Robert Krawitz wrote:

> Using 2.4.0, I tried opening three images, and typing ctrl-L in each > to open a layers dialog. It only opened the one dialog (and again, as > soon as I move the mouse into one of the images, the image in the > layers dialog changes).

Ctr-l or menu does not open another layers dialog, true. Do you see the "Auto" button next to the image list menu-box ...?

I never knew about that, actually. Unfortunately, the resulting Layers dialog doesn't say which image it's attached to.

> Nor was I able to do it from either the file menu on the toolbox or > the dialogs menu on the images.

It can be done from the tab menu -> Add Tab -> Layers.

It works, although it's a bit obscure (you have to know two relatively obscure things to get there).

Anyway, I see two approaches for dealing with the image / layers (or similar dialog) relation:
- Always attach everything relating to just one image to its image window
- Use inspectors like now

The former has the potential to be less confusing and would make showing several layer stacks straightforward. Size requirements for an image and its layer stack might be quite different, though.

Like I said, when I can afford it, QXGA time...

Flash has relative ability.
You can choose to see "Library" of active document or any other open documents via combobox on Library panel. Panel also has "Pin current library" button and "New library panel" button. http://livedocs.adobe.com/flash/9.0/UsingFlash/help.html?content=WSd60f23110762d6b883b18f10cb1fe1af6-7f4e.html

31.10.07, 15:35, Robert Krawitz (rlk@alum.mit.edu):

From: Thorten Wilms
Date: Wed, 31 Oct 2007 13:10:31 +0100 On Wed, 2007-10-31 at 07:20 -0400, Robert Krawitz wrote: > Using 2.4.0, I tried opening three images, and typing ctrl-L in each > to open a layers dialog. It only opened the one dialog (and again, as > soon as I move the mouse into one of the images, the image in the > layers dialog changes).
Ctr-l or menu does not open another layers dialog, true. Do you see the "Auto" button next to the image list menu-box ...? I never knew about that, actually. Unfortunately, the resulting Layers dialog doesn't say which image it's attached to. > Nor was I able to do it from either the file menu on the toolbox or > the dialogs menu on the images. It can be done from the tab menu -> Add Tab -> Layers. It works, although it's a bit obscure (you have to know two relatively obscure things to get there).
Anyway, I see two approaches for dealing with the image / layers (or similar dialog) relation:
- Always attach everything relating to just one image to its image window
- Use inspectors like now
The former has the potential to be less confusing and would make showing several layer stacks straightforward. Size requirements for an image and its layer stack might be quite different, though. Like I said, when I can afford it, QXGA time...

Hi,

note that this really doesn't belong here. This discussion should have long been ended. But I'll explain it anyway...

On Wed, 2007-10-31 at 07:20 -0400, Robert Krawitz wrote:

Using 2.4.0, I tried opening three images, and typing ctrl-L in each to open a layers dialog. It only opened the one dialog

It would be very akward if it always opened a new one. Being able to bring the layers dialog to front using Ctrl-L is very important.

(and again, as
soon as I move the mouse into one of the images, the image in the layers dialog changes).

The dialog follows the active image since that's what you configured it to do. If you don't want it to do this, then untoggle the button labelled "Auto" next to the Image menu.

Nor was I able to do it from either the file menu on the toolbox or the dialogs menu on the images.

Try from the "Add Tab" menu as found in the menu of each dockable.

Sven