Re: [Gimp-developer] change layout of mode menus?
Does it keep the entire menu inside the screen if the layers dialog is at the right edge of the screen ? -- Laxminarayan Kamath Ammembal (+91) 9945036093 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Hi, On Thu, 2008-02-14 at 21:47 -0800, Bill Skaggs wrote: One of the minor annoyances of using Gimp is that the Layer Mode menu (and paint mode menu, etc) is unpleasantly long -- for me, it nearly extends from the top to the bottom of the screen. It would actually be very easy to change the code so that these menus are laid out in two columns, and in my opinion they look nicer that way. I am attaching a screenshot showing how it looks. (Hopefully the attachment will come through.) I am not sure. I have never had problems with the long menu and I think that the separators help a lot to understand the paint modes. The two-column layout doesn't provide this information and it even seems to suggest that there's some relationship between modes that are shown on the same row. IMO this change would be a regression but I might be convinced that it is an improvement. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
Unfortunately now that I have had time to think a bit harder, I understand that there is a fundamental difference in how my initial effort to implement a warp tool works compared to how the IWarp filter does. Basically, when using the IWarp filter, and manipulating the preview in its dialog, IWarp all the time has access to the complete original drawable (well, it uses a preview-sized scaled version of it). Also, the deformation vector array is built up and modified by each stroke in the preview, and not re-initialized between strokes. The displayed result preview is continuously based on pixels fetched from the original drawable, not from the already warped preview. In my current warp tool, on the other hand, each stroke (i.e. invocation of a GimpWarp object, a subclass of GimpPaintCore) is independent and reinitialises the deformation vector array. Also, it continuously modifies the drawable being painted on from itself to itself, if you understand what I think I mean... So, how to solve this? Should the bookeeping of deformation vectors be done per-drawawble by the GimpWarpTool object (a subclass of GimpPaintTool) and not GimpWarp object? Ditto for a copy of the original drawable. But when should this state then be discarded? Can a GimpWarpTool object know when some other tool or filter is being used on the drawable, and thus the warping data for that drawable should be discarded? Hopefully this is a question with an obvious answer, and there is some tool that already works like this... Or is it really so that a warp tool, and the filter brush kinds of tools that Ankh asks for, and all other nice cool things will need to wait for a complete geglification? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Fri, Feb 15, 2008 at 8:47 AM, Bill Skaggs wrote: One of the minor annoyances of using Gimp is that the Layer Mode menu (and paint mode menu, etc) is unpleasantly long -- for me, it nearly extends from the top to the bottom of the screen. It very much depends on particular GTK+ theme in use. I've used few Murrina (a GTK+ engine) based themes that a *very* compact. For instance, the whole list of layer modes takes something between 1/2 and 1/3 with them on my aging 1280x800 px laptop. Thus I'd rather encourage creating improved Default/Smaller themes :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Fri, Feb 15, 2008 at 2:57 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: Unfortunately now that I have had time to think a bit harder, I understand that there is a fundamental difference in how my initial effort to implement a warp tool works compared to how the IWarp filter does. Do you really need to do it exactly the way the filter does it? From your description, I don't really understand why your current approach is less valid, or even why it will produce a significantly different result. (The filter needs to do it that way because it doesn't act on the image until the user has finished working with the preview, but that logic doesn't apply to your tool.) Can a GimpWarpTool object know when some other tool or filter is being used on the drawable, and thus the warping data for that drawable should be discarded? Yes, many tools face this problem, and the system is set up so that tools are automatically halted if a drawable is dirtied while a tool is active. (More precisely, while tool_control is active.) Even tools themselves must take measures to keep from being halted when they make changes to the image: they do this by calling gimp_tool_control_set_preserve() before making a change. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
Do you really need to do it exactly the way the filter does it? From your description, I don't really understand why your current approach is less valid, or even why it will produce a significantly different result. It does produce a significantly different result. In my current code, there is interpolation upon interpolation when calculating the new pixels as the stroke proceeds, and the affected area gets more and more blurred. In IWarp, even when updating the preview while stroking, it is just one interpolation away from the original (scaled) preview pixels. the system is set up so that tools are automatically halted if a drawable is dirtied while a tool is active. (More precisely, while tool_control is active.) That sounds promising indeed. I do wish that there was some technical documentation on how this all hangs together. Just trying to understand by reading the code is a bit hard. When you say tool, you mean an object of a subclass of GimpTool, right, not an object of a subclass of GimpPaintCore? That is one thing that was a unclear to me, what is the proper division of tasks between a GimpTool and a GimpPaintCore? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Bill wrote: It seems to me that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly to give the very long list some structure, as far as I can see. But this is something that you should consider. separators are very important in a menu, to be able to deal with many ( 5) items, by putting them in sub groups, you get your bearing for aiming. even arbitrary sub-grouping is better than none. Anyway, I would like to make this change, and I wonder if there are objections. yeah, this is also harder to use because you have to do a controlled sideways movement to get from one column to the other. sorry: no cigar... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
agree with Peter, (part of my job is to improve user interaction UI usability) separators are good, even better are spacers (like in Firetox and Thunderbird [fluid spacers]) also a line OR a background surrounding a group of buttons are good for focusing to a 'grouped set of functions' ...instead of individual buttons. anyhow : 2 cigars peter sikking wrote: Bill wrote: It seems to me that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly to give the very long list some structure, as far as I can see. But this is something that you should consider. separators are very important in a menu, to be able to deal with many ( 5) items, by putting them in sub groups, you get your bearing for aiming. even arbitrary sub-grouping is better than none. Anyway, I would like to make this change, and I wonder if there are objections. yeah, this is also harder to use because you have to do a controlled sideways movement to get from one column to the other. sorry: no cigar... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Bill Skaggs wrote: One of the minor annoyances of using Gimp is that the Layer Mode menu (and paint mode menu, etc) is unpleasantly long -- for me, it nearly extends from the top to the bottom of the screen. It would actually be very easy to change the code so that these menus are laid out in two columns, and in my opinion they look nicer that way. I am attaching a screenshot showing how it looks. (Hopefully the attachment will come through.) I should say that the disadvantage is that it's hard to maintain the separators that divided the modes into categories -- it would be possible, but coding it would be a significant pita. It seems to me that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly to give the very long list some structure, as far as I can see. But this is something that you should consider. I think the separators are important. And the categories are full of sense. About create two columns, I think it may be a nice idea, but I have no problem with only one column. May be could be possible make two columns but mantaining separators. Anyway, I would like to make this change, and I wonder if there are objections. -- Bill Salu2 de jEsuSdA 8) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Well, it's clear that the idea is not generating a great deal of enthusiasm. Before dropping it, though, I'd like to take one more shot at clarifying the problem -- I'm attaching a screenshot showing a typical incarnation of the Paint Mode menu, using the Default Gimp theme and Ubuntu's default Human theme. I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better, other than asking people to use specific Gtk themes? -- Bill attachment: paint-mode-menu.png___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Fri, 2008-02-15 at 13:13 -0800, Bill Skaggs wrote: Well, it's clear that the idea is not generating a great deal of enthusiasm. [... screenshot...] I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better, other than asking people to use specific Gtk themes? Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a more modes submenu is a possibility. If gimp starts to have adjustment layers, that can e.g. apply a filter, or user-defined painting modes, or if the ilst of built-in modes got longer, the menu approach would probably become unworkable, and we'd need a drawing mode pallette or something. But it seems to me it's worth living with it as it is for a while, until the hot goat love (GEGL) has been explored a little more. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Liam R E Quin writes: Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a more modes submenu is a possibility. Eek, please no! Often the best way to use layer modes is to go down the list one by one, which would become even worse if you had to click through a more submenu each time. Bad enough to have to go to the bottom of the menu then wait for it to scroll. Personally I'd like Bill's side-by-side mode menu, just because it would be faster, and a shorter distance, to get to most entries. But Sven does have a good point that it implies there's a connection between each side-by-side pair of modes. Bill wrote: I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better I don't have a great solution, just a few specifics the gtk widget doesn't do well that I wish the modes menus could handle better. Like the fact that clicking on the button pops up the menu, but not always with the current mode selected -- sometimes it's the mode above the currently selected one, so I can't just arrow down once and assume I'm on the next mode -- I have to look at the current mode before I click, then choose the next one explicitly. And I wish there was a faster way to select them by keyboard than the current click on the button then use up or down arrow ... I wish I could type ad and be on Addition right away. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
