Re: [Gimp-developer] 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 -- .~.The mind is its own place,and in http://hnb.sf.net/ /v\itself can make a Heaven of Hell http://hal9001.2y.net/ /(_)\ a Hell of Heaven. - John Milton ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
On 10 Apr 2002, Sven Neumann wrote: > Hi, > > Nathan C Summers <[EMAIL PROTECTED]> 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. 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Hi, RaphaXl Quinet <[EMAIL PROTECTED]> writes: > On 09 Apr 2002 15:42:31 +0200, "Sven Neumann" <[EMAIL PROTECTED]> 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 | > > ||| > > --- > > Alternative setups like top/bottom, diagonal split have been > > suggested. Difficult to get this integrated into the GUI w/o > > cluttering it with buttons. Could be in a right-click menu, but > > it would probably not be found there. > > This could be nice, but I am not sure that it would be worth the effort > (and again, the wasted space). How many plug-ins would really benefit > from such a preview? In most cases, looking at the window containing > the original image should be sufficient (assuming that the preview is > located in one corner of the plug-in dialog, so that it is easy to put > one window over the other one and compare their contents). I am not > really against it, but I think that it should not be enabled by default > and I would like some examples of plug-ins for which this feature could > be useful. probably my ascii drawing was a bit misleading. The idea was to split the content of the preview area, not to add a second preview area. So we wouldn't waste and space, we just need to find a way to expose this functionality to the user and allow her to switch it on/off and configure where the split occurs. Since this is sort of an expert feature, it might be OK to make it accessible thru a right-click context menu only. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
On 09 Apr 2002 15:42:31 +0200, "Sven Neumann" <[EMAIL PROTECTED]> 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 | > ||| > --- > Alternative setups like top/bottom, diagonal split have been > suggested. Difficult to get this integrated into the GUI w/o > cluttering it with buttons. Could be in a right-click menu, but > it would probably not be found there. This could be nice, but I am not sure that it would be worth the effort (and again, the wasted space). How many plug-ins would really benefit from such a preview? In most cases, looking at the window containing the original image should be sufficient (assuming that the preview is located in one corner of the plug-in dialog, so that it is easy to put one window over the other one and compare their contents). I am not really against it, but I think that it should not be enabled by default and I would like some examples of plug-ins for which this feature could be useful. > - Make docks scrollable. Yuck! > - Make layers resizable/scalable in by adding handlers to the layer > boundaries. I think that the risks of hitting the resize handles by mistake and resizing the layers when you do not want to are higher than the benefits. If you frequently start selections or gradients or drawing lines from the corners of the image, you would be quickly annoyed by this feature. > - Effect layers. Hasn't been discussed much, probably not for 1.4. I had some thoughts about that, but nothing concrete yet. Basically, I was thinking about layers that could contain the results of the execution of a plug-in (or any PDB function, such as color correction or maybe some transforms). Every time the "source" layer is changed, the PDB function would be invoked to re-create the "effect" layer. The name of the PDB function and its arguments would need to be attached to the "effect" layer. It would be nice to have a way to combine that with "layer groups" so that one could specify that the effect layer contains an effect that should be applied to a group of layers instead of a single layer (the layers could be merged in the cache for the effect layer before calling the PDB to generate the results). Anyway, these thoughts are not very well structured yet, so this will be for later unless someone else has lots of good ideas and can implement that quickly... > - Allow to rotate the canvas just as one rotates a sheet of paper > when drawing to ease the use of graphic tablets. This was suggested last year by Roy Katz in comp.graphics.apps.gimp. Some programs such as Corel Painter offer this feature. There is already a bug report about that in Bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=55367 -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
On Wed, 10 Apr 2002 11:58:57 +0200, "Tino Schwarze" <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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) -- Jukka Rajala - Freelance Designer - +358 50 5144429 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Hi, [EMAIL PROTECTED] (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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Hi, [EMAIL PROTECTED] (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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 | > ||| > --- > Alternative setups like top/bottom, diagonal split have been > suggested. Difficult to get this integrated into the GUI w/o > cluttering it with buttons. Could be in a right-click menu, but > it would probably not be found there. 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. > - 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.) > - 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. 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. Hmmm... what about embedding a real image inside the preview? > - Make layers resizable/scalable in by adding handlers to the layer > boundaries. I want resizeable (rectangular) selections! > Text Tool > - > > - Should allow multi-line text with configurable line spacing. > > - Should allow to modify character-spacing for selected parts > of text. > > - 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. - Should allow more sophisticated text layout (e.g. changing fonts and styles for parts of the text, alignment for each lines, tabulators) Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Hi, Nathan C Summers <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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. -- Ville Pätsi -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 | > ||| > --- > Alternative setups like top/bottom, diagonal split have been > suggested. Difficult to get this integrated into the GUI w/o > cluttering it with buttons. Could be in a right-click menu, but > it would probably not be found there. It seems to me that the best way would be to have a "paned" view. Since it doesn't seem useful to have the pane in any other positions, the pane bar would "click" to the mid-point and to the left edge. I could even make a case for clicking to the right edge (showing the before image). Also, since left-to-right language speaker's eyes tend to move to the upper left and lower right corners of a dialog, it would be a little more usable to have the "after" (which is looked at more frequently) on the left and the before on the right (assuming the preview is placed on the left top as it is in all of the plugins I can think of). Not a big deal either way, though. > - Alternative preview in image window would be nice to have. > > - 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. > [pie menus] It's really hard to design a useful pie menu for a large number of menu items, especially in this case where you can add and remove items by adding and removing plugins. Perhaps a pie-menu enthusiast could give us a mock-up. > - Make docks scrollable. Eeek! Bad idea. But several people around here have suggested to me that image windows be dockable. Honestly, I can't see the point in that, but there is no harm either, and they seem to think it's more convienent to have everything in one big window. > - Make layers resizable/scalable in by adding handlers to the layer > boundaries. Sounds good, but I would make it a separate tool. Otherwise they would get in the way -- you would go to draw in a corner area and resize the image instead. > - Effect layers. Hasn't been discussed much, probably not for 1.4. Perhaps more powerful would be to have effect layer _modes_ instead of effect layers. It would integrate with what gimp currently better as well. I don't really think it's a 1.4 thing. > - 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. I suggest the color that is (1-H, 1-S, 1-V) (where HSV are the hue, saturation, and brightness of the pixel on a 0...1 scale). There will always be some pathological case where any algorithm will produce almost invisible lines, but this one should only be a problem if you have ugly high-frequency high-contrast lines in your image and you are selecting parellel to them. (bleck!) It should be very visable in almost all other cases. On second thought it might be better to use (1-H, S, 1-V). We'll have to experement. > - Find a better heuristic to place pasted selections/layers. Right > now they appear in the center of the image which is often far > away from the spot where one needs them. Using the center of the > display could be a better choice. Might I suggest we use the same UI that "Get It" does in the Self IDE? (http://research.sun.com/self/ -- original MacOS and Solaris versions, http://www.gliebe.de/self/download.html -- Linux port) For those who haven't had the unique pleasure of programming in Self, the Get It function is a lot like those window managers that make you place a new window whenever it pops up. But it's not like that in two important ways. It's not annoying. The window manager mouse placement thing is annoying since windows pop-up unexpectedly at time (like netscape errors) and you have to go to all the trouble of placing it before you see what the windows is. This wouldn't be annoying since you don't paste layers unexpectedly, and the layer would be displayed instead of moved in outline form. So, when you press th
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
On Tue, 9 Apr 2002, Stephen J Baker wrote: > 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've seen this on a number of graphics packages (Maya for example) > and it does work quite well. http://www.piemenu.com/ Research, source, examples, etc. Pie menus are used in The Sims and Maya. They work well for some applications (IMO), especially where there is frequent menu navigation, and I wouldn't mind seeing them as an option within the GIMP. But as already pointed out, the familiar list is also a good approach for those learning the features. A toggleable switch would be nice. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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+, -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
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've seen this on a number of graphics packages (Maya for example) and it does work quite well. The idea is that when you Right-click in the image to pop up the menu, instead of having just one honking great list of stuff, you split that menu into a number of catagories (4 or 8 typically) and scatter those catagories as little icons or perhaps text labels in a ring around the mouse pointer. Moving the mouse a short distance in the requisite direction pops up either a new (short) menu - or (more likely), drops you into a new ring of catagories. Releasing the mouse activates whatever thing the mouse is over at the time in the usual way. 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. It's pretty logical actually. Encoding the function you want as a 1 dimensional list requires EITHER tiny fonts and accurate mouse positioning OR large fonts and huge mouse movements. Neither are good for speedy menu item selection. Using (in essence) a 2 dimensional menu allows for larger, clearer fonts with less distance to travel to get to the entry you want. It also seems that people are somehow able to 'learn' the gestures to get to certain items quickly without even reading the menu's. It's like changing gear on a stick-shift car - you don't even have to think about the actual motion. "Right-Click then move up then right then up again" seems easier to get into "muscle memory" than "Right-Click, move down 1.3cm then move right then move down 2.6cm". I think the DISADVANTAGE of this scheme is that the beginner doesn't see a clearly presented *list* of options - this is perhaps a problem - but it could be a configuration option to select which style of popup menu you want - and in most packages that use these gesture menu's, there is also a standard menu containing all the options in the usual place at the top of the window. I saw a demo of one of these systems where a joystick was used to select the menu item - with the idea that you could mouse with one hand and pick menu's with joystick with the other. Dunno about that - I like my hotkeys. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Notes from the Guad3c GIMP BOF session
Hi, Damien Genet <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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+, -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
