Re: [Gimp-developer] Moving selection contents with the move tool?
Hi, On Thu, 2006-09-28 at 02:13 +0200, [EMAIL PROTECTED] wrote: We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I dont think that makes sense to the user. Well, we can't really decide that without doing some usability research. We aren't users, so we can't create categories in a way that makes sense to the users. This would probably be a nice task for card sorting. Make a pile of cards with tool names (and perhaps tool icons) on them and ask a number of selected users to sort them into a bunch of piles. You could predefine categories or you could ask the users to come up with their own categories. There are standard protocols for analyzying the results. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
On Wed, Sep 27, 2006 at 08:36:09PM +0200, Sven Neumann wrote: Hi, On Wed, 2006-09-27 at 13:07 +0200, Dave Neary wrote: So another idea is to persuade Shawn to move everything gimp.org to another server (perhaps somewhere in gnome.org/RedHat's colo to take advantage of their sysadmin team?), update the DNS records and move on with our lives with new sysadmins. Come on, nobody wants this. Before we can even ask Yosh for revoking someone's email address, we need to agree on rules about the use of the gimp.org aliases. That's what I would like us to talk about now. Everything else seems very counterproductive to me. I think policing it at all is silly. Back in the day, we even gave out @gimp.org aliases as contest prizes, and monitoring that usage is impractical. I don't get where the expectation that postings from gimp.org addresses should be considered as anything but the individual expression of the author. Expecting a volunteer organization to have a rigid public face is ridiculous. One really should evaluate emails on the actual *content*, and not what the From address says. There are several active contributors who do not use gimp.org addresses, assuming their comments should have less weight is rather rude. Can we please stop cluttering the development mailing list with this now? -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
While moves might not be considered to be within the category of Transformations, they are commonly associated with them. A google of CAD translations and transformations will readily display how the two operations are commonly paired. Perhaps a better question to ask would be what graphics programs *don't* associate these operations? Regarding the current user interface (in CVS), I fail to see any logic in having the selection tools possessing the ability to move selection contents, it is much simpler and more intuitive if they limit themselves to selecting regions and not engage in modifying drawables. A minor related note: the Affect Selection option of the Move Tool displays two identical Move Selection options, both of which are always(?) grayed out. I understand the tools are under development and am not complaining; the work being done is most excellent and I look forward to the time these usability issues are resolved. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
Hi, Manish Singh a écrit : I think policing it at all is silly. That's unacceptable. And it's not your decision to make. One really should evaluate emails on the actual *content*, and not what the From address says. There are several active contributors who do not use gimp.org addresses, assuming their comments should have less weight is rather rude. I *am* judging the content. The content is crap, often abusive, and to my mind obviously unacceptable behaviour for a community member. But someone coming to the project for the first time doesn't have the same ability to make that judgement. Can we please stop cluttering the development mailing list with this now? There's an easy way to do that - ban Carol from the list and remove her gimp.org email address alias. Or get out of the way and let someone else do it. Cheers, Dave. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
On Wed, 27 Sep 2006 23:50:24 +0200, Michael Natterer [EMAIL PROTECTED] wrote: On Wed, 2006-09-27 at 21:25 +0200, Raphaël Quinet wrote: On Wed, 27 Sep 2006 21:03:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote: How do we handle the statusbar being invisible? Perhaps the statusbar should delegate to gimp_message() if it is not currently shown? Yes, but this should probably not be done by the status bar itself. It should be done one level higher so that the code still knows that it is some error message that is important enough to be displayed with gimp_message(). We only show messages if things didn't happen as the user expected them to happen. We can't just let user actions on the display fail without any comment. The Statusbar should imho just use gimp_message() if it is invisible. There are other messages that can be displayed in the status bar but are not errors. In that case, they should simply not be displayed if the status bar is hidden. Obviously that would include the various hints for the tools, selection sizes, guide positions, etc. They don't use the same function call now, so that's fine. But I was also thinking about using gimp_statusbar_push_temp() for something else than errors. For example, after saving a file it could be possible for the file plug-ins to report things like the size of the saved file, which would then be briefly shown to the user in the status bar. Or if you undo or redo some operation, its name could be briefly shown in the status bar (like in the undo history). These informational messages would be displayed in the status bar without the warning icon that is currently used (we could use some info icon although using no icon is probably better if we want the warnings to be noticed easily). And if the status bar is hidden, they would just not be displayed anywhere because they are not very important anyway. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On Thu, 2006-09-28 at 02:13 +0200, [EMAIL PROTECTED] wrote: We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I dont think that makes sense to the user. I covered that in a reply to Sven. Aha... so which of the tools under Transform Tool is not doing a transform? I don't see any that wouldn't prefectly fit into the catrgory. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: *** PROBABLY SPAM *** Re: [Gimp-developer] Moving selection contents with the move tool?
On Thu, 28 Sep 2006 13:48:29 +0200, Michael Natterer [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 02:13 +0200, [EMAIL PROTECTED] wrote: We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I don't think that makes sense to the user. I covered that in a reply to Sven. Aha... so which of the tools under Transform Tool is not doing a transform? I don't see any that wouldn't perfectly fit into the category. ciao, --mitch Mitch, please look back over the thread. As quick reply because I'm repeating what has already been said, I don't think moving a selection a bit to one side would seen as a transforming it by someone who did not have a maths background. It's an example of a broader issue. cheers. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On 9/28/06, saulgoode [EMAIL PROTECTED] wrote: Regarding the current user interface (in CVS), I fail to see any logicin having the selection tools possessing the ability to move selectioncontents, it is much simpler and more intuitive if they limit themselves to selecting regions and not engage in modifying drawables.I agree completely. A minor related note: the Affect Selection option of the Move Tooldisplays two identical Move Selection options, both of which arealways(?) grayed out.Either you are misunderstanding what is actually there, or your build is messed up. Try rebuilding from scratch, and then checking your assertion above. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 01:42:12 +0200, [EMAIL PROTECTED] wrote: [...] 1/ In general I find it needs too many mouse/keyboard actions to achieve a simple operation. 1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in. There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow. Well, the undo shortcut is probably not assigned to Ctrl-Z by accident. Did you notice that there is no Z in undo? Something like Ctrl-U could have been used instead (and was used in the past). But many applications use Ctrl-Z. If you are a right-handed english-speaking user (or at least someone with a qwerty keyboard), you can see that Ctrl and Z are close to each other and can be pressed easily with the left hand while the right hand is on the mouse. You might complain about discrimination against lefties or foreigners, but at least for a large percentage of the users, the Ctrl-Z shortcut can be found easily without diverting attention from the screen or mouse. 1b/ I pull up a dlg. the first text entry is highlighted so I can type to replace , fine. But if I want to edit it eg 100 to 400, I go to select the 1 with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want. Solving this problem would probably require disabling drag drop from the input fields. I am not sure that anyone uses that feature anyway, at least for the short entry fields that we have in most dialogs (except for the text tool). I agree that it is more likely that someone who clicks and drags in one of these short input fields wants to select some digits instead of dragging the whole number elsewhere. This should probably be submitted in Bugzilla. 2/ I am continually repeating the same placement/configuration operations where once should be enough. 2a/ It seems none of the filters retain thier position and size, although they retains _some_ of their settings. Right. We do not even have an API allowing the plug-ins to retain their size and position easily. Although the current API based on gimp_get_data() and gimp_set_data() could be used for that, every plug-in writer would have to write hacks around gimp_dialog_new() or gimp_dialog_run() in order to resize the window correctly. In addition, the filters that have a more complex layout with resizeable panes inside the window would also have to remember the size of each of them (e.g. Filters-Map-Bump Map) and those that have multiple tabs should remember which tab is active. specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again. While this is probably down to the plugin writer, at least the common filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins. I agree. Please submit this improvement proposal in Bugzilla. It may even be useful to remember the window positions (for the plug-ins) accross gimp sessions. In this case, this information should probably go into the pluginrc or something similar. 2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options. specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels. Although it would make sense for Duplicate, I am not sure that it would be good to always remember the last values used when you create a new image. The defaults can be set in Preferences-Default Image and I would like these values to be used. 2c/ I have select for tools to store settings but this seems limitted. specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option :tools store settings. I do not understand what you expect in this case. Things like the resolution, units, grid spacing and so on are a property of the image. The Scale Image dialog should just use what is specified for that image. But maybe I misunderstood what you meant. 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools.
Re: [Gimp-developer] Moving selection contents with the move tool?
On Thu, 2006-09-28 at 14:11 +0200, [EMAIL PROTECTED] wrote: On Thu, 28 Sep 2006 13:48:29 +0200, Michael Natterer Aha... so which of the tools under Transform Tool is not doing a transform? I don't see any that wouldn't perfectly fit into the category. ciao, --mitch Mitch, please look back over the thread. As quick reply because I'm repeating what has already been said, I don't think moving a selection a bit to one side would seen as a transforming it by someone who did not have a maths background. It's an example of a broader issue. I did read the thread, and moving *is* transforming. Yes mathematically and correctly. Making it a non-transform tool UI-wise makes no sense to me whatsoever. What else should it be then? And what broader issue are you talking about? ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On Thu, 2006-09-28 at 21:48 +0930, David Gowers wrote: On 9/28/06, saulgoode [EMAIL PROTECTED] wrote: Regarding the current user interface (in CVS), I fail to see any logic in having the selection tools possessing the ability to move selection contents, it is much simpler and more intuitive if they limit themselves to selecting regions and not engage in modifying drawables. I agree completely. In Current CVS, you have to press alt+shift or alt+control to actually move the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it. A minor related note: the Affect Selection option of the Move Tool displays two identical Move Selection options, both of which are always(?) grayed out. Either you are misunderstanding what is actually there, or your build is messed up. Try rebuilding from scratch, and then checking your assertion above. Well, should we simply hide these options when they make no sense? It's IMHO better to change the text to something that's actually happening and make them insensitive. That's the whole reasoning behind that. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On 9/28/06, Michael Natterer [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 21:48 +0930, David Gowers wrote: On 9/28/06, saulgoode [EMAIL PROTECTED] wrote: Regarding the current user interface (in CVS), I fail to see any logic in having the selection tools possessing the ability to move selection contents, it is much simpler and more intuitive if they limit themselves to selecting regions and not engage in modifying drawables. I agree completely.In Current CVS, you have to press alt+shift or alt+control to actuallymove the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it.That is definitely a great feature, and I understand why it can't be assigned to a single key. I think it still needs to be made more accessible (personally I'd rate it as more important than being able to intersect the selection with the old selection; however it's less obvious than the intersect function) Looks like I've comprehensively misunderstood what saulgoode was trying to say. -- Sorry, saulgoode. Either you are misunderstanding what is actually there, or your build is messed up. Try rebuilding from scratch, and then checking your assertion above.Well, should we simply hide these options when they make no sense? It's IMHO better to change the text to something that's actuallyhappening and make them insensitive. That's the whole reasoningbehind that.What I meant here is that the only circumstances in which the 'affect selection' option of the Move tool is greyed out is when there is no image open, and that there is exactly one instance of it, not two. Oh, wait.. I see what saulgoode meant now. I think that it could be improved (the second radio option could be N/A and selecting 'affect selection' would force the radio selection to the first option (and set the radio group insensitive, as before)) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
Raphaël Quinet wrote: I am not sure about does not operate vs. cannot manipulate, but I I prefer operate to manipulate. An alternatives would be can not work with indexed images or can not use indexed images -- Cheers! Kevin. http://www.interlog.com/~kcozens/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172|Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
Hi, On Thu, 2006-09-28 at 14:39 +0200, Raphaël Quinet wrote: 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools. Indeed. The image is also not filled with the last used color if the user switches to the Bucket Fill tool. Doing this for the transform tools would be very inconsistent. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
Hi Yosh, On Thu, 2006-09-28 at 01:50 -0700, Manish Singh wrote: One really should evaluate emails on the actual *content*, and not what the From address says. There are several active contributors who do not use gimp.org addresses, assuming their comments should have less weight is rather rude. You ignore the fact that we are not actually discussing whether a mail from gimp.org has more or less weight. What we are discussing is abuse of the gimp.org email domain. I agree that we should not try to monitor what people are doing with their gimp.org alias, but if abuse is reported multiple times, we have to do something about it. Can we please stop cluttering the development mailing list with this now? I am not really willing to ignore this issue any longer. I have had several reports from people who received mails from [EMAIL PROTECTED] that can be described as very irritating, to say the least. I think that we can not any longer ignore this problem. I have asked Carol multiple times to stop sending such mails, or at least not to use the gimp.org mail alias for it. She has ignored these requests and did it again. What do you suggest that we do? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
Hi, On Thu, 2006-09-28 at 13:30 +0200, Raphaël Quinet wrote: These informational messages would be displayed in the status bar without the warning icon that is currently used (we could use some info icon although using no icon is probably better if we want the warnings to be noticed easily). And if the status bar is hidden, they would just not be displayed anywhere because they are not very important anyway. Sure, I don't think anyone disagrees with that. It might also help to include the tool icon in the statusbar when a tool displays status or user hints. That would make it clearer where this messages are coming from. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
On Thu, Sep 28, 2006 at 07:31:56PM +0200, Sven Neumann wrote: I am not really willing to ignore this issue any longer. I have had several reports from people who received mails from [EMAIL PROTECTED] that can be described as very irritating, to say the least. I think that we can not any longer ignore this problem. I have asked Carol multiple times to stop sending such mails, or at least not to use the gimp.org mail alias for it. She has ignored these requests and did it again. What do you suggest that we do? i am curious if this mail actually came from me. i had a bad time in my life. really really really bad. that being said, i can be expected to be as patient with people who might be having a similar bad time. being let down by people you tried to be friends with is a horrible thing. i can thank my newer california 'friends' for this new understanding of how this world works and my ability to overlook it. right now, the mail i send is to gimp lists and also to old friends and family. there is a huge group of users on the old wilber computer. i can provide a list of these people. i am willing to guess that anyone of them would be more capable than me of hacking the mail server there. i find it additionally interesting the people who are new to gimp who have user space there. i was under the impression that wilbers space was very limited and indeed, there is not the space there for gtk to put their tarballs and the new computer sits dead here. can you share the complaint mail with me? i believe that i am fully capable of being able to determine what mail i authored and what mail i did not author. i even think that it would be useful to look at how the security of the berkeley host is. if you are unable to do this, can you shut up please? it would be interesting to see if the complaints are about mail i sent. i totally admit that i am not very happy sharing the same computers with so many screened users. 'neo' being one of them. and here is an honest question about how the user space is being allocated on both wilber and ircd. karine has space on both computers, where apparently, i have space on wilber but only symbolically on ircd. i have pulled down my web stuff repeatedly because of the perception i have that we work together. i did this for akkana and i also did and do this for karine. i left gimp-web development because karine spent so much time working on it and for it. it is karine being edhel online and in bugzilla and in the changelog, am i correct on this? perhaps we should all go through everything that people have a problem and claim what they actually did and did not do and be willing to be responsible for it. everyone who is unwilling to do this should leave. if i should be sorry that i did not aggressively take what was mine -- i don't actually have a language to be that way. i did not have the language to enable me to keep what was mine before i became involved. i do not like authoring my email directly from wilber like this. i do like my decision to wait until i/me, my physical body which is totally, typically and predictably human to be in my home with my own internet connection which i pay for from whatever living i can make in this horrible and broken world. i find it interesting how trying to work with karine and akkana doesn't help much. i will also find it interesting when i can read the complaints you are getting to see if it is about something i have done or written. thanks for all of the concern, carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Moving selection contents with the move tool?
On 9/28/06, Michael Natterer [EMAIL PROTECTED] wrote: In Current CVS, you have to press alt+shift or alt+control to actually move the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it. A feature being useful doesn't justify its misplacement in the command structure. Maybe that is stating things a bit harshly but selection operations should be limited to operating on selections. I am a great fan of overloading commands but there needs to be some basic and comprehensible limits to what groups of commands do, otherwise they cease to be groups. How is it any more of a power tool to hold ALT+CTRL while a Selection Tool is active versus pressing another key (such as M) to activate a Move Tool? Especially since the result is a floating selection for which selecting will no longer be of any use (you can either Anchor or continue to Move). And if moving the selection contents is such a useful tool to have at one's disposal (with which I would heartily agree), why is it an almost hidden auxiliary function of the Selection Tool -- with no equivalent elsewhere in the toolbox? OFF-TOPIC: A screenshot of the Move Tool double option window is available at http://flashingtwelve.brickfilms.com/GIMP/Screenshots/Move.png That was compiled from Monday's CVS. I will try rebuilding this weekend. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 14:39:39 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: On Thu, 28 Sep 2006 01:42:12 +0200, [EMAIL PROTECTED] wrote: [...] 1/ In general I find it needs too many mouse/keyboard actions to achieve a simple operation. 1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in. There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow. Well, the undo shortcut is probably not assigned to Ctrl-Z by accident. Did you notice that there is no Z in undo? Something like Ctrl-U could have been used instead (and was used in the past). But many applications use Ctrl-Z. If you are a right-handed english-speaking user (or at least someone with a qwerty keyboard), you can see that Ctrl and Z are close to each other and can be pressed easily with the left hand while the right hand is on the mouse. You might complain about discrimination against lefties or foreigners, but at least for a large percentage of the users, the Ctrl-Z shortcut can be found easily without diverting attention from the screen or mouse. Yes, I know cntl-Z can be hit with one hand but I am going to scrabble around unless I look, in which we're back to my original point. A close to hand undo button would be a lot faster. 1b/ I pull up a dlg. the first text entry is highlighted so I can type to replace , fine. But if I want to edit it eg 100 to 400, I go to select the 1 with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want. Solving this problem would probably require disabling drag drop from the input fields. I am not sure that anyone uses that feature anyway, at least for the short entry fields that we have in most dialogs (except for the text tool). I agree that it is more likely that someone who clicks and drags in one of these short input fields wants to select some digits instead of dragging the whole number elsewhere. This should probably be submitted in Bugzilla. Done. 2/ I am continually repeating the same placement/configuration operations where once should be enough. 2a/ It seems none of the filters retain thier position and size, although they retains _some_ of their settings. Right. We do not even have an API allowing the plug-ins to retain their size and position easily. Although the current API based on gimp_get_data() and gimp_set_data() could be used for that, every plug-in writer would have to write hacks around gimp_dialog_new() or gimp_dialog_run() in order to resize the window correctly. In addition, the filters that have a more complex layout with resizeable panes inside the window would also have to remember the size of each of them (e.g. Filters-Map-Bump Map) and those that have multiple tabs should remember which tab is active. Taking Bump Map as an example, this is a good case in point. The preview autorescales so all we need is size and position to be reatained. Many of these previews are too small to see the effect clearly. That's my main reason to resize the dlg. I think technical difficulties of implementation need to be separated from UI discussion until the value of the idea has been assessed. I would have other comments about the flexibility on API implementations. specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again. While this is probably down to the plugin writer, at least the common filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins. I agree. Please submit this improvement proposal in Bugzilla. It may even be useful to remember the window positions (for the plug-ins) accross gimp sessions. In this case, this information should probably go into the pluginrc or something similar. Done. 2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options. specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels. Although it would make sense for Duplicate, I am not sure that it would be good to always remember the last values used when you create a new image. The defaults can be set in Preferences-Default Image and I would like these values to be used. I was refering to scale image, duplicate was mentioned to show that each instance of the dlg reverts while the same instance retains. Rather inconsistant. Settings could be stored when the dlg is closed so that the same dlg on another image can retain them. 2c/ I have selected for tools to store settings but this seems limitted. specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option
Re: *** PROBABLY SPAM *** Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 19:12:57 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2006-09-28 at 14:39 +0200, Raphaël Quinet wrote: 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools. Indeed. The image is also not filled with the last used color if the user switches to the Bucket Fill tool. Doing this for the transform tools would be very inconsistent. Sven Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it. Bucket-fill remembers its settings but does not apply them until you ask. Rotate shows the selection outline rotated but not the pixels so if it remembered this would work well without arbitarily transforming the image before required. If the other transforms were made consistant with rotate, all could retain values and you would have the best of both worlds and be more consistant than the current situation. What do you think would be the best way to align these differences? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements
Hi, On Thu, 2006-09-28 at 22:50 +0200, [EMAIL PROTECTED] wrote: I think technical difficulties of implementation need to be separated from UI discussion until the value of the idea has been assessed. I would have other comments about the flexibility on API implementations. I don't think this needs much further discussion. We already have plans for adding a GimpPlugInDialog widget and porting the plug-ins to it. Such a dialog would provide a framework for loading and storing plug-in settings or at least for changing the defaults. It could also take care of session management such as setting the window size. I dont see what tool store settings does. I see some data about brushes if I plough through the configs but if I choose to work in percent rather than pixels this is not remembered. IIRC, the dialog currently takes the unit from the image that is being edited. This seems to make some sense to me and it might be difficult to decide when it makes sense to use percent instead. Or perhaps percent would even be a better default? We should ask some users. Well I looked at this with rotate. The preview on the image just shows the outline that will be rotated but does not move the image/selection until the dlg closes. This indeed seems the best of both worlds if it retains my last rotation setting. I either hit go or reset as you suggest. IIRC, the Rotate tool shows a preview of the rotation by default. If it shows only the outline for you, then you probably changed the default rotate tool settings. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
Hi, On Thu, 2006-09-28 at 23:01 +0200, [EMAIL PROTECTED] wrote: Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it. Your accusations are unfair. First of all, your GIMP setup seems somewhat screwed. Try to reset the tool options or remove the ~/.gimp-2.3/tool-options folder. And you also ignore the fact that a lot of thought has gone into the current behaviour. It would help if you could appreciate that and ask before you jump to conclusions quickly. Also you need to admit that your usage of GIMP is just one possible way of using it. We don't know much about you yet, so we can't tell if your usage patterns are in any way representative for a large user group. We are willing to do changes. But very often people forget to see all aspects of user interface design. Are you sure that you have thought about all possible user scenarious? Are you sure that you understood the rationale behind the current behaviour? If not, it might be a good idea to ask those questions first. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 23:21:15 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2006-09-28 at 23:01 +0200, [EMAIL PROTECTED] wrote: Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it. Your accusations are unfair. First of all, your GIMP setup seems somewhat screwed. Try to reset the tool options or remove the ~/.gimp-2.3/tool-options folder. And you also ignore the fact that a lot of thought has gone into the current behaviour. It would help if you could appreciate that and ask before you jump to conclusions quickly. Also you need to admit that your usage of GIMP is just one possible way of using it. We don't know much about you yet, so we can't tell if your usage patterns are in any way representative for a large user group. We are willing to do changes. But very often people forget to see all aspects of user interface design. Are you sure that you have thought about all possible user scenarios? Are you sure that you understood the rationale behind the current behaviour? If not, it might be a good idea to ask those questions first. Sven Sven, (and the rest of the team) please don't take any of this the wrong way. I made a list of things that I found held me back. This is in no way suggesting that no-one has put any thought into this interface , clearly they have. By and large it works very well. I would like to help you improve it. I clearly stated that all of the issues were minor but the overall effect was that a lot more mouse input was required than was really necessary. I listed a number of points , not as a means of ripping it apart, but to give clear indications where I could identify lost time and hence give something concrete to look into rather than broad unjustified comments. You will appreciate it also takes time to go through all this and give precise, hopefully useful, criticisms. Neither do I assume my way of working is typical, it almost certainly is not, because like most of you on this list I have a technical programmers background and a good knowledge of maths. What I say about settings is not that the one's I choose are in any way better or typical but that there is a need to retain user settings in order to avoid a lot of unwarranted repetition. Sorry if I have a bit of a blunt style , I do tend to come straight to the point. This is not meant to be dismissive or disrespectful of the work that has been done. We all also know email is a lousy form of communication and it's easy to take things the wrong way. You and Bill in particular have been very helpful in helping find my way around the code and I've felicitated you on the openness of your approach. Let's not let irritations drift drift in the way here. Thanks for your time and comments. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
On 9/28/06, Manish Singh [EMAIL PROTECTED] wrote: I don't get where the expectation that postings from gimp.org addressesshould be considered as anything but the individual _expression_ of theauthor. Expecting a volunteer organization to have a rigid public face is ridiculous.When I initially joined the list several years ago I was disappointed in the attitude of one/some gimp.org posters because I thought they were in some way associated with the project. There was too much noise and disrespect so I left the list because of it (but have since re-joined). Personally I don't think it is an unreasonable expectation that someone with a gimp.org email is associated with the project. It may be ridiculous to expect a rigid public face, but I think the public should expect the project to have a respectable face. Can we please stop cluttering the development mailing list with thisnow? The project has a problem. Several people have pointed out the problem. Although not explicitly stated, I would think the purpose of the developer list is to discuss project issues.-- Tim Jedlicka, Network Entomologist [EMAIL PROTECTED], http://www.galifree.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
