Notes from the Guad3c GIMP BOF session
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Notes from the Guad3c GIMP BOF session
Hi,
here are some commented notes I took on the GIMP BOF session which took place last saturday in Sevilla at the GNOME Users and Developers European Conference. This is a loose collection of random ideas and thoughts. We didn't decide on anything, we just took the opportunity to collect some ideas and discuss them...
Plug-in Previews ----------------
- Most, if not all, plug-ins should have a preview and they should share a common look and feel.
- The preview should be zoomable with the plug-in specifying the initial zoom setup (1:1 in most cases).
- The preview area should scale with the dialog.
- The zoom GUI might be copied from PS:
---------------
| |
| |
| Preview |
| |
---------------
+ 100% -
+/- are buttons for adjusting the zoom located around a label that
displays the zoom value. The value is clickable to select 100%.
The click-to-100% feature is not very intuitive, but since it's an
expert feature, it might be OK to hide it this way. Someone wanted
a way to a enter zoom value numerically, so we might want to use an
entry/spinbutton instead.
- A split mode would be handy:
-------------------
| | |
| Before | |
| | After |
| | |
-----------------
Notes from the Guad3c GIMP BOF session
salut,
Le mar 09/04/2002 à 15:42, Sven Neumann a écrit :
- Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea.
i suggest you go there :
http://catalog.com/hopkins/piemenus/ddj/piemenus.html
or just play the Sims ;)
- Clicking somewhere into the image and starting to type should create a new text layer the size of the text's bounding box. Clicking and dragging should create a new text layer the size of the dragged rectangle.
or, the size of the layer text is completly hidden to the user, and it adapts automagically when you modify the text
also, a suggestion, it would be great to be able to "group" layers, to be able to show/hide a group of layers in one click, this would be relly usefull when you are doing webdesign with dynamic elements.
a+,
Notes from the Guad3c GIMP BOF session
Hi,
Damien Genet writes:
- Clicking somewhere into the image and starting to type should create a new text layer the size of the text's bounding box. Clicking and dragging should create a new text layer the size of the dragged rectangle.
or, the size of the layer text is completly hidden to the user, and it adapts automagically when you modify the text
how can we wrap lines then if there's no given width to fit the text into?
Salut, Sven
Notes from the Guad3c GIMP BOF session
0
Notes from the Guad3c GIMP BOF session
salut,
Le mar 09/04/2002 à 16:45, Sven Neumann a écrit :
how can we wrap lines then if there's no given width to fit the text into?
right ;)
firt, my main principle was : "in fact the user don't want to see a
layer, he just want to see text"
but, this lead to interresting questions
they are (at least) two kind of text : * text like a title, where you don't want to have a fixed width (and you can always use to write on 2 lines), and just want to see "text", this the usual vision of a graphic/vector tools * multi-line text, like a paragraph, where the text wrap when the width is reached, this is the usual vision of publishing tools, and word processors
the current version of the gimp use the first one but maybe this should change fot the gimp 1.4 so the question is, which one is the most usefull for a graphic tool ?
also if the second is choosen the user would want to see a "containing block" more than a layer, ie : if he resize the width of the block, he would expect to see the text redisplayed with the new correct wrapping, this is different from a layer, where when you resize it, you just "cut" the overlapping content.
a+,
Notes from the Guad3c GIMP BOF session
0
Notes from the Guad3c GIMP BOF session
On 9 Apr 2002, Sven Neumann wrote:
Someone wanted a way to a enter zoom value numerically, so we might want to use an entry/spinbutton instead.
Seems to me that an entry/spinbutton has all the advantages of the other ui proposal with the extra advantage that you can quickly and easily go to magnifications other than 100%.
- A split mode would be handy:
-------------------
| | |
| Before | |
| | After |
| | |
-----------------
Notes from the Guad3c GIMP BOF session
On Tue, 2002-04-09 at 18:42, Stephen J Baker wrote:
The idea is that a right-click followed by a short (and easily memorized) "gesture" gets you to the menu item you want in less time than scrolling down that l-o-n-g menu.
Yeah. I actually wanted something more like 3dsmax than maya. I did a mockup last july... http://www.gnome.org/~drc/jeepo/4waymenu.png (Ignore the menu contents, they are random.)
I wanted this to be a poweruser feature. So it shouldn't be enabled my default.
Notes from the Guad3c GIMP BOF session
Hi,
Nathan C Summers writes:
- Provide an API that allows the plug-in developer to use the same function for manipulating the image as well as the preview. The preview would have to provide a drawable API and pixel-regions etc. in order to achieve this goal.
There is a serious problem here: what if two plug-ins are open at the same time and want to draw on the same image? We wouldn't just need tile-level locking but layer or image-level locking as well, and the preview widget would have to gracefully fall back or force the other plugin to give up its hold on the display. You could run into serious UI issues here.
the idea was not to use the original drawable but to have the preview create a scaled version of the selected area and expose it to the plug-in as if it was a drawable. This will need some hacks in the proxy drawable code in libgimp but I think it could be done.
Salut, Sven
Notes from the Guad3c GIMP BOF session
On Tue, Apr 09, 2002 at 03:42:31PM +0200, Sven Neumann wrote:
- Most, if not all, plug-ins should have a preview and they should share a common look and feel.
- The preview should be zoomable with the plug-in specifying the initial zoom setup (1:1 in most cases).
What about:
- left mouse click = zoom in
- middle mouse drag = move around
- right mouse click = zoom out
or use shift-left and have a little context menu with right
- A split mode would be handy:
-------------------
| | |
| Before | |
| | After |
| | |
-----------------
Notes from the Guad3c GIMP BOF session
Hi,
tino.schwarze@informatik.tu-chemnitz.de (Tino Schwarze) writes:
- The preview should be zoomable with the plug-in specifying the initial zoom setup (1:1 in most cases).
What about:
- left mouse click = zoom in
- middle mouse drag = move around
- right mouse click = zoom out
or use shift-left and have a little context menu with right
zooming by means of mouse clicks or mouse wheel is an option but there needs to be a UI that clearly indicates that you are able to zoom and how to do it. Only using the mouse w/o adding any visible UI elements is not an option from a usability point of view.
Hmm... a pretty weird preview comes to my mind. It might be difficult to implement though. The preview is not separeted into before and after views but shows one part of the image. There is an invisible borderline between before and after so that there is a transition from before- to after-image. The interesting thing is: This border-line can be rotated. You therefore have the option to have a preview like above or one separated top-bottom or diagonal - any way you like.
the original suggestion was of course to have both views (before and after) in the same drawing area and not separated. The idea to make the border-line rotatable is actually very nice and shouldn't be too hard to implement. Getting the GUI right could be difficult though.
- Alternative preview in image window would be nice to have.
Definitely. It should be toggleable from the preview widget itself. Also, the plugin has to choose in which mode to start. There are plugins for which a tiny preview is useless (e.g. global operations like brightness and contrast.)
most color corrections are implemented as tools anyway.
The preview widget also needs an option to toggle between automatic or manual preview update since there are effects which take very long to compute - even for a small preview.
ack.
Hmmm... what about embedding a real image inside the preview?
I don't understand this sentence. Could you elaborate on this?
Salut, Sven
Notes from the Guad3c GIMP BOF session
On Wed, Apr 10, 2002 at 11:47:42AM +0200, Sven Neumann wrote:
zooming by means of mouse clicks or mouse wheel is an option but there needs to be a UI that clearly indicates that you are able to zoom and how to do it. Only using the mouse w/o adding any visible UI elements is not an option from a usability point of view.
ACK.
- Alternative preview in image window would be nice to have.
Definitely. It should be toggleable from the preview widget itself. Also, the plugin has to choose in which mode to start. There are plugins for which a tiny preview is useless (e.g. global operations like brightness and contrast.)
most color corrections are implemented as tools anyway.
Which I find confusing - I stumbled acroos this yesterday. It is non-intuitive that something without a toolbox icon has Tool Options.
Hmmm... what about embedding a real image inside the preview?
I don't understand this sentence. Could you elaborate on this?
I mean: Why create proxies and stuff? Just create an appropiate GimpImage and let the plugin poke on that. I'm not very familar with the GIMP internals, but I guess we don't need to re-invent the wheel there. Using a downscaled version of the actual image allows the plugin to perform _any_ operation it can do on the original image. If there was a layer-removal plugin, the removal of a layer could be previewed.
Bye, Tino.
Notes from the Guad3c GIMP BOF session
Hi,
tino.schwarze@informatik.tu-chemnitz.de (Tino Schwarze) writes:
Hmmm... what about embedding a real image inside the preview?
I don't understand this sentence. Could you elaborate on this?
I mean: Why create proxies and stuff? Just create an appropiate GimpImage and let the plugin poke on that. I'm not very familar with the GIMP internals, but I guess we don't need to re-invent the wheel there. Using a downscaled version of the actual image allows the plugin to perform _any_ operation it can do on the original image. If there was a layer-removal plugin, the removal of a layer could be previewed.
plug-ins usually only work on a single drawable. Creating a copy of the whole image would be overkill in almost all cases. Since we want a zoomable preview, we'd even have to redo the image copy every time the zoom changes. Doing a real drawable copy would probably be a reasonable approach since the gimp core could do the scaling for us.
Salut, Sven
Notes from the Guad3c GIMP BOF session
On Tue, 2002-04-09 at 18:47, Damien Genet wrote:
they are (at least) two kind of text : * text like a title, where you don't want to have a fixed width (and you can always use to write on 2 lines), and just want to see "text", this the usual vision of a graphic/vector tools * multi-line text, like a paragraph, where the text wrap when the width is reached, this is the usual vision of publishing tools, and word processors
At GUADEC BOF we compared these two ways and found a way to implement them both.
Just by clicking the image with the texttool you'd get the first type of text field. Clicking and dragging would give you the second type, a textblock.
Both types should create a textlayer, like the dynamic text now does, and be resizeable in the same way... (compare to the discussion about resizeable layers)
Notes from the Guad3c GIMP BOF session
On Wed, 10 Apr 2002 11:58:57 +0200, "Tino Schwarze" wrote:
On Wed, Apr 10, 2002 at 11:47:42AM +0200, Sven Neumann wrote:
zooming by means of mouse clicks or mouse wheel is an option but there needs to be a UI that clearly indicates that you are able to zoom and how to do it. Only using the mouse w/o adding any visible UI elements is not an option from a usability point of view.
ACK.
This is very important and unfortunately the usability aspect "no hidden features" has been overlooked too frequently in the past. See for example: http://bugzilla.gnome.org/show_bug.cgi?id=51108 For many users, any feature that is not visible in the GUI does not exist.
most color corrections are implemented as tools anyway.
Which I find confusing - I stumbled acroos this yesterday. It is non-intuitive that something without a toolbox icon has Tool Options.
We are talking about gimp-1.3.x. In the developer's version, all tools (including color correction tools) have an icon in the toolbox. The color correction tools are now listed under "Tools" in the menus, and not anymore under "Image->Colors->..."
-Raphaël
Notes from the Guad3c GIMP BOF session
On 09 Apr 2002 15:42:31 +0200, "Sven Neumann" wrote:
- The zoom GUI might be copied from PS: ---------------
| |
| |
| Preview |
| |
---------------
+ 100% -
I like this GUI. I also like the fact that in PS (or is it in PSP?), the mouse pointer changes to a hand as soon as you move over the preview area so that the user knows that the image can be panned simply by clicking and dragging with the left mouse button. In our case, the cursor could be changed to the same crossed arrows as for the Move tool. Assigning this feature to the left mouse button implies that the default cursor can be changed (the feature would be "hidden" if another mouse button was used). Also, this preview widget is very nice because it is compact: there is no need for scrollbars because there is a visible hint (the cursor) indicating that the preview can be moved.
I am not sure that I like the idea of making the zoom ratio editable (spinbutton) because that would waste some space on the screen. Most dialogs in the GIMP are already much too large.
- A split mode would be handy:
-------------------
| | |
| Before | |
| | After |
| | |
-----------------
Notes from the Guad3c GIMP BOF session
Hi,
RaphaXl Quinet writes:
On 09 Apr 2002 15:42:31 +0200, "Sven Neumann" wrote:
- The zoom GUI might be copied from PS: ---------------
| |
| |
| Preview |
| |
---------------
+ 100% -I like this GUI. I also like the fact that in PS (or is it in PSP?), the mouse pointer changes to a hand as soon as you move over the preview area so that the user knows that the image can be panned simply by clicking and dragging with the left mouse button. In our case, the cursor could be changed to the same crossed arrows as for the Move tool. Assigning this feature to the left mouse button implies that the default cursor can be changed (the feature would be "hidden" if another mouse button was used). Also, this preview widget is very nice because it is compact: there is no need for scrollbars because there is a visible hint (the cursor) indicating that the preview can be moved.
I am not sure that I like the idea of making the zoom ratio editable (spinbutton) because that would waste some space on the screen. Most dialogs in the GIMP are already much too large.
I don't think we need to care too much about screen estate in plug-in dialogs since they are sort of modal. You open the plug-in dialog, use it and close it again. Screen estate is important for dialogs that stay open while doing other stuff. Using a spinbutton might increase the dialog's vertical size by a few pixels (if any at all), so I don't think this argument holds.
- A split mode would be handy:
-------------------
| | |
| Before | |
| | After |
| | |
-----------------
Notes from the Guad3c GIMP BOF session
sven@gimp.org (2002-04-09 at 1542.31 +0200):
- Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea.
I take he meant pie menus:
+--------------+
| \ Cut / |
| \ / |
|Paste -- Copy|
| / \ |
| / V \ |
+---+______________+---+
| \ Edit / |
|File \ / Select|
|-----___\ /___-----|
|Dialogs |--| View|
|_____---/ \---_____|
|Tools / \ Image|
| / Layers \ |
+----------------------+
Imagine the angles are more even in 8 entry one. When someone wants to select one of the 8 options, he moves the mouse in that direction, so function is performed, be it new submenu or action. This way users can do things like "up, left, left+down", or in the ASCII art, "up, right" for copy.
Problem is the limited entries you get if you want to keep "decent" angles, and thus it will go nuts when menu entries appear and disappear, like when adding plug-ins. In submenus, it can provide a way to go back or not, but in first case one dir is "wasted" and in the other a failure means a full restart.
The proposition says 4 direction... which limits things a lot, with so many functions as GIMP has it would work only as user configurable helper (thus containing only the user most used items), not as main system, IMHO.
- Replace canvas XOR drawing by something nicer. We looked at some commercial apps and found they all get problems if the background color matches the color used to preview lines/beziers etc. GIMP has this problem with gray backgrounds. Should be discussed further.
Find two formulas that never report the same result for some colours, and make then appear like ants mode, thus in at least one time interval you see something different. XOR could be one, the other could be plain "paint over". OTOH, I guess it could allow "undo" for fast updates on screen. XOR with different keys (0xF0 and 0x0F, ie)?
Text Tool
---------- Should allow multi-line text with configurable line spacing.
- Should allow to modify character-spacing for selected parts of text.
Total control of kerning, tracking and leading? Yipe! :]
- Clicking somewhere into the image and starting to type should create a new text layer the size of the text's bounding box.
Current GDynText behaviour, which is nice.
Clicking and dragging should create a new text layer the size of the dragged rectangle.
So click and drag overrides font size? Sounds like a nice way to put things in fixed places (with guides snap would be perfect).
GSR
Notes from the Guad3c GIMP BOF session
the idea was not to use the original drawable but to have the preview create a scaled version of the selected area and expose it to the plug-in as if it was a drawable. This will need some hacks in the proxy drawable code in libgimp but I think it could be done.
Oh, ok. That's a good idea. I parsed that sentence as meaing that the same function could be used to preview code in the preview widget or in the image window (like the jpeg plugin preview hack). Having multiple simultaneous previews in the same image window just wouldn't work.
Rockwalrus
The idea was also to do kind of what de jpeg plug-in does, and this will not involve any further locking, altough the behaviour seems a little strange to the user..
The way the jpeg code does it is by creating a new temporary layer on top of the layer stack. The jpeg plug-in is itself responsible for creating and deleting this layer.
The same goes for other plug-ins that should do the same (I've been playing around with this a little).
I'll illustrate what happens with some layer stacks
save as jpeg
[ background | jpeg preview ]
adjust colors in yuv space
[ background | jpeg preview | yuv preview ]
adjust jpeg parameters
[ background | yuv preview | jpeg preview ]
The previews won't interfer with each other since they only read from the original drawable. At the moment the jpeg plug-in doesn't bother about setting the current active layer (I think),.. so the active layer changes back and forth between the preview and the original.
The ability to run multiple plug-ins whilst drawing on the image,.. is kind of a usability issue anyways,.. but using preview layers won't make it worse.
-pippin