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
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, 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, [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 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: 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, 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 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
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
[Gimp-developer] Pie and gestures
Hi I was also in the Guadec GIMP BOF, but only some minutes and I missed all stuff about pie menus/gestures. I'm very bad with ascii-drawing, so I've put my idea in a web: http://www.eurielec.etsit.upm.es/~fherrera/pie/ Please, visit it and comment!! Salu2 -- Fernando Herrera de las Heras Onírica: análisis, diseño e implantación de soluciones informáticas http://www.onirica.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Suggestion: add Bugzilla contact info in PLUGIN_MAINTAINERS
When some new bug reports are submitted to Bugzilla, some of us are notified about this and I try (as time permits) to reproduce the bug, ask for more information if necessary and in general to make sure that the status of the bugs in Bugzilla is up-to-date. Sometimes I even try to fix the bugs, but I did not have too much time for that in the last months. When a bug is affecting the core of the program, Sven and Mitch (who also get the notifications from Bugzilla) will usually take a look at it and try to fix it. But when a bug is affecting a plug-in or a part of the code that is maintained by someone else or that occurs only on a system that is not Linux or Solaris, then it is more difficult to be sure that the corresponding maintainer is aware of the problem. Sometimes it is already difficult to find a tester who has access to the corresponding operating system and who can confirm if the bug report is valid or not. It would be easier to work with Bugzilla if it was possible for me (and others) to add the corresponding maintainer(s) or tester(s) to the CC list for these bug reports, so that they are notified about the new bug report or any additional comments that are added to it. Unfortunately, this is not always easy to do because the e-mail addresses listed in the documentation (MAINTAINERS or PLUGIN_MAINTAINERS) do not always match the address used in the Bugzilla accounts. For example, it took me a while to find out that the address for Nick Lamb, listed as [EMAIL PROTECTED] in PLUGIN_MAINTAINERS should be [EMAIL PROTECTED] because this is the one that is recognized by Bugzilla. I propose to add a new field in PLUGIN_MAINTAINERS, containing only the Bugzilla accounts (or list of accounts) that should be added to the CC list if a bug is detected in the corresponding plug-in. This would usually be the same address as the one listed in the MAINTAINER field, but not always (maybe the maintainer uses a different address for Bugzilla or does not want to get the notifications at all). So there could be a new field called BUGZILLA: or BUGZILLA_CC: for all plug-ins, like this: NAME : normalize AUTHOR : Adam D. Moss, Federico Mena Quintero MAINTAINER : Adam D. Moss ([EMAIL PROTECTED]) BUGZILLA_CC: [EMAIL PROTECTED] SIZE : 7.7 kB in 1 file (only C files counted) COMMENT: I think that it would be a good idea to add something similar in the MAINTAINERS file, listing some potential testers for non-Linux operating systems. Some bug reports for systems other than Linux or Solaris (this includes Windows and MacOS X, among others) can remain in the UNCONFIRMED state for several weeks before someone who has access to the corresponding platform takes a look at it and adds some helpful comments that allow the status of the bug to be updated. Comments? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Notes from the Guad3c GIMP BOF session
[EMAIL PROTECTED] (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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] (no subject)
Wednesday, April 10, 2002 Dear Sir/Madam: ContestFinder.com has created a new service that can prove invaluable to organizers of contests and competitions on the Web. In essence we use a huge database and state-of-the-art programming to match potential entrants with events according to the interests and requirements of each. Participation is without charge. For detailed information about how we can help your efforts achieve wider and more precise exposure, please visit us on the web at www.contestfinder.com or give us a call Tall FREE: 1-866-840-5385 . Yours truly, Slava Levin, President For the team at ContestFinder.com ___ 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
