On Thu, 3 Feb 2005, Jakub Steiner wrote:

Date: Thu, 03 Feb 2005 20:57:45 +0100 From: Jakub Steiner
To: inkscape-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Cc: gimp-developer-Or+p3mSrIjqU3F2EYrvgd0D9O10f7Vne@public.gmane.org Subject: [Inkscape-devel] common interface for graphics apps on the "free desktop"

One of the good things about Adobe's product line is that they "work together". Same tasks require the same interface. Shortcuts are consistent.

On the free desktop we have two major graphics applications, Inkscape (http://www.inkscape.org) and GIMP (http://www.gimp.org). It will not be uncommon to have users needing both apps in their workflow. I hope you guys agree trying to have similar consistency helps to provide a sane user experience.

There is definately some room to improve consistancy that wont bother either project but as I'm sure you are aware Inkscape quite deliberately has a different user interface from the GIMP so hopefully we can stick to the bits everyone can agree on.

It is probably worth mentioning that Inkscape is likely to implement some form of dock to help manage the Palette windows. It is also likely in the long term that the toolbar widgets in Inkscape will become more flexible allowing a somewhat more flexible layout of the user interface.

To be specific, there are areas where GIMP & Inkscape provide similar functionality in a slightly different way. For now I will ignore the path tool.

An inconsistency that came up while I was working on something is the mouse wheel behavior. GIMP uses shift+scroll wheel to zoom, Inkscape Ctrl+mousewheel. GIMP uses Alt+mousewheel to pan horizontally, Inkscape uses Shift+mousewheel. I've filed this as http://sourceforge.net/tracker/index.php?func=detail&aid=1115612&group_id=93438&atid=604306

According to the GNOME Human Interface Guidelines Inkscape is using the preferred behaviour (and although I would need to double check I am reasonably sure this behaviour is consistant with Apple and Microsoft guidelines).

http://developer.gnome.org/projects/gup/hig/2.0/input.html#mouse-buttons Ctrl-scrollwheel-up should zoom into the window or control under the mouse pointer, and Ctrl-scrollwheel-down should zoom out. Zooming in this way should not move keyboard focus to the window or control being zoomed.

It would be cool if somebody found the motivation to write up some extension to the Gnome HIG, defining a standard behaviour for gfx apps (*hint* *hint* ;).

I do agree that a section describing how best to design Palette Dialogs is needed as they need to be compact and are quite different from the standard transient dialogs described by the current guidelines.

Sorry for cross posting, but I hope to initiate some discussion among both camps.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

(Feel free to reply to one list or both but please don't CC me)

------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Alan Horkan writes:

On Thu, 3 Feb 2005, Jakub Steiner wrote:

An inconsistency that came up while I was working on something is the mouse wheel behavior. GIMP uses shift+scroll wheel to zoom, Inkscape Ctrl+mousewheel. GIMP uses Alt+mousewheel to pan horizontally, Inkscape uses Shift+mousewheel. I've filed this as http://sourceforge.net/tracker/index.php?func=detail&aid=1115612&group_id=93438&atid=604306

Correction: GIMP uses Ctrl+wheel to pan horizontally, not Alt.

According to the GNOME Human Interface Guidelines Inkscape is using the preferred behaviour (and although I would need to double check I am reasonably sure this behaviour is consistant with Apple and Microsoft guidelines).

http://developer.gnome.org/projects/gup/hig/2.0/input.html#mouse-buttons Ctrl-scrollwheel-up should zoom into the window or control under the mouse pointer, and Ctrl-scrollwheel-down should zoom out. Zooming in this way should not move keyboard focus to the window or control being zoomed.

Perhaps we should just swap the Shift and Ctrl modifiers for display scrolling to be consistent with the HIG and across graphics apps.

ciao, --mitch

Hi,

Michael Natterer writes:

Perhaps we should just swap the Shift and Ctrl modifiers for display scrolling to be consistent with the HIG and across graphics apps.

Sounds like a good idea. Let's do this for 2.4.

Sven

------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Hi,

Alan Horkan writes:

There is definately some room to improve consistancy that wont bother either project but as I'm sure you are aware Inkscape quite deliberately has a different user interface from the GIMP so hopefully we can stick to the bits everyone can agree on.

It is probably worth mentioning that Inkscape is likely to implement some form of dock to help manage the Palette windows. It is also likely in the long term that the toolbar widgets in Inkscape will become more flexible allowing a somewhat more flexible layout of the user interface.

In the end the user interfaces will most likely converge even more. We have already reduced the amount of toplevel windows and popups and will continute to do that. As soon as we add tabbed images, we are already rather close to an MDI-alike user interface. I wouldn't object against pushing the changes even further. But it needs people who are willing and capable to work on such this.

To be specific, there are areas where GIMP & Inkscape provide similar functionality in a slightly different way. For now I will ignore the path tool.

It would beinteresting to have a comparison of the path tools in GIMP and Inkscape. There's certainly room for improvement and it would help users a lot if the two applications (and others) would behave somewhat similar.

We should also try to improve interoperability between the two apps. We already share a common format for paths, so we it should be possible to quickly exchange paths between the two apps. GIMP 2.2 supports DND for paths. Has Inkscape added support for this? What about the clipboard? We don't do copy-and-paste for paths yet, but we would definitely like to add that. Does Inkscape use the system clipboard for paths?

An inconsistency that came up while I was working on something is the mouse wheel behavior. GIMP uses shift+scroll wheel to zoom, Inkscape Ctrl+mousewheel. GIMP uses Alt+mousewheel to pan horizontally, Inkscape uses Shift+mousewheel. I've filed this as http://sourceforge.net/tracker/index.php?func=detail&aid=1115612&group_id=93438&atid=604306

GIMP in CVS now uses Ctrl+scroll wheel for zooming. Shift is being used to pan horizontally now.

Sven

------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Alan Horkan wrote:

On Thu, 3 Feb 2005, Jakub Steiner wrote:

Date: Thu, 03 Feb 2005 20:57:45 +0100 From: Jakub Steiner
To: inkscape-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Cc: gimp-developer-Or+p3mSrIjqU3F2EYrvgd0D9O10f7Vne@public.gmane.org Subject: [Inkscape-devel] common interface for graphics apps on the "free desktop"

One of the good things about Adobe's product line is that they "work together". Same tasks require the same interface. Shortcuts are consistent.

On the free desktop we have two major graphics applications, Inkscape (http://www.inkscape.org) and GIMP (http://www.gimp.org). It will not be uncommon to have users needing both apps in their workflow. I hope you guys agree trying to have similar consistency helps to provide a sane user experience.

There is definately some room to improve consistancy that wont bother either project but as I'm sure you are aware Inkscape quite deliberately has a different user interface from the GIMP so hopefully we can stick to the bits everyone can agree on.

It is probably worth mentioning that Inkscape is likely to implement some form of dock to help manage the Palette windows. It is also likely in the long term that the toolbar widgets in Inkscape will become more flexible allowing a somewhat more flexible layout of the user interface.

As someone mentioned last time this was brought up, the DTP-tool Scribus should be added to the mix, since it is the InDesign equalent of a free DTP enviorment and it would be great if they got involved in this. Inkscape has already some relations with this project. I have started to screenshot the three apps to point out small stuff that would make them work better together, but I am unsure where to post them. Would the inkscape wiki do, or should it be put on more "neutral" ground :) , like freedesktop.org?
- Andreas Nilsson

------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Sven Neumann wrote:

Michael Natterer writes:

Perhaps we should just swap the Shift and Ctrl modifiers for display scrolling to be consistent with the HIG and across graphics apps.

Sounds like a good idea. Let's do this for 2.4.

Two questions about the current GIMP behavior (unrelated to modifiers):

1: Ctrl-Scroll up/down scrolls left/right. Wouldn't scroll up/down scrolling up/down be more logical? What happens on mice with scroll wheels for left/right? Does it just work out?

2: Shift-Scroll up/down zooms in/out from the center of the image. Would it be more useful if the zoom in feature zooms at the current cursor position? Is that possible, or would it be too confusing?

Chris

------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Hi,

Christopher Curtis writes:

Two questions about the current GIMP behavior (unrelated to modifiers):

1: Ctrl-Scroll up/down scrolls left/right. Wouldn't scroll up/down scrolling up/down be more logical? What happens on mice with scroll wheels for left/right? Does it just work out?

GIMP scrolls up/down if you don't press a modifier. And yes, horizontal scroll wheel does work as expected.

2: Shift-Scroll up/down zooms in/out from the center of the image. Would it be more useful if the zoom in feature zooms at the current cursor position? Is that possible, or would it be too confusing?

That is possible and it's on the TODO for GIMP 2.4.

Sven

------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

On Thu, Feb 03, 2005 at 08:57:45PM +0100, Jakub Steiner wrote:

On the free desktop we have two major graphics applications, Inkscape (http://www.inkscape.org) and GIMP (http://www.gimp.org). It will not be uncommon to have users needing both apps in their workflow. I hope you guys agree trying to have similar consistency helps to provide a sane user experience.

People like me will be using GIMP & Inkscape simultaneously. It's _not_ about forgetting what a user has been used to in the past. Having inconsistent behavior makes one stumble in both apps.

It would be cool if somebody found the motivation to write up some extension to the Gnome HIG, defining a standard behaviour for gfx apps (*hint* *hint* ;).

I think this is an excellent idea. I would love to see this work undertaken.

It sounds like this would involve identifying menu layout, toolbar layout, keyboard accelerators, and other aspects felt important by users. Perhaps this could be done as an addendum, or placed directly into sections 4, 5, and 10.

Anyone interested in volunteering for this writing?

Bryce

------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click