Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 01:02:34AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: I don't know what I am smoking, but this very compaint has come up a number of times, and your only reaction is to talk it down. That is a blatant lie. The reaction to these concerns is that me and This is the end of reasonable discussion with you again. Too bad you immediately call other people liars and worse. Couldn'T you simply be reasonable? these concern with Federico and other GTK+ developers, entering bug reports and writing patches to fix them. The fact that you completely ignore this and stick to your lies is becoming rather insulting. I did not even claim that you didn't and where did I ignore this. What's your problem? Accusing me of saying things I clearly haven't again? Accusing me of not having said things that you assume I think? Come on, get a life... No, it does not at all work surprisingly well. It is *extremely* slow, it hinders, it flickers, it destroys the selection, it pops up a window. It feels like an ugly kludge and certainly does not wor surprisingly well. I cannot reproduce most of your problems. Which would be? Why does your inability to partly reproduce problems mean that I cannot be taken seriously? At least not from this description. If you want to be taken seriously, then please come up with serious descriptions and make sure that comprehensive and useful bug reports exist for them. You cannot reproduce some aspect of my description but others so claim I can't be taken seriously. That is *exactly* the kind of tactics that annoys so many people: They report sth., you have a problem with some aspect of their descriptino so you dismiss it all. Don't other people simply deserve to be taken seriously, especially if _so_many_people_ report the same kind of problems? It's juts as I said: you ignore or talk down these issues. Fact is, people agree that the way the gtk+-1 file selector worked with regards to text entry and tab completion has no problems. So all this wiggly-waggly we don't know what you mean is pretty dumb: I repeat: The behaviour of thre gtk+-1.0 file dialog with regards to text entry and tab completion is *exactly* what people want, and even if it weren't, it's most close. It's exactly what I said earlier, too. All the questions on what to do are completely superfluous, as there even exists working code that explains what people need. What happens instead is that we see kludge after kludge and claims that these kludges would be superior. If the gtk+ developers would want to help they would just listen to the users. And you accuse me of lieing and claim I can't be taken seriously. Don't you realize something? Just because you can bully other people and silence them (well, not all fortunately) does not mean you are right. But I said that before, and you simply don't want to understand that or improve the situation. You need a serious attitude change when dealing with people. You also said file dialogs should go away (in some distant future) and people should use dragdrop. You misunderstood me. If you say so, then it is so. If I were you I'd just accuse you of lieing :( Sorry, but that's not at all funny. I didn't say that DND is going to replace file choosers. I said that sooner or later most people will not even know about the concept of hierarchical file systems. That doesn't mean that they will be dragging in files from file managers. File managers will also cease to exist (at least for a large user group). Yeah, I have seriously misinterpretetd what you said when you actually meant that. Have fun! -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tuesday, June 21, 2005, 1:02:34, Sven Neumann wrote: No, it does not at all work surprisingly well. It is *extremely* slow, it hinders, it flickers, it destroys the selection, it pops up a window. It feels like an ugly kludge and certainly does not wor surprisingly well. I cannot reproduce most of your problems. At least not from this description. If you want to be taken seriously, then please come up with serious descriptions and make sure that comprehensive and useful bug reports exist for them. I definitely can - typing paths in the Ctrl+L dialog looks like this to me: type a drive letter and :, see them both appear while typing, continue typing, but see no feedback for several seconds while it's checking the files - the native Win32 dialog boxes show the autocomplete list both much faster, and doesn't interfere with my input even when it takes a few seconds for the list to appear. I'll write a more complete list of the things that bother me in the file dialog in the evening. -- Jernej Simoncic http://deepthought.ena.si/ Logic is a systematic method of coming to the wrong conclusion with confidence. -- Manley's Maxim ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Peace!
Hi Marc, Sven. I don't know if there's a list protocol about this, or maybe it's well established that peacemakers like myself are pretty much bound to fail, but I thought I'd give it a shot ... I've been on the internet for many years, and I've been insulted and flamed quite a number of times. The best way to keep the peace is to ignore the flames entirely and not reply at all. If you think you need to reply, reply to the cogent points of the post, not the insults. Something else I've found: ignoring the flames only makes the flamer look more foolish, so by doing so you keep the peace _and_ make your would-have-been opponent look worse. I don't think the list can afford to lose the input of either one of you. -- Giles [EMAIL PROTECTED] http://www.gilesorr.com/ -- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace! Seconded!
On Tuesday 21 June 2005 19:55, Giles wrote: I don't think the list can afford to lose the input of either one of you. Agree. Please find a way to work together, or at least constructively ignore one another. Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/Member, Linux Australia ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, 2005-06-21 at 13:02 +0200, [EMAIL PROTECTED] wrote: On Tuesday, June 21, 2005, 1:02:34, Sven Neumann wrote: No, it does not at all work surprisingly well. It is *extremely* slow, it hinders, it flickers, it destroys the selection, it pops up a window. It feels like an ugly kludge and certainly does not wor surprisingly well. I cannot reproduce most of your problems. At least not from this description. If you want to be taken seriously, then please come up with serious descriptions and make sure that comprehensive and useful bug reports exist for them. I definitely can - typing paths in the Ctrl+L dialog looks like this to me: type a drive letter and :, see them both appear while typing, continue typing, but see no feedback for several seconds while it's checking the files - the native Win32 dialog boxes show the autocomplete list both much faster, and doesn't interfere with my input even when it takes a few seconds for the list to appear. I'll write a more complete list of the things that bother me in the file dialog in the evening. Hi Jernej, I believe you missed the type-ahead functionality: http://jimmac.musichall.cz/demos/gimp/file-dialog-rocks.avi Some notes about the video which may not be obvious - the focus issues are history and the dialog accepts input even if you clicked on the shortcuts. At one point I messed up and entered the wrong directory. I used the nautilus shortcut alt+up to go up. The new file dialog is a pleasure to use to me, mainly because of the bookmarks. I spend less time browsing deep hierarchies and achieve file-related tasks faster than I used to. cheers -- Jakub Steiner [EMAIL PROTECTED] Novell, Inc. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
Giles wrote: I don't think the list can afford to lose the input of either one of you. I wouldn't worry too much about it. Compared to flame-fests of the past, this one is pretty much a yawner. At least they're arguing about questions of fact. -- Bill The one advantage of playing with fire, is that one never gets even singed. It is the people who don't know how to play with it who get burned up. -- Oscar Wilde, A Woman of No Importance __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tuesday, June 21, 2005, 17:29:52, Jakub Steiner wrote: I believe you missed the type-ahead functionality: I know of type-ahead, but it's not an adequate replacement for a real path+file text entry. This is how I usually browse for files: http://deeperthought.ena.si/autocompletion.htm (I only used Enter key once, when I had the complete path to file entered and wanted to open the file). -- Jernej Simoncic http://deepthought.ena.si/ At any level of traffic, any delay is intolerable. -- Brigg's Law of Traffic ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 07:16:25PM +0200, [EMAIL PROTECTED] wrote: On Tuesday, June 21, 2005, 17:29:52, Jakub Steiner wrote: I believe you missed the type-ahead functionality: I know of type-ahead, but it's not an adequate replacement for a real path+file text entry. This is how I usually browse for files: http://deeperthought.ena.si/autocompletion.htm (I only used Enter key once, when I had the complete path to file entered and wanted to open the file). I liked the way a lot it was with GIMP 2.0 (GTK 2.2 IIRC): Just type parts of file or directry, hit tab, voila, just like the shell (the dropdown with possible completions is optional). Bye, Tino. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 08:46:55AM -0700, William Skaggs wrote: Giles wrote: I don't think the list can afford to lose the input of either one of you. I wouldn't worry too much about it. Compared to flame-fests of the past, this one is pretty much a yawner. At least they're arguing about questions of fact. -- Bill The one advantage of playing with fire, is that one never gets even singed. It is the people who don't know how to play with it who get burned up. -- Oscar Wilde, A Woman of No Importance it does smell of agreement between the two of them. if it were less boring of an interchange, i could pull the real conversation out from between the lines and any one who has been respectfully following the list for a while can do this easily as well. completely off-thread, i would like to see the way mr. lehmann has the menu structure set in his own personal instance of gimp. i say this because i really liked the changes that installing gimp-perl makes to the Xtns menu. gimp-perl tried to make the scripting environment invisible to the user a very very long time ago. including the pdl (a long time ago) foiled this attempt. i accidentally perpetuated this when i made an updated python image instead of asking that the image in the dialog be removed. carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 11:20:44AM -0700, Carol Spears [EMAIL PROTECTED] wrote: completely off-thread, i would like to see the way mr. lehmann has the menu structure set in his own personal instance of gimp. I never ever changed the menu structure compared to the cvs/source releases, and I always run in the C locale. the Xtns menu. gimp-perl tried to make the scripting environment invisible to the user a very very long time ago. If you mean that I didn't make a separate Perl subhierarchy like script-fu does (or did), then yes, this I did because I believed that a user must not be forced to learn the difference between a C/Script-Fu/python/perl/whatever plug-in. It makes no difference, as long as it does what it states it would do. I still believe that making language-specific menus is a disservice to users. It's only use is for marketing of the language in question (oh, so it's in script-fu!). But such ideas were and probably are unpopular within a community that prejuduices some languages over others. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: If you mean that I didn't make a separate Perl subhierarchy like script-fu does (or did), then yes, this I did because I believed that a user must not be forced to learn the difference between a C/Script-Fu/python/perl/whatever plug-in. It makes no difference, as long as it does what it states it would do. I still believe that making language-specific menus is a disservice to users. It's only use is for marketing of the language in question (oh, so it's in script-fu!). But such ideas were and probably are unpopular within a community that prejuduices some languages over others. You didn't miss the current efforts or restructuring the menus, did you? HTH, Michael -- The GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
Hi, Giles [EMAIL PROTECTED] writes: I don't think the list can afford to lose the input of either one of you. Don't worry. We are just having some fun. At least I hope that Marc does. I am certainly enjoying it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: This is the end of reasonable discussion with you again. Too bad you immediately call other people liars and worse. Couldn'T you simply be reasonable? Huh? Is it all over already? That would be a pity. these concern with Federico and other GTK+ developers, entering bug reports and writing patches to fix them. The fact that you completely ignore this and stick to your lies is becoming rather insulting. I did not even claim that you didn't and where did I ignore this. Well, you said that I would be deliberately ignoring user complaints and that is just plain wrong. I may tend to disagree with a lot of the complaints but that is mostly because I also hated the new filechooser dialogs in the beginning but over time the widgets have matured and in the meantime I really like them. I completely agree that the dialogs were pretty much unsuable when they appeared in GTK+ 2.4 and I feel sad whenever I learn that people are still using GIMP with GTK+ 2.4. But there isn't really anything I can do about that. I cannot reproduce most of your problems. Which would be? Why does your inability to partly reproduce problems mean that I cannot be taken seriously? I simply want you and anyone else who wants to have a discussion on the file-chooser to do three things: (1) Use the latest GTK+ 2.6 release. Most of the problems that you and others mentioned have been addressed in the meantime and it doesn't really make sense to have a discussion on bugs that are already fixed. (2) Take a step back and try to understand the concepts behind the new dialog. There is room for improvement but the overall design is good. It is good because it works for newcomers and it still has a lot to offer to the expert user. (3) Don't try to advertise the old GtkFileSelection dialog as being the solution that we should revert too. That widget sucked badly. It's main problem was that it was completely unusable for newcomers. It had exactly one feature to overcome its limitations and that was Tab completion. Without Tab completion the old dialog was pretty much unusable. The problem here is that Tab completion is not something that people can discover. At least not the larger part of our userbase. So if you want to revert to the old dialog, don't expect to be taken seriously. If you insist on being taken seriously with this approach, please show me evidence to back up your claims. I might trust a usability test but I am certainly not taking your word on what is good user interface and what's a bad one. So as long as you can try to even consider these three points, we can probably have a very interesting discussion and perhaps it might even lead to something useful. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 10:24:46PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Giles [EMAIL PROTECTED] writes: I don't think the list can afford to lose the input of either one of you. Don't worry. We are just having some fun. At least I hope that Marc does. I am certainly enjoying it. I am certainly not enjoying it; I don't see it as having fun, either, and I must say you have weird ways of enjoying yourself. I am trying to make you realize that ignoring problems does not make them go away. Sorry for being a pain in the ass... -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 10:48:15PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Huh? Is it all over already? That would be a pity. I won't let you drga me down to that level of discussion. So when you want to rant about lies and accusations, feel free to do so without me. I cannot reproduce most of your problems. Which would be? Why does your inability to partly reproduce problems mean that I cannot be taken seriously? I simply want you and anyone else who wants to have a discussion on the file-chooser to do three things: (1) Use the latest GTK+ 2.6 release. Most of the problems that you and others mentioned have been addressed in the meantime and it doesn't really make sense to have a discussion on bugs that are already fixed. While there are some changes, fundamentally it's the same behaviour as in 2.6.7. It's simply slowing down users who just want to type in paths. (2) Take a step back and try to understand the concepts behind the new dialog. There is room for improvement but the overall design is good. It is good because it works for newcomers and it still has a lot to offer to the expert user. As I told you before: for using the dialogs, it doesn't matter wether the design is a beauty in itself or wether it is spaghetti code. What counts is how it works for the user. And the new dialog is still not up to the level of usefulness as the gtk+-1.0 one, despite your continual claims to the contrary. Yes, this is subjective, but you need to accept that some people have different workflows and different styles of user interaction, and for some people, the above statement is true. (3) Don't try to advertise the old GtkFileSelection dialog as being the solution that we should revert too. I didn't. I did advertise the way the old file selection dialog used it's text entry as the solution for me (and others with similar complaints). For some reason you really want to misinterpret that again and again, but I am convinced that enough people have made this clear, so there really is no reason to imply that those who complain want to revert tot he old dialog. That widget sucked badly. Well, it sucked much less than the current dialog in some important respects, like text entry and completion. It's main problem was that it was completely unusable for newcomers. Probably. I admit am not concerned with that. It had exactly one feature to overcome its limitations and that was Tab completion. That was really great, and was ripped from the users, to be put back step for step and in a still very suboptimal fashion. Without Tab completion the old dialog was pretty much unusable. Well, that's quite subjective, but I think it sufficed quite nicely for the simple task of selecting files. It was no worse than most other file dialogs around. The new dialogs have many more potentially useful features (even for me). The pity is that the old pretty unusable file dialog was much more supportive than the current one (again, for me, and at least the few others who have complained similalry). I'd take it back everyday, regardless of what it means for other I'users. Now, before you accuse me of asking you to revert the dialog *again*: no, I did not mean to say that, and I did not say that, if you read closely. The problem here is that Tab completion is not something that people can discover. At least not the larger part of our userbase. So if you want to revert to the old dialog, don't expect to be taken seriously. Well, well... but the gtk+ people who designed the current dialog vividly disagree with you on that. After all, the current dialog is full of features that are not discoverable. You should explain why you outright refuse to consider tab completion (I interpret not taken seriously as an refusal to seriously consider something), even though it's part of the current design and despite the fact that people actualyl complain about discoverability issues with the *new* file dialogs. If discoverability of features is the goal of the new dialogs, they clearly failed. If you insist on being taken seriously with this approach, please show me evidence to back up your claims. I, and others, did so. I know you want to ignore it (and you do). I just find it annoying of you to ask or details again and again and the accuse people of not providing details (or worse). If you want to ignore it anyways, just say so, so people can stop wasting their time. It should be *extremely* and *crystal* clear of what people want: a visible text entry, and tab completion as in the old gtk+ file selector. There is even code that shows the behaviour. I don't know what evidence you want, to be taken seriously. Isn't people arguing for it all the evidence you need? So as long as you can try to even consider these three points, we can probably have a very interesting discussion and perhaps it might even lead to
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 09:28:56PM +0200, Michael Schumacher [EMAIL PROTECTED] wrote: I still believe that making language-specific menus is a disservice to users. It's only use is for marketing of the language in question (oh, so it's in script-fu!). But such ideas were and probably are unpopular within a community that prejuduices some languages over others. You didn't miss the current efforts or restructuring the menus, did you? I very likely did miss them. That's why I wrote as script fu does (or did) because I am not that well-informed about future menu plans. Not even about the current cvs menus. If it coincides with what I stated as my goals and preferences then just the better... (Please note that I was asked a specific question and gave a specific answer. I did not criticise current or future plans). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Integrated Scripting
now that marc and sven have had their fun and we have all been allowed an example of how the perlized obfiscuates script-foneys with equal yet different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? questions i have are these: what of the history of Xtns? it seems to be steeped in mystery and mis-use people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. is there a sane way to include a script from each of the languages? examples: font-mapping, yinyang drawing; all the scripts have one. some of the scripting languages have an example that shows how to use the script; however the result of using it is ugly. suggestions: identify these example scripts. include a menu entry for each of the gimp script powertools: the browsers the consoles the servers help browsers potentially helpful non-gimp urls what are other useful Xtns submenues: gimp-perl installs helpful menus to the Xtns menu: Render Animation script-fu uses useful subsubmenus of: Utils Misc my own instance of gimp, i have made submenus: Color PhotoGalleries i personally would not mind keeping Kevi1 busy with changes to Tiny-fu for a while, however, i am uncomfortable with the limited view i have had of the menu reorganization. my completely unresearched opinion was formed while seeing that it is being handled by people who have not actually experienced the whole gimp eh, experience. i also would be one of these people. i can at least see that by the time i started to use gimp, everything that appeared in Xtns were plug-ins that did not need an image to start with. fixing the problem with different types of scripts that do the same job in Xtns where it is much more of a problem will help everyone with the Image menu which has a few instances of this but not as many. thanks carol() ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: As I told you before: for using the dialogs, it doesn't matter wether the design is a beauty in itself or wether it is spaghetti code. What counts is how it works for the user. And the new dialog is still not up to the level of usefulness as the gtk+-1.0 one, despite your continual claims to the contrary. I believe that we got more complaints about the old dialog than we got about the new one. At least not since the worst problems of the new dialog have been fixed. That makes me think that the new dialog isn't all that bad compared to the former. Most of the complaints seem to come from people who got accustomed to the old dialog and haven't really tried to approach the new one yet w/o leaving the old habits behind. Of course that's an assumption but the discussions that evolved around these complaints seem to show that. Yes, this is subjective, but you need to accept that some people have different workflows and different styles of user interaction, and for some people, the above statement is true. Of course. That has never been questioned. But I am not concerned with that, at least not as much as with the usability of GIMP for new and infrequent users. (3) Don't try to advertise the old GtkFileSelection dialog as being the solution that we should revert too. I didn't. I did advertise the way the old file selection dialog used it's text entry as the solution for me (and others with similar complaints). So far noone has made a proposal on how such an entry should be integrated with the current dialog. So I don't have much chance but to assume that what you have in mind is basically the behaviour of the old dialog. Perhaps you aren't suggesting to revert to it code-wise, but I haven't yet seen a detailed proposal on how an entry with Tab completion is supposed to work without bringing back the problems we had with the old dialog. I certainly wouldn't want to miss the current key-navigation behaviour. But perhaps you can offer a viable alternative? Such an alternative would have to be a concept for the whole dialog. Just adding an entry with Tab completion is going to ruin the whole thing. It's main problem was that it was completely unusable for newcomers. Probably. I admit am not concerned with that. See. That is the main problem with your approach. You are only concerned with your needs. That is all valid but you should at least try to look at the bigger picture or else I don't see how we can get anywhere if we are discussing user interfaces. Well, well... but the gtk+ people who designed the current dialog vividly disagree with you on that. After all, the current dialog is full of features that are not discoverable. The question here is if the dialog works w/o discovering these features or if it leaves the average user frustrated. IMO the new dialog does a better job because it works somewhat better even before you discover that it can be used without the mouse. You should explain why you outright refuse to consider tab completion (I interpret not taken seriously as an refusal to seriously consider something), even though it's part of the current design and despite the fact that people actualyl complain about discoverability issues with the *new* file dialogs. Your interpretation is nuts then. I have never said anything against Tab completion. Actually I very much welcome the changes to the completion behaviour in the Save dialog that came with GTK+ 2.6.8. If you tried, you might have noticed that you can finally use the Tab key to expand to the common prefix of existing files. That was one of the concerns that were taken from GIMP users to the people actually working on the file-chooser. It took a while but I think that it now works quite well. If discoverability of features is the goal of the new dialogs, they clearly failed. I agree that there are too many undiscoverable features, like Ctrl-L (which is probably just there to kill the trolls) and the more useful keybindings which are carefully hidden away. If you insist on being taken seriously with this approach, please show me evidence to back up your claims. I, and others, did so. Marc, I am sorry, but your own personal user experience is not evidence. Nor is mine or anyone else's. I admit that it isn't fair to ask for evidence here because you and me both don't have the resources to deliver facts about the usability of these dialogs. It would certainly be interesting, and probably helpful, to actually collect such data and compare different file dialogs in carefully designed tests with a variety of users. If you or someone else can come up with a detailed mockup of an alternative dialog and if we could write a prototype that actually works, I am quite confident that we could persuade someone to do a usability test on it. Sven ___ Gimp-developer mailing list
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wednesday, June 22, 2005, 0:18:34, Sven Neumann wrote: So far noone has made a proposal on how such an entry should be integrated with the current dialog. What's wrong with the place Inkscape puts it? -- Jernej Simoncic http://deepthought.ena.si/ All inanimate objects can move just enough to get in your way. -- Law of Inanimate Mobility ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Hi, [EMAIL PROTECTED] writes: So far noone has made a proposal on how such an entry should be integrated with the current dialog. What's wrong with the place Inkscape puts it? The place is probably OK, despite my feeling that it adds clutter. The real problem though is that an entry only makes sense if it has the keyboard focus. In Inkscape it doesn't have the focus initially so you need to press tab several times before you can start to use the entry. As soon as you tab into the entry, your keyboard focus is grabbed there (well, there's Ctrl-Tab to get out of an entry but we aren't really improving on discoverability here...). Of course one could focus the entry initially but then you wouldn't be able to navigate the file list with the keyboard any longer or use typeahead which IMO gives more direct feedback than Tab completion. If you just add an entry to the current dialog you don't get the current dialog with the extra benefit of an entry with Tab completion. Unfortunately what you get is a dialog that has two orthogonal ways of navigating it with the keyboard and both ways keep getting into the way of each other. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On Tue, Jun 21, 2005 at 07:18:25PM -0400, Nathan Summers wrote: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. the word Development was frightening to me. i stayed a respectful distance away from it for probably too long. scripting gimp is easy and somewhat empowering to me (only on my computer so far, it would be nice to see some reflection of this feeling in my real life). i found that there was a similar situation involving the file named HACKING in the cvs source. this file contained helpful and perhaps necessary information, however there seemed to be a gender related bias towards looking at it. and equally frightening name Personalization is also not a good word, but it comes closer to what scripting gimp is like for me. actually, the thing that is wrong with this name is that it overlaps with the meaning of Preferences. Authoring misses both marks, while perhaps hitting a couple of marcs at the same time. Diving? Dive In is probably more to the point of what actually happens when you are of the mind to make gimp work a certain way and tackle this need with scripting. Development as a word should be used (both ways) more respectfully than is fun, or educational, or attractive to the larger group of people who can use this stuff and grasp how to use it. potentially helpful non-gimp urls That opens another can of worms, but to be brief, I like the idea of having such urls either being redirects from the gimp website, or dynamically updated every gimp startup. the best argument i heard against non-gimp urls being made available as the gimp urls are now is maintenance. can of worms is another interesting argument against this. i find the python library reference extremely useful when i am scripting. i dont need to get it through gimp though. both the perl and script-fu urls i have looked at scare the beegeebies out of me. i personally would not mind keeping Kevi1 busy with changes to Tiny-fu for a while Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. no, but he has been willing. the not trivial portion of the change is the number of scripts that will need it. , however, i am uncomfortable with the limited view i have had of the menu reorganization. my completely unresearched opinion was formed while seeing that it is being handled by people who have not actually experienced the whole gimp eh, experience. i also would be one of these people. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. inspite of the very very not fun life changes that seemed to be triggered when i worked on another wiki, part of the reason for this thread was so that i could take the opinions of the developers who know what is going on, who might have something left to lose by volunteering at the gimp wiki. unless there is a reason that everyone should lose their life, their stuff and their little little place they carved out for themselves. i can at least see that by the time i started to use gimp, everything that appeared in Xtns were plug-ins that did not need an image to start with. Not technically true, as script-fu scripts are implemented through an extension, not a plug-in, but this only reinforces the point that no one knows/cares about the distinction. well, it is nice to start weird and perhaps not so well maintained scripts from somewhere not File. it is not a necessity, however, i know the lack of maintenance feeling i get is only gotten from when i use anything in Xtns. scripts that do not run nicely with the defaults (script-fu fontmap was like that (i have too many fonts installed)) and scripts that will cough up a DEPRECATED warning: i feel better when this happens from Xtns-- and not from File-- fixing the problem with different types of scripts that do the same job in Xtns where it is much more of a problem will help everyone with the Image menu which has a few instances of this but not as many. My suggestion is that Xtns menu items that create images should be called something like File|New Generated Image and that the rest should be merged with the other dialogs, ether as File|Dialogs or as a new toplevel Dialogs menu item. if new users are the concern, i have found that one of the biggest problem that people who are new to computer graphics has is the lack of understanding about what size image you need to have for the different jobs that graphics are being used for. meaning, they want to print their little 125x75pixel icon of bart simpson (for example) as a photograph. my idea was to
Re: [Gimp-developer] Integrated Scripting
Nathan Summers writes: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, File-Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly. for example. I know that the reason for the difference is that the Dialogs are implemented by the core, but why should I care? You shouldn't. include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. Right. If it were up to me, I'd split Xtns into two menus: 1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like: Module Manager Plug-in Browser Procedure Browser Unit Editor Script-Fu Console... Refresh Script-Fu Start Script-Fu Server... Python-Fu Console... Python-Fu Browser... 2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word Script-Fu. Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too. There was some suggestion on IRC that not all the items in the Xtns-Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples; if there are some, maybe they should go somewhere else. Likewise, if there are items in Filters which create a new image rather than working on the current one (I don't know of any) then they should move here. I'd lean toward making both these menus top-level menus in the toolbox window (so there would be four menus, not three), but that would cause space issues in verbose languages and large fonts, so alternately, I'd make Development a submenu (probably of File or File-Dialogs, not of Xtns/Generate/whatever, since the Development items do not create an image). It's more important that the New Image Creating stuff be easy to access than that Development is, because anyone developing scripts for gimp knows enough to use tear-offs, or set up key bindings, or somehow make it easier to get to the language tools. Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. I'd be happy to do the work if we reach consensus on what should be done. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. That's also what discussion on mailing lists, bugzilla and IRC are for. We still won't encompass the whole gimp experience, but at least by doing things in the open we'll have a chance of hearing from a range of people. My suggestion is that Xtns menu items that create images should be called something like File|New Generated Image and that the rest should be merged with the other dialogs, ether as File|Dialogs or as a new toplevel Dialogs menu item. I'd argue for that menu being a toplevel menu, so users are more likely to explore it. There are some cool scripts in there. There's some reorganization that could usefully be done inside that menu as well. Buttons only has two items, Misc only has Sphere, Utils only has two items. How about moving those five items up to be directly visible in the Generate/Create menu? So it would look like this: Logos Make Brush Patterns Web Page Themes --- Custom Gradient... Font Map... Round Button... Simple Bevelled Button... Sphere... Thoughts? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 00:18:34 +0200 (3) Don't try to advertise the old GtkFileSelection dialog as being the solution that we should revert too. I didn't. I did advertise the way the old file selection dialog used it's text entry as the solution for me (and others with similar complaints). So far noone has made a proposal on how such an entry should be integrated with the current dialog. So I don't have much chance but to assume that what you have in mind is basically the behaviour of the old dialog. Perhaps you aren't suggesting to revert to it code-wise, but I haven't yet seen a detailed proposal on how an entry with Tab completion is supposed to work without bringing back the problems we had with the old dialog. I certainly wouldn't want to miss the current key-navigation behaviour. But perhaps you can offer a viable alternative? Such an alternative would have to be a concept for the whole dialog. Just adding an entry with Tab completion is going to ruin the whole thing. Sven, you've been offered a solution -- just add an entry with tab completion. You may not agree with it, but it's not accurate to say that noone has made a proposal on how such an entry should be integrated with the current dialog. Just stick it on the bottom of the dialog, just above the OK/cancel boxes, and Marc and I will be happy to shut up. In what way is just adding an entry with Tab completion going to ruin the whole thing? If it's there, but isn't used, it isn't going to interfere with anything else, is it? And why is it so important that there be a concept for the entire dialog beyond what works best for people? The problem (to me, and I daresay to Marc) is very simple -- there's no obvious way to simply enter a pathname with a simple form of completion that's only activated on demand. A file dialog without this is just plain fatally flawed. Make it a configuration option, if you like. Just stick the text entry box with tab completion anywhere on the dialog -- I really don't care where, as long as it's part of the dialog, not some silly pop-up box, and I don't have to do something each time that I want to activate it (since I'm personally going to use the text entry box every time I want to open a file, even one extra keystroke or mouse gesture adds up over time, while if it's a configuration option I only have to do it once). My first experience with the new configuration dialog was absolutely brutal. I couldn't believe that I was being presented with a file dialog that had no text entry box (I spent a while exploring it to try to find the button that would give me the entry box), and given the way I jumble everything together, searching around in a list entry is hopeless (I have about 1000 files in one directory; I know a lot of the filenames by memory, but being forced to do a linear search through that many files is simply absurd). I more or less stopped using the GIMP altogether for a while; I used Cinepaint or xv (!) despite it being obsolete in many ways where I could, and otherwise started a new instance of the GIMP each time I had to use it, because dealing with the file dialog was so hopeless. Eventually after poking around Google I found the ctrl-L hack, but it's still very clumsy compared to the simplicity of a text entry box. Bookmarks are of no use to me because I have a lot of files that I work with whose names I generally know by memory. They don't scale; after you have more than maybe 10-20 of them it runs into the same problem of searching, whereas my memory for my own images is associative (reasonably close to constant time lookup). I'm also absolutely hopeless at maintaining any kind of organization of this kind. Anyone who tells me that I should organize my files differently will be told (politely or otherwise) to fsck off. I've used emacs for over 20 years (hence the preference for a simple filename entry with tab completion), and this form of organization for much longer than that (long before I knew what a computer was), and this way of working is by now completely ingrained into me. I'm a slob who simply dumps things wherever it's convenient. In addition to having to remember where files were, if I were to reorganize everything I'd have to mess around with kimdaba for a while to get everything back to how I have it. I've read some of the stuff on the GNOME mailing lists, and quite frankly I can't believe what I see there (e. g. file dialogs should go away, and everything should be done through the file manager or some such). This is design for its own sake rather than design for what's actually usable. I have half a mind to do a fork of GTK+ just to fix the file dialog. This would really be an insane thing for me to do. I really need to put my very limited free software time into Gutenprint, or at least dcraw, not this. If I'm so exasperated by the file dialog that I
[Gimp-developer] Bevel/Innerbevel effect
hi! i am new here! i am trying to code in basic a drawing effect. afak this effect i am looking for, is called inner-bevel !?? i dont know where to start and cant find any source nor tutorials about how to code such an effect ;-/ so i thought i would contact you and maybe someone of you may be so friendly and may help me? would be really great! thanks in advance.. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On Tue, Jun 21, 2005 at 05:38:36PM -0700, Akkana Peck wrote: Nathan Summers writes: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. the one situation that i found this condition of gimp to be effective for was to quickly figure out what was installed and what wasnt when helping people to debug scripts or install necessary scripts. that usefulness is gone now. people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, File-Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly. thanks for agreeing! include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. Right. If it were up to me, I'd split Xtns into two menus: 1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like: Module Manager Plug-in Browser Procedure Browser Unit Editor Script-Fu Console... Refresh Script-Fu Start Script-Fu Server... Python-Fu Console... Python-Fu Browser... perhaps Scripting with submenus like that with the addition of: Perl Server Perl Console Perl Browser with the assumption that a perl console and browser can be written. 2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word Script-Fu. Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too. i still find the idea of Utility very appealing. especially when considering where some scripts i wrote should go. silly scripts that generate web pages which will report what resources your gimp has access to. and plans i have for scripts that can apply parasites to groups of images. i also think that grouping the other plug-ins that make new images by resolution somehow would be most helpful to new users and not so well-educated older users and converts. use politically correct words for this like screen and other words that define the media that images are used on. Web Page Themes actually does do exactly as promised. instead of Create or New Images, the menu entry that gimp-perl installs that is called Render seems fitting. and Animation which i am using for my python animation scripts. it has been nice to have this menu there for this, i cannot imagine a better place to put it and do not want to search through Create or Render to find them. most of them are more like Alter Stacks. I'd lean toward making both these menus top-level menus in the toolbox window (so there would be four menus, not three), but that would cause space issues in verbose languages and large fonts, so alternately, I'd make Development a submenu (probably of File or File-Dialogs, not of Xtns/Generate/whatever, since the Development items do not create an image). It's more important that the New Image Creating stuff be easy to access than that Development is, because anyone developing scripts for gimp knows enough to use tear-offs, or set up key bindings, or somehow make it easier to get to the language tools. i do not mind moving the scripting stuff. i admit, i have grown fond of Xtns and cringe when i think of this name changing. i can see how difficult it must be to translate, however. Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. I'd be happy to do the work if we reach consensus on what should be done. i feel the same way, especially about the consensus part. if it means agreement the way it is being used here. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. That's also what discussion on mailing lists, bugzilla and IRC are for. We still won't encompass the whole gimp experience, but at least by doing things in the open we'll have a chance of hearing from a range of people. My suggestion is that
Re: [Gimp-developer] Integrated Scripting
On Wednesday 22 June 2005 11:36, Carol Spears wrote: On Tue, Jun 21, 2005 at 05:38:36PM -0700, Akkana Peck wrote: Nathan Summers writes: Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. True, but... the one situation that i found this condition of gimp to be effective for was to quickly figure out what was installed and what wasnt when helping people to debug scripts or install necessary scripts. that usefulness is gone now. Could a language-related mini-icon (16x16 or smaller) against each menu entry help? Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/Member, Linux Australia ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
