RSS/Atom feed Twitter
Site is read-only, email is disabled

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.

19 of 20 messages available
Toggle history

Please log in to manage your subscriptions.

Notes from the Guad3c GIMP BOF session Sven Neumann 09 Apr 15:42
  Notes from the Guad3c GIMP BOF session Damien Genet 09 Apr 16:25
   Notes from the Guad3c GIMP BOF session Sven Neumann 09 Apr 16:45
    Notes from the Guad3c GIMP BOF session Damien Genet 09 Apr 17:47
     Notes from the Guad3c GIMP BOF session Jukka Rajala 10 Apr 12:56
   Notes from the Guad3c GIMP BOF session Stephen J Baker 09 Apr 17:42
    Notes from the Guad3c GIMP BOF session Mike Phillips 09 Apr 18:59
  Notes from the Guad3c GIMP BOF session Nathan C Summers 10 Apr 02:04
   Notes from the Guad3c GIMP BOF session Sven Neumann 10 Apr 10:58
  Notes from the Guad3c GIMP BOF session Tino Schwarze 10 Apr 11:25
   Notes from the Guad3c GIMP BOF session Sven Neumann 10 Apr 11:47
    Notes from the Guad3c GIMP BOF session Tino Schwarze 10 Apr 11:58
     Notes from the Guad3c GIMP BOF session Sven Neumann 10 Apr 12:56
     Notes from the Guad3c GIMP BOF session Rapha 10 Apr 13:09
  Notes from the Guad3c GIMP BOF session Rapha 10 Apr 13:41
   Notes from the Guad3c GIMP BOF session Sven Neumann 10 Apr 14:28
  Notes from the Guad3c GIMP BOF session Guillermo S. Romero / Familia Romero 10 Apr 17:25
Notes from the Guad3c GIMP BOF session Ville Pätsi 10 Apr 08:31
Pine.LNX.4.44.0204101158220... 07 Oct 20:21
  Notes from the Guad3c GIMP BOF session Øyvind Kolås 11 Apr 13:56
Sven Neumann
2002-04-09 15:42:31 UTC (almost 22 years ago)

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 |
| | |
-----------------

Damien Genet
2002-04-09 16:25:22 UTC (almost 22 years ago)

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+,

Sven Neumann
2002-04-09 16:45:06 UTC (almost 22 years ago)

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

Stephen J Baker
2002-04-09 17:42:47 UTC (almost 22 years ago)

Notes from the Guad3c GIMP BOF session

0

Damien Genet
2002-04-09 17:47:56 UTC (almost 22 years ago)

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+,

Mike Phillips
2002-04-09 18:59:19 UTC (almost 22 years ago)

Notes from the Guad3c GIMP BOF session

0

Nathan C Summers
2002-04-10 02:04:06 UTC (almost 22 years ago)

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 |
| | |
-----------------

Ville Pätsi
2002-04-10 08:31:39 UTC (almost 22 years ago)

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.

Sven Neumann
2002-04-10 10:58:18 UTC (almost 22 years ago)

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

Tino Schwarze
2002-04-10 11:25:33 UTC (almost 22 years ago)

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 |
| | |
-----------------

Sven Neumann
2002-04-10 11:47:42 UTC (almost 22 years ago)

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

Tino Schwarze
2002-04-10 11:58:57 UTC (almost 22 years ago)

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.

Sven Neumann
2002-04-10 12:56:21 UTC (almost 22 years ago)

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

Jukka Rajala
2002-04-10 12:56:26 UTC (almost 22 years ago)

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)

Rapha
2002-04-10 13:09:26 UTC (almost 22 years ago)

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

Rapha
2002-04-10 13:41:12 UTC (almost 22 years ago)

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 |
| | |
-----------------

Sven Neumann
2002-04-10 14:28:11 UTC (almost 22 years ago)

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 |
| | |
-----------------

Guillermo S. Romero / Familia Romero
2002-04-10 17:25:09 UTC (almost 22 years ago)

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

Øyvind Kolås
2002-04-11 13:56:24 UTC (almost 22 years ago)

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