Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, Jun 22, 2005 at 11:53:18PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: That is, I think the fundamental flaw. A user interface that works for the majority is a pretty idiotic goal. A user interface should work for ALL users, and likely should have features to support the majority. Yeah, of course. If it works for all users, that's even better. Are you trying to make an argument out of this now? Are you trying to argue? Maybe there is hope for you then, although the above is not an argument. It's better than activey ignoring what people write. So that argument is *completely* and *utterly* bogus, firstly because you equate majority==newbies, and secondly because it's not a viable goal at all. So let's see then. The goal is to please you and ignore the majority? You have weird ways of deliberately misinterpreting and twisting other persons words. What does it buy you? Time? Ignorance? Shying away people? Developers are also users. But the same argument holds true for users. You can't find out facts about a user interface by discussing it. Yeah, that should work, except here, as you immediately drive ad-hominem attacks and spread FUD (again...). I don't think it's even remotely possible to really discuss these issues with you. at any discussion out there. It is always a few people who are very loud at complaining. Are these users representative? No, they aren't. You jump to conclusions. Maybe they are, maybe they are not. But I already said that designing just for the majority is an idiotic goal, one that gtk+ certainly _does not follow_, so telling me that that goal would be a good goal contradicts reality. agree on. But that is not the case here. So, that's why I have made the offer of organizing a usability test with the goal to gather some facts on the current design compared to whatever we can come up with as an alternative. Feel free to ignore that offer. Well, I certainly didn't ignore it, and unfortunately you know that. But if you do, don't expect me to ever discuss user interface issues with you again. Yes, we *know* that your goal is to talk down and ignore this issue. Hint: you did succeed again. The original problem was you accusing me of ignorance. That has been proven to be a lie. So please don't continue with it. Just because you claim something doesn't mean it is proven. Sorry, but that really is what I think is happening. It's far from being a lie. Still you failed so far to give a detailed and useful description of your problems. That's another of _your_ lies. Sorry to use that word, it's really not appropriate, but aybe if I talk in your language communicaqtion improves? I even pointed you to working code that exactly reproduces the desired behaviour (but it's not gtk+2 compatible, if you meant that. And if you meant that, say so). You listed a few things but you never got further than half a sentence on each of them. Another of your lies. You tactics is very simple: people complain and explain, and you accuse them of not explaining and lieing. Then people explain some more (because they have no idea which part of their explanatiomn you didn't understand) and then they get some more accusations. In the end, you simply ignore them in good shape, as you always tried to discuss, it's always the others who play bad and fail to explain their issues. I still don't know what your complaints really are but You should certainly know *that* by now, even if you might miss some details. If you are really that dense, then for your sake just *ask* instead of just producing more accusations. Just because you don't understand something does _not_ mean people tried hard to explain it. Just review tis thread. But as your goal is not discussion but ignoring others (for whatever maybe understandable reasons), this only drives people away again, with no resolution for either side. It's just too frustrating to explain things again and again and be told to stop whining and start explaining things. that you want the text entry back. Well, at least that part got through. A useful complaint includes use cases, describes a certain workflow and outlines where the current UI gets into your way. This has been done multiple times. You keep ignoring this and ask for it. Maybe you don't receive all of the mails from this list? In any case, I just tried to point out to you that you factually do ignore this kind of discussion (in a very active way, actually, but nevertheless), but you still don't get it. I won't intrude further into your world, as all I wanted to do has been done, even though I couldn't get through to you like so many others couldn't. I am out of here again -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Thursday, June 23, 2005, 2:18:57, Robert L Krawitz wrote: Here's one: add a text entry box at the bottom of the screen, and use a different key (say, shift-tab) for completion. My suggestion would be to use Tab for completion, but only if the user typed a few characters first - if he didn't, use Tab to jump to the next widget. Another possibility would be the End key - I noticed that on Linux, Ctrl+L dialog autocompletes the currently entered text (in Ctrl+L dialog - it doesn't do this on Windows) and that you can already use End to confirm this completion. I've seen quite a number of people -- Marc, Alastair Robinson, Bill Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael Thaler, and myself -- complain more or less vociferously about this, for what appears to be more or less the same reason. Alan Horkan appears to have at least some complaints about it, Dennis Bjorklund appears to be defending it mildly, and you're defending it strongly. So by my count, we have There's definitely more of us - otherwise no Windows port of GTK+ programs would offer native Win32 dialogs, and there wouldn't be a plug-in for Gimp that adds native dialogs. -- Jernej Simoncic http://deepthought.ena.si/ Always remember to pillage before you burn. -- Attila's Instruction ___ 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, Robert L Krawitz [EMAIL PROTECTED] writes: Isn't that at least enough reason to take a closer look at the issue? Are you as well starting with this accusation now? We are taking a close look at this. We have already spent a lot of time on this, probably way more than we should. I have been contributing patches and suggestions to the file-chooser for quite a while now. This has turned the dialog into something that works rather well for me. Perhaps it is time that you start doing that as well. The only reason why someone sensible would complain on this subject on the gimp-developer mailing list is that he/she wants to discuss the issue in the context of using the dialog from within GIMP. The goal of such a discussion should be to prepare a proposal or even patches in order to present them to the GTK+ developers. You complain, we talk about your complaints. What did you expect to happen? 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
Von: Bill Kendrick [EMAIL PROTECTED] * Don't try to access my A: drive every time a dialog appears. If I really cared about the A: drive (I don't), I'll probably click on the icon for it! I heard others complain here that the file dialogs take FOREVER, since they try to hit every network file share on their Windows system. Yuck! Is this the current version of GTK+? This didn't happen for me since 2.6.7, iirc. Michael -- Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden testen ++ http://www.gmx.net/de/go/promail ++ ___ 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: Thu, 23 Jun 2005 10:35:51 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: Isn't that at least enough reason to take a closer look at the issue? Are you as well starting with this accusation now? We are taking a close look at this. We have already spent a lot of time on this, probably way more than we should. I have been contributing patches and suggestions to the file-chooser for quite a while now. This has turned the dialog into something that works rather well for me. Perhaps it is time that you start doing that as well. The context for this was: Marc, it is you who's being idiotic here. You state that there are a number of people. What number? How large is that number compared to the number of happy users? We can hardly decide anything unless we know the answer to these questions. You asked how many people were involved here. I went and looked at how many people have posted on precisely this issue, and posted my numbers. I've been contributing suggestions both here and on the bugzilla.gnome.org bug (whose number I forget). Yes, it's true that my suggestion boils down to bring back the text entry box! and not a whole lot else. Every time anyone here makes that suggestion you dismiss it with You basically have no clue on how the new dialog works or I have already explained [how a text entry with completion would conflict with being able to use the file dialog's other features] without really getting to the heart of the matter -- a lot of people just plain want a text entry box, because it's such a natural way to work (a filename, or pathname for that matter, is a text string, and people just want to be able to type it in a natural manner). The only reason why someone sensible would complain on this subject on the gimp-developer mailing list is that he/she wants to discuss the issue in the context of using the dialog from within GIMP. The goal of such a discussion should be to prepare a proposal or even patches in order to present them to the GTK+ developers. The only GTK2 app that I use on any kind of routine basis that uses this dialog is the GIMP. This has given me a good reason to do everything I can to avoid other GTK2 apps. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ 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
Date: Thu, 23 Jun 2005 07:43:07 -0400 From: Robert L Krawitz [EMAIL PROTECTED] I've been contributing suggestions both here and on the bugzilla.gnome.org bug (whose number I forget). Yes, it's true that my suggestion boils down to bring back the text entry box! and not a whole lot else. Every time anyone here makes that suggestion you dismiss it with You basically have no clue on how the new dialog works or I have already explained [how a text entry with completion would conflict with being able to use the file dialog's other features] Actually, I should correct myself here: the second comment (explaining how the text entry would conflict is a legitimate explanation, not merely dismissing objections. ___ 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
to the number of happy users? We can hardly decide anything unless we know the answer to these questions. I've seen quite a number of people -- Marc, Alastair Robinson, Bill Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael Thaler, and myself -- complain more or less vociferously about this, for what appears to be more or less the same reason. Alan Horkan appears to have at least some complaints about it, I do not disagree with Sven on this. Please do not count me in on this arguement, I probably should not have commented at all. On balance the new file chooser is better, it just happens to be worse in some of the ways the old file chooser was good and I do recognise it has issues. On balance I support the new File Chooser. I see the problems with it as mostly GTK problem. You cannot really argue against the merits of a clean API that allows you to go ahead and write your own replacement. Now that i think if it GPE are one of the few groups who have gone ahead and done this, and I am increasingly tempted to attempt it myself (but dont hold your breath it would take me a long time to develop something I would be willing to show in public). - Alan H. ___ 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
Date: Thu, 23 Jun 2005 21:13:41 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] I do not disagree with Sven on this. Please do not count me in on this arguement, I probably should not have commented at all. On balance the new file chooser is better, it just happens to be worse in some of the ways the old file chooser was good and I do recognise it has issues. Fair enough. ___ 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, Robert L Krawitz [EMAIL PROTECTED] writes: I've been contributing suggestions both here and on the bugzilla.gnome.org bug (whose number I forget). Yes, it's true that my suggestion boils down to bring back the text entry box! and not a whole lot else. Every time anyone here makes that suggestion you dismiss it with You basically have no clue on how the new dialog works or I have already explained [how a text entry with completion would conflict with being able to use the file dialog's other features] without really getting to the heart of the matter -- a lot of people just plain want a text entry box, because it's such a natural way to work (a filename, or pathname for that matter, is a text string, and people just want to be able to type it in a natural manner). Hey, what the heck is this about? I accept the fact that a lot of people want the text entry back but I am not the maintainer of the GtkFileChooser dialog so why do you care about my opinion? I will continue to tell people that I don't think the text entry should be added back but of course I don't care if it is being added back as long as I can switch it off. If you want the text entry back, go add it back. I even expect the GTK+ developers to accept a patch if it works well and uses XSettings to make it optional. The only GTK2 app that I use on any kind of routine basis that uses this dialog is the GIMP. This has given me a good reason to do everything I can to avoid other GTK2 apps. If only I could get rid of the few apps that I still have to use that don't use the new file chooser yet... 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, Dennis Bjorklund [EMAIL PROTECTED] writes: In the gtk2 dialog when you start to type you get a popup entry widget where you can only type in entries that are in the current file list. From a user perspective I don't see any drawbacks if one could type in any path in that entry box, with tab completion. Currently this popup entry box is tied to TreeView and I don't know how easy it is to customize, but it's all part of gtk so anything can be changed. IMO it is important that typeahead in the file chooser works just like typeahead in all other list and tree views. I don't think that changing the behaviour of typeahead is a good idea. I also doubt that it will silent the people asking for an entry box. CTRL-O- open dialog /tmp - ends up in the popup entry and you can use TAB-completion ENTER - show the temp directory in the dialog Here's what I do to achieve that: Ctrl-O, /t, Enter CTRL-O /tmp/foo.png- here I used tab-completion :-) ENTER - dialog closes and image is opened Here's what I do to achieve that: Ctrl-O, /t, Enter, f, Enter Your proposal makes some sense, I am not convinced that it is a good idea but it should probably be considered. 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, Robert L Krawitz [EMAIL PROTECTED] writes: 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. This is not about making you and Marc shut up. This is about designing a user interface that works for the majority of users. Whatever we do, there will always be someone complaining. I don't really care who that is. 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? It does indeed interfere with the rest of the dialog, otherwise it would probably have been added a while ago already. But I already explained the problems of this approach in another mail that I sent last night. 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. The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. Make it a configuration option, if you like. No, I don't like configuration options, I hate them. And it would also not have to be me who adds it but the GTK+ developers. We are certainly not going to fiddle with the internals of the GtkFileChooser widget. 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. I agree that the Ctrl-L is clumsy and I would like it to be removed (of course after it has been completely obsoleted). But you don't really need Ctrl-L to use the dialog. I am sorry that you made your first experiences with the new dialog with the early versions that were indeed rather akward to use. 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
On Wed, 22 Jun 2005, Sven Neumann wrote: IMO it is important that typeahead in the file chooser works just like typeahead in all other list and tree views. I don't think that changing the behaviour of typeahead is a good idea. One can also say that it's important that typing in a path always works the same in the dialog and having different things happen when you type paths starting with / then paths without is also not good. For example, what happens if you type ../foo ? Didn't someone point out that the dialog was fixed so that when you type in something it uses the typahead of the file list (I complained that sometimes the bookmark list is focused in my verion of gtk+/gimp when I open the dialog). Does that mean that you can't use type ahead on the bookmark list? Well, I described how I want it to work. We all have our dreams. -- /Dennis ___ 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, Dennis Bjorklund [EMAIL PROTECTED] writes: Didn't someone point out that the dialog was fixed so that when you type in something it uses the typahead of the file list (I complained that sometimes the bookmark list is focused in my verion of gtk+/gimp when I open the dialog). Does that mean that you can't use type ahead on the bookmark list? If the bookmarks list has the keyboard focus (which it shouldn't have initially), then you can of course use typeahead on the bookmarks list. Not sure what fix you are referring to but this seems to be some kind of rumour. 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
On Wed, 22 Jun 2005, Sven Neumann wrote: If the bookmarks list has the keyboard focus (which it shouldn't have initially), then you can of course use typeahead on the bookmarks list. Good. Not sure what fix you are referring to but this seems to be some kind of rumour. I couldn't find the mail now but I think someone in the thread said that typeahead now worked in the open dialog no matter what widget in it had the focus. Not important anyway, this problem is fixed as far as I understand. Just for fun I put in an enhancement bug in the gtk bugzilla for making the type ahead in the file dialog specialized for paths. So that you can type bar/foo in it and jump directly to that sub directory. bar/foo is not an entry in the current list view, just bar is in this example so it would not work with normal type ahead. But making the type ahead specialized for paths in the file dialog is as I described it before a good idea to me. I don't really expect it to change anything, but maybe one could get some comment from the gtk+ developers about the idea. http://bugzilla.gnome.org/show_bug.cgi?id=308618 And if you guys want to add anything to the bug, please be polite and don't make it into a flame-bug :-) -- /Dennis ___ 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 Wed, Jun 22, 2005 at 12:59:33AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Not a _single_ problem I described been changed (I originally assumed that the kills the selection problem has gone away, but it's still there). What is kills the selection? I haven't been able to make anything out of that term. No problem: make a selection, open the file dialog, start typing = the selection is gone (this is an illness that generally started to spread within the last 6 months, at least I have never seen programs doing that before, now lots of programs do that). -- 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 Wed, Jun 22, 2005 at 12:18:34AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: 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. In the case of tab completion, you don't seriously want people to leave the old habits behind? That argument has a problem: old habits are not bad at all. Habits are bad if they can be improved. But in this case, making tab completion slower and/or more clumsy and difficult to use is not really a useful option. Or, put in other words: just becasue it's new and difefrent doesn'T automatically make it better. Yes, this is subjective, but you need to accept that some people Of course. That has never been questioned. Well, many of the things you say certainly sound as if there would be only one valid workflow, and whoever doesn't use it is mistaken (for a very mild example see the old habits argument above. There is no logical connection between old habits and bad habits). But I am not concerned with that, at least not as much as with the usability of GIMP for new and infrequent users. Well, if those features get in the way of more experienced people, I'd be strictly against it. But we can easily disagree on this point... (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. Argh. Lots of people have. If you look closely, many people just asked for a text entry. Integrating that into the dialog would make tab completion the old way very natural. Given that there *are* proposals, a) why do you say no one proposed it and b) what would the possible problems be? I can easily understand that keyboard shortcuts get in the way, but right now, typing creates a tetx entry, so entering characters is already reserved for that. Is it a limitation inside gtk+? It would be great if you could enlighten us why the proposals don't work. So I don't have much chance but to assume that what you have in mind is basically the behaviour of the old dialog. The behaviour with regards to having an entry widget and how it works. Yes, I guess you completely understood that then. Perhaps you aren't suggesting to revert to it code-wise, Certainly not. 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 am not aware of any problems with regards to tab completion in the old dialog. Talking about that might be quite productive. I certainly wouldn't want to miss the current key-navigation behaviour. But perhaps you can offer a viable alternative? What is the current key navigation behaviour? cursor keys? I don't really need cursor keys when I do tab completion, and when I need them, I could easily use my mouse to click. 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. Well, the simplest solution would be some (non-gimp) preferences to enable a text entry for those people who prefer it. (Remember that I don't ask for people to implement that. My primary concern is that the existing problems and complaints are (or were) being talked down). 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's obviously wrong. If I were the only one who'd like to have an effective tab completion I would be very very silent. So no, I am not just concerned with my needs, but with the needs of at least some more people. 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, I am mostly concerned with my needs (and have said a lot of times that you semed to have missed that I do understand that other needs need to be satisfied, too) and you said you are mostly concerned with newbie needs, so what's the big difference here? Why is it bad when I say it but good when you say it? That makes no sense... 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
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 10:12:05 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: 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. This is not about making you and Marc shut up. This is about designing a user interface that works for the majority of users. Whatever we do, there will always be someone complaining. I don't really care who that is. This one seems to be attracting a disproportionate share of complaints. Usually with other controversial interface issues I see a few comments, and then people start to converge. This one is different. 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? It does indeed interfere with the rest of the dialog, otherwise it would probably have been added a while ago already. But I already explained the problems of this approach in another mail that I sent last night. If I understood correctly, it's a conflict between the use of tab for completion and tab for jumping between widgets? If so, how about using a different keystroke for completion (escape or ctrl-tab, for example)? Perhaps another approach would be for the integrated text input to be initially hidden, but with a More button that makes it visible. The state of the More button is saved, so that the next time the dialog is popped up it has the same components as it did before. 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. The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. The problem is that there's no one method that works best for people. People like Marc and I find the old dialog much more suited to our needs than the new one. Make it a configuration option, if you like. No, I don't like configuration options, I hate them. And it would also not have to be me who adds it but the GTK+ developers. We are certainly not going to fiddle with the internals of the GtkFileChooser widget. Obviously the problem is a GTK issue, not a GIMP issue. 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. I agree that the Ctrl-L is clumsy and I would like it to be removed (of course after it has been completely obsoleted). But you don't really need Ctrl-L to use the dialog. I am sorry that you made your first experiences with the new dialog with the early versions that were indeed rather akward to use. Two problems with this: 1) There's no visual cue that typing in a filename will do anything. 2) The secondary popup is very annoying (either it's going to pop up under the mouse, in which case it's going to obscure other parts of the dialog, or it isn't going to have focus for those of us who use focus strictly follows mouse). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 09:53:20PM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: 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. Actually, the old file selector didn't just have an entry to type in. As a matter of fact, most file dialogs I know are very hard and unintuitive to use, I often end up activating all sorts of things and often have to close and reopen it to get into a sane state. Most motif programs fall intot hat category. Whta made the old dialog so special was that you could just type in paths as you could elswhere in unix - namely via tab completion. For example replacing tab by enter completely wrecks this feature, as this is not at all intuitive, because enter usually means do it (either in the shell or in a dialog), so people are not quick at pressing enter and using it as a key to press oftentimes slows down considerably. The thing is, the old dialog had this tremendously great and useful and fats and efficient (whatever) feature that make it distinct to most other file dialogs and extremely easy and joyful to use for me and all the people around me (who incidentally also use a terminal and vim to to most of their other tasks. Those people are not by any means rare in the unix world, and making their life worse by making gimp more windows-like in behaviour (such as the current file dialog does) is imho a very wrong direction: People are not used to press enter after pathname components, people are not used to use cursor-down/up to select between components, as both of those usually destroy what you were typing). _Everybody_ I showed that tab feature (that they didn't expect in clumsy graphical programs), wether on trade shows or in private, was immediately drawn in to how great it was. Similarly to the dynamic keyboard shortcuts which are not disabled by default. Those fetaures had definitely a discoverability problem, but the new field dialog is IMHO worse with respect to discovering those features. I feel (And judging from the feedback I am not alone) that removing those features (or making them harder to use) in the name of usability is the wrong approach. Making everything easy for newbies most often means making it more difficult for regular users. sometimes you can find a compromise, such as with the menu bar (again, a discoverability problem), sometimes you cannot (if tab completion is fundamentally incompatible with newbie-support). Incidentally, lots of those things have been solved by supporting both styles and using preferences to switch, and while not a perfect solution, it might well the achievable optimum. 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. This experience is close to mine, and close to the experiences of the people around me. It seems sven's standpoint is that this just needs to some more experience, or learning the new way of using the dialog, but I have to use those dialogs for quite some time now, and I simply don't believe that I am too dumb or too stubborn for the new dialog, but that it's simply slowing me down at best. 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. [Agree with all of that. The great thing is, however, that bookmarks don't seem to collide with a text entry, so one could have both, which is just great, and a win-win situation]. Anyone who tells me that I should organize my files differently will be told (politely or otherwise) to fsck off. The irony is that one gets told that the old way would be somehow inferior without any evidence and lots of evidence to the contrary. It's new and completely different, so it must be better. 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. A lot of people feel that way. 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. Yes, it would :( It's a waste of time. -- 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
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, Jun 22, 2005 at 10:12:05AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: This is not about making you and Marc shut up. This is about designing a user interface that works for the majority of users. Whatever we do, there will always be someone complaining. I don't really care who that is. That is, I think the fundamental flaw. A user interface that works for the majority is a pretty idiotic goal. A user interface should work for ALL users, and likely should have features to support the majority. The simple goal of works for the majority is nothing short of a dictatorship (while in a democracy the majority rules, the fundamental point of democracy is minority rights). If that *were* the goal, why have things like ATK, which are decidedly not for the majority? And who decides what the majority is? The newbies? I am not sure newbies are the majority of gimp users (but I am pretty sure at some point in ther future this will be the case). So that argument is *completely* and *utterly* bogus, firstly because you equate majority==newbies, and secondly because it's not a viable goal at all. 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. The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. I disagree, and I haven't actually seen evidence of that, despite hearing that a lot, I don't think developers are somehow worse off then users. Despite, I am unfortunately a mere gimp _user_ right now. This is basically the same argument, where you exchanged the majority by people, and it has the same flaws. I _am_ part of that people, as are you and other developers. The easiest way to find out is to try it, and see how it works. This is currently what's being done, and you can't complain about the negative (and also positive) feedback, so it seems to be the correct approach. Make it a configuration option, if you like. No, I don't like configuration options, I hate them. Others would love them! (In most cases there are unavoidable, wether it's themes or keyboard layout. Some people simply have different preferences. And while you hate preferences some people would be rather better of with them). And it would also not have to be me who adds it but the GTK+ developers. We are certainly not going to fiddle with the internals of the GtkFileChooser widget. Yes, the discussion has become a little bit out of bounds for gimp-developer again. Just remember that the original problem was the attitude of yours with regards to user complaints (or suggestions). 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. I agree that the Ctrl-L is clumsy and I would like it to be removed (of course after it has been completely obsoleted). But you don't really need Ctrl-L to use the dialog. I am sorry that you made your first experiences with the new dialog with the early versions that were indeed rather akward to use. Well, it's not as if this has fundamentally changed till the current version. You seem to relate all the bad user experiences to old versions, but that is not true. I based my initial response on gtk+-2.6.7, and now used gtk+-2.6.8, which is exactly the version you asked people to try. -- 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 Wednesday 22 June 2005 16:12, Sven Neumann wrote: Whatever we do, there will always be someone complaining. I don't really care who that is. While it's fundamentally true, it's also a heavily defeatist approach. What I'd like is a complicated device folded down to simple proportions so that dolts don't hurt themselves with it - but that can be easily and permanently defaulted to something more useful for people who are not and never will be the lowest common denominator. 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 Tuesday 21 June 2005 20:30, Sven Neumann wrote: 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. Ok - What about this: Hitting the easy and intuitive CTRL + L, instead of cluttering everything else with a pop-up, make such an entry field to appear, with focus in it? Therefore, nothing else would be on the way of one who can spend about a minute or two navigating the file structure and clicking on a file, while thos eint he know cna hit ctrl+L for soemthing actually usefull. Joao ___ 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 Wed, 22 Jun 2005, Robert L Krawitz wrote: Date: Wed, 22 Jun 2005 07:32:11 -0400 From: Robert L Krawitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 10:12:05 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: 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. This is not about making you and Marc shut up. This is about designing a user interface that works for the majority of users. Whatever we do, there will always be someone complaining. I don't really care who that is. This one seems to be attracting a disproportionate share of complaints. Usually with other controversial interface issues I see a few comments, and then people start to converge. This one is different. It is unfortunate that the new file chooser is bad at exactly the things the old file chooser was good at, a case of six of one half dozen of the other. (I always have a terminal open and make frequent use of gimp-remote so I dont mind to the new file chooser too much.) 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? It does indeed interfere with the rest of the dialog, otherwise it would probably have been added a while ago already. But I already explained the problems of this approach in another mail that I sent last night. If I understood correctly, it's a conflict between the use of tab for completion and tab for jumping between widgets? If so, how about using a different keystroke for completion (escape or ctrl-tab, for example)? Perhaps another approach would be for the integrated text input to be initially hidden, but with a More button that makes it visible. The state of the More button is saved, so that the next time the dialog is popped up it has the same components as it did before. 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. The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. The problem is that there's no one method that works best for people. People like Marc and I find the old dialog much more suited to our needs than the new one. Obviously the problem is a GTK issue, not a GIMP issue. There seems to be a big benefit to developers in using the new File Chooser API. I am a little surprised no one has ported the old file chooser to the new API, or written any alternative file choosers that work with the new API. (There was definately some talk of adding support for the KDE file chooser to use the Gtk File Chooser API by developers connected with Freedesktop.org or Redhat I think but I am pretty sure nothing ever came out of those wild ideas but the Gtk Developers would be the ones to ask I guess.) I notice some projects have added support for the new file chooser to make it a compile time option but mostly as a way to avoid forcing their users to use the latest version of GTK. I expect the gimp requires an up to date version of GTK for other other reasons but perhaps support for the old file chooser could be added as a compile time option (horribly inelegant and another unpleasant configuration option I know but I wanted to put it out there as a possibility). - Alan H. ___ 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, Alan Horkan wrote: It is unfortunate that the new file chooser is bad at exactly the things the old file chooser was good at, a case of six of one half dozen of the other. (I always have a terminal open and make frequent use of gimp-remote so I dont mind to the new file chooser too much.) Yes, I do that too. I alias it to gr, so the only penalty is an extra mouse click and one extra keypress. That we both go to these lengths to avoid using the new dialog says something. To my mind the biggest problem with the old dialog was that it's *really* ugly to look at! It also looks reminiscent of the old Windows 3.1 file dialog, which is a big turn-off to some people... I notice some projects have added support for the new file chooser to make it a compile time option but mostly as a way to avoid forcing their users to use the latest version of GTK. I expect the gimp requires an up to date version of GTK for other other reasons but perhaps support for the old file chooser could be added as a compile time option (horribly inelegant and another unpleasant configuration option I know but I wanted to put it out there as a possibility). I seem to remember early versions of Page Plus had a very good way of balancing the needs of experienced and new users; you could set the user interface between three modes, beginner, medium and expert, which determined how many of the advanced features were visible. Later versions broke out in a nasty case of Wizarditis, but they at least had the sense to make it possible to disable them. I think ultimately, something like this might be the answer - not for The GIMP, but for GTK+ - if I could set a flag in my .gtkrc file to say I'm not a novice, don't try and shield me from complexity I'd be a lot happier! All the best, -- Alastair M. Robinson ___ 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 Wednesday, June 22, 2005, 13:47:03, Marc)(A.)(Lehmann wrote: Whta made the old dialog so special was that you could just type in paths as you could elswhere in unix - namely via tab completion. For example replacing tab by enter completely wrecks this feature, as this is not at all intuitive, because enter usually means do it (either in the shell or in a dialog), so people are not quick at pressing enter and using it as a key to press oftentimes slows down considerably. I can think of 2 or 3 ways of doing autocompletion that would be more intuitive than how it's currently implemented - Enter is the last thing I tried, because in all other software that offers autocompletion with the help of an automatic drop-down (not just in file dialogs), Enter will confirm the current selection and dismiss the dialog. (btw, there are other things that GTK+2 just does bothersome differently from every other piece of software I use - including differently from GTK+1 programs). It seems sven's standpoint is that this just needs to some more experience, or learning the new way of using the dialog, but I have to use those dialogs for quite some time now, and I simply don't believe that I am too dumb or too stubborn for the new dialog, but that it's simply slowing me down at best. I found it easier to use Windows' Exploder to navigate to the directory where my images are and double-click the image there than to use Gimp's open dialog (and I absolutely hate Explorer). [Agree with all of that. The great thing is, however, that bookmarks don't seem to collide with a text entry, so one could have both, which is just great, and a win-win situation]. IMHO, the bookmarks would be even more usable if they appeared at the top of the list, not bottom - I've got a lot of network and physical drives, so I need to scroll the list to get to the bookmarks (another argument for this is that you can always create bookmarks for the default items in that list if you want to have those at the top). -- Jernej Simoncic http://deepthought.ena.si/ If the probability of success is not almost one, then it is damned near zero. -- Fourth Law of Thermodynamics ___ 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 Wednesday, June 22, 2005, 18:29:57, Alastair M. Robinson wrote: To my mind the biggest problem with the old dialog was that it's *really* ugly to look at! It also looks reminiscent of the old Windows 3.1 file dialog, which is a big turn-off to some people... That one was more useful - I liked having the directory tree separate, and it had a text entry (although without any completion). -- Jernej Simoncic http://deepthought.ena.si/ You're not drunk if you can lie on the floor without holding on. -- Dean Martin's Definition of Drunkenness ___ 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, Robert L Krawitz [EMAIL PROTECTED] writes: The problem is that there's no one method that works best for people. People like Marc and I find the old dialog much more suited to our needs than the new one. The GtkFileChooser widget was designed to be modular from the very beginning. There is a reason why the current implementation lives in a file called gtkfilechooserdefault.c. What keeps you from writing a different implementation that implements the GtkFileChooser interface? Two problems with this: 1) There's no visual cue that typing in a filename will do anything. I don't think that's a problem because the dialog is still usable without knowing about this and sooner or later the user will find out. After all typeahead is something that works in all list views. 2) The secondary popup is very annoying (either it's going to pop up under the mouse, in which case it's going to obscure other parts of the dialog, or it isn't going to have focus for those of us who use focus strictly follows mouse). Didn't I say already that the secondary popup is bad and should go away? What point are you trying to make? 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, Alastair M. Robinson [EMAIL PROTECTED] writes: I seem to remember early versions of Page Plus had a very good way of balancing the needs of experienced and new users; you could set the user interface between three modes, beginner, medium and expert, which determined how many of the advanced features were visible. That has been tried several times (with nautilus for example) and it has never worked. The problem is that you will very soon need a feature that is only available in the Advanced mode and then you get tons of expert features cluttering your user interface. 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: That is, I think the fundamental flaw. A user interface that works for the majority is a pretty idiotic goal. A user interface should work for ALL users, and likely should have features to support the majority. Yeah, of course. If it works for all users, that's even better. Are you trying to make an argument out of this now? So that argument is *completely* and *utterly* bogus, firstly because you equate majority==newbies, and secondly because it's not a viable goal at all. So let's see then. The goal is to please you and ignore the majority? Marc, you have yourself said that you don't care about other users. Why should we care about you then? The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. I disagree, and I haven't actually seen evidence of that, despite hearing that a lot, I don't think developers are somehow worse off then users. Developers are also users. But the same argument holds true for users. You can't find out facts about a user interface by discussing it. Look at any discussion out there. It is always a few people who are very loud at complaining. Are these users representative? No, they aren't. All the happy users will never join a mailing-list and tell us that they like the user interface. You will only hear from them if you actually change something. Then, given that they disagree with that change, they will suddenly be there, loud and clear. So it should be clear that it is a waste of time to discuss user interface questions unless they can be boiled down to some simple rules that everyone can agree on. But that is not the case here. So, that's why I have made the offer of organizing a usability test with the goal to gather some facts on the current design compared to whatever we can come up with as an alternative. Feel free to ignore that offer. But if you do, don't expect me to ever discuss user interface issues with you again. Yes, the discussion has become a little bit out of bounds for gimp-developer again. Just remember that the original problem was the attitude of yours with regards to user complaints (or suggestions). The original problem was you accusing me of ignorance. That has been proven to be a lie. So please don't continue with it. Well, it's not as if this has fundamentally changed till the current version. You seem to relate all the bad user experiences to old versions, but that is not true. I based my initial response on gtk+-2.6.7, and now used gtk+-2.6.8, which is exactly the version you asked people to try. Still you failed so far to give a detailed and useful description of your problems. You listed a few things but you never got further than half a sentence on each of them. I still don't know what your complaints really are but that you want the text entry back. A useful complaint includes use cases, describes a certain workflow and outlines where the current UI gets into your way. 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
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 23 Jun 2005 00:09:06 +0200 [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Lots of people have. Sorry but I haven't seen a detailed and complete proposal yet. If you can point me to one, please do. Here's one: add a text entry box at the bottom of the screen, and use a different key (say, shift-tab) for completion. Attach this label to the entry box: Filename: (to complete, type shift-tab) I certainly wouldn't want to miss the current key-navigation behaviour. But perhaps you can offer a viable alternative? What is the current key navigation behaviour? cursor keys? I don't really need cursor keys when I do tab completion, and when I need them, I could easily use my mouse to click. Oh well. I had the impression all along this discussion. You basically have no clue on how the new dialog works. That doesn't shed a good light on the new dialog but it also shows that you are rather ignorant. I think I asked you and everyone else to actually try to work with the dialog. I guess I will have to sit down and write a manual since you obviously haven't understood how it works. I could just as easily say that you have no clue how Marc or I work -- please keep the personal attacks out of it. You did ask Marc to try to work with the new dialog, he complied, and found it didn't help him. Or, put difefretly: in what ways would a tetx entry with completion conflict with being able to use the file dialogs other features with the mouse (and then: with the keyboard). I have already explained that in all details. See my other mail in this thread in case you missed earlier explanations. As best as I can tell, the only substantive issue is the fact that the tab key, if used for completion, would conflict with the tab key, as used to jump around the other widgets. I propose using a different key sequence -- shift-tab -- for completion. If a number of users complain about usability issues, askign them to make scientific studies before their complaints can be taken seriously is just plain idiotic. What counts is reality, and the current file dialogs, wether they worked in studies or not, fail this for quite a number of people. Marc, it is you who's being idiotic here. You state that there are a number of people. What number? How large is that number compared to the number of happy users? We can hardly decide anything unless we know the answer to these questions. I've seen quite a number of people -- Marc, Alastair Robinson, Bill Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael Thaler, and myself -- complain more or less vociferously about this, for what appears to be more or less the same reason. Alan Horkan appears to have at least some complaints about it, Dennis Bjorklund appears to be defending it mildly, and you're defending it strongly. So by my count, we have Oppose/strongly oppose 7 Mildly oppose 1 Mildly support 1 Strongly support 1 Is this proof? No. Perhaps the majority of GIMP/GTK users who are not on the list strongly prefer the new dialog. However, my experience on the net suggests that if there were other people on the list who strongly support the new dialog that at least a few of them would have popped up by now. What's more, the complaints are all very specific, and are focused on exactly the same issue -- the lack of a text entry box for a filename. Nobody here is complaining about anything else. Isn't that at least enough reason to take a closer look at the issue? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ 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 Wed, Jun 22, 2005 at 08:18:57PM -0400, Robert L Krawitz wrote: Here's one: add a text entry box at the bottom of the screen, and use a different key (say, shift-tab) for completion. The problem with Shift-Tab is that it's often used to navigate backwards through widgets in GUIs. Honestly, isn't this the kind of thing that should be getting standardized, e.g. by FreeDesktop.org? -bill! ___ 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 Wed, Jun 22, 2005 at 08:18:57PM -0400, Robert L Krawitz wrote: Nobody here is complaining about anything else. Actually, at least with Gimp 2.2 on WinXP (which is what I'm sitting in front of right now), I have issues with Save As behaviour: * Once I've saved a newly-created image in a particular place, use THAT as the default Save-As location, not My Pictures. If I'm doing artwork for a video game, for example, I have to add Yet Another Bookmark to the Save dialog, or navigate around for EVERY new image I make. I'd love it if it would remember between sessions, too! * Don't try to access my A: drive every time a dialog appears. If I really cared about the A: drive (I don't), I'll probably click on the icon for it! I heard others complain here that the file dialogs take FOREVER, since they try to hit every network file share on their Windows system. Yuck! Thx :) -bill! ___ 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 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
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] 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] 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] 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] 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] 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
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Mon, Jun 20, 2005 at 12:40:37AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well. I just told you that this is not true. Then you told me you'd not ignore complaints. Now you tell me what I should do instead and that it would work surprisingly well. 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. 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. But you should know that. We can argue wether it works surprisingly well because it's not clear what it means. To me, this surprisingly well working input is an annoyance and slow-down compared to the simple and fast gtk+1.0 selector. Just compare it to your typical shell: path input time: very few seconds. gtk+: ranging form 5+ seconds to minutes (not counting the time it takes to open the dialog). And no flickering in the shell, no extra popups and it does not even destroy your selection. Obvously, the very term surprisingly well is meaningless because other people have different definitons for what works well. And you keep ignoring this. Really. Maybe you just don't understand it. I don't know. I am 100% sure it's not malice! One thing is that people, and _many_ people, just want their location entry back, for lots of reasons: discoverability, pastability and so on. But for some reason this simply does not happen. This is an example where lots of people continually *are* being ignored because the new design is supposedly better. There's no such atttitude. The new file chooser has bugs and they need to be fixed. Asking us to revert to the old widget is however not an option. That might be true, but *if* the old widget was better for the users it should be reverted, no question to be asked. Again, there is an *if* in that sentence. (Also, I really don't see the many bugs. I see misdesign, but I would not call that a bug. There were design decisions involved, and these might be good for some uses and bad for others. At least the problems I have with the dialogs do not seem to be bugs at all, but simply design decisions). I often heard argumnts like it was a lot of work to design and implement, but there is a logical fallacy in that (a red herring): no matter how much work it was, if the result is bad, it is bad. (Now, there are probably good sides to the new file dialog, but none of the new features mean anything to me, so for me it is only negative). You also said file dialogs should go away (in some distant future) and people should use dragdrop. This is another very bad way to force unnatural (for some) workflow on people: for one thing, dragdrop doesn't work very wlel under X, for another thing it is quite difficult to actually dragdrop while prpessing your mouse button for some people. Even I who can easily do drgadrop find for example the selection much easier, because I can do things in etween and do not have to press hte button all the time, which improves my aim. The new file dialog gets more and more byzantine, without offering the simple and effective interface that the old dialog. Now I hear in the long term people should switch from it completey. That is the wrong direction, IMHO. -- 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 Mon, 20 Jun 2005, Marc wrote: One thing is that people, and _many_ people, just want their location entry back, for lots of reasons: discoverability, pastability and so on. But for some reason this simply does not happen. Do you want this only in gimp or in all programs that use the gtk+ widgets and dialogs? I think the gtk dialog can be made better and should be improved for all applications, not just gimp. Things I don't like: * In fedora 3 I can type in a filename and it selects that file in the file tree view and it just works. It does not work with full paths so I either have to navigate to the correct directory first (which I usually do using a bookmark) or have to use the hidden feature of Ctrl-L (almost never do this). If one fixes so one can type in any path directly, and not just filenames in the current selected dir, then the Ctrl-L is not needed anymore. * The file tree view does not always have input focus when the dialog is opened. So sometimes when I type in a filename the focus is in the bookmark part of the dialog and it matches a bookmark instead. Also, some keys to fast give bookmarks and filelist input focus would be nice (and tab:ing to the right widget is too much work). I've not filed any bugs for the above and I don't know if maybe this have already been improved in later versions of gtk+ then what's in FC3. It's simply not a big enough problem for me that I've done that but I still would want these things to be improved. The battle for you to fight is with gtk2 and not with gimp. If gimp started to use another dialog then what other gtk2 programs did, then people would start a fight about that. I also think that some of you in this thread are unfair to Sven. From my point of view he tries to help as much as he can. For you reverting to the old dialog is a solution, for me that would make the dialog a lot worse. I love the bookmark feature. I usually just use a couple of directories in total and I have these as bookmarks. Currently not everyone is happy with the new dialog but hopefully it can be improved so most of us are happy in the future. If not, then what do you suggest? Either way you choose someone will be unhappy. -- /Dennis ___ 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
Date: Mon, 20 Jun 2005 11:14:03 +0200 (CEST) From: Dennis Bjorklund [EMAIL PROTECTED] On Mon, 20 Jun 2005, Marc wrote: One thing is that people, and _many_ people, just want their location entry back, for lots of reasons: discoverability, pastability and so on. But for some reason this simply does not happen. Do you want this only in gimp or in all programs that use the gtk+ widgets and dialogs? Obviously this is a GTK2 issue. Currently not everyone is happy with the new dialog but hopefully it can be improved so most of us are happy in the future. If not, then what do you suggest? Either way you choose someone will be unhappy. Adding a simple file (text) entry box with tab completion (and a preference to turn on autocompletion) would, IMHO, solve virtually all of the problems. People who don't like using text entry boxes wouldn't have to use it. The ctrl-L popup has lots of problems; not only is it not apparent how to get to it (there's nothing that points at ctrl-L), but it's very clumsy to use (you have to type ctrl-L, type in the filename -- while having to deal with its quirks -- and then click OK twice). And no, bookmarks are NOT a complete solution to this. I have probably 200 bookmarks in Firefox (for example), and finding the right bookmark in the list takes a while (I have to scan through the list and find the one I want). As far as images go, I currently have about 70 directories with images (65 subdirectories for my digital camera, and some miscellaneous ones). The camera ones have 100-200 each (in a lot of cases I have two copies of each image, one the JPEG file extracted from the raw image and another one converted using my hacked-up dcraw), and a couple of the others have 1000 each. Navigating through all of this is a real pain; the ones I'm most interested in I simply memorize. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ 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 Mon, 20 Jun 2005, Robert L Krawitz wrote: Adding a simple file (text) entry box with tab completion (and a preference to turn on autocompletion) would, IMHO, solve virtually all of the problems. Or just make the current system work better. In my installation you can type in a filename, one just need to add tab-completion to it and make it support full paths. For example, I want to just be able to type /tmp and press enter and then the dialog changes to that dir. I can't do that today. As I said, I don't know what happend in later versions of gtk then what is in FC3, it might already be improved (you can always hope :-). The ctrl-L popup has lots of problems; not only is it not apparent how to get to it (there's nothing that points at ctrl-L), but it's very clumsy to use (you have to type ctrl-L, type in the filename -- while having to deal with its quirks -- and then click OK twice). No one say that the CTRL-L is any good. It's just a workaround for those of us that are used to tab completion, until we have something better. I hope it can work as explained above in the future. and find the one I want). As far as images go, I currently have about 70 directories with images (65 subdirectories for my digital camera, and some miscellaneous ones). Maybe you need one bookmark to the parent and not 65 bookmarks to all subdirectories, Navigating through all of this is a real pain; the ones I'm most interested in I simply memorize. Right, and I make bookmarks of the places I use the most. Anyway, what I said was just that going back to the old dialog removes the bookmark feature that I use a lot. So no matter if you use the new or old dialog one of us will be unhappy. Not that going back seems to be an option, but if it was I would be against it. -- /Dennis ___ 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 6/20/05, Dennis Bjorklund [EMAIL PROTECTED] wrote: On Mon, 20 Jun 2005, Robert L Krawitz wrote: Adding a simple file (text) entry box with tab completion (and a preference to turn on autocompletion) would, IMHO, solve virtually all of the problems. Or just make the current system work better. In my installation you can type in a filename, one just need to add tab-completion to it and make it support full paths. For example, I want to just be able to type /tmp and press enter and then the dialog changes to that dir. I can't do that today. As I said, I don't know what happend in later versions of gtk then what is in FC3, it might already be improved (you can always hope :-). Yes, this works fine the the current gtk2, although with drop-down completion rather than tab completion. John ___ 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
Date: Mon, 20 Jun 2005 13:59:44 +0200 (CEST) From: Dennis Bjorklund [EMAIL PROTECTED] The ctrl-L popup has lots of problems; not only is it not apparent how to get to it (there's nothing that points at ctrl-L), but it's very clumsy to use (you have to type ctrl-L, type in the filename -- while having to deal with its quirks -- and then click OK twice). No one say that the CTRL-L is any good. It's just a workaround for those of us that are used to tab completion, until we have something better. I hope it can work as explained above in the future. Unless they've changed it further, you still don't have the text entry box visible. and find the one I want). As far as images go, I currently have about 70 directories with images (65 subdirectories for my digital camera, and some miscellaneous ones). Maybe you need one bookmark to the parent and not 65 bookmarks to all subdirectories, I don't really need bookmarks at all for this. I simply want to type /images/dcim/138canon/crw_3888.jpg (to identify a particularly interesting photo of a sunset in Bermuda, for example) without the dialog trying to helpfully (and slowly) autocomplete through all of that mess and without having to open a second, modal dialog (I thought that modal dialogs are supposed to be really bad juju?). Actually, the more common issue I deal with as Gutenprint lead developer is that I print an image named colors4.tif to a file (usually I name it /tmp/b.prn). I then run a command named unprint to generate a .pnm file from the output: unprint /tmp/b.prn /tmp/b.pnm following which I want to inspect that file (to see the effect that changes I've made to the Gutenprint source have made certain changes to the output, without having to waste a lot of ink and paper). The problem here is that colors4.tif lives in /images, so if I open a file from that context, I'm in /images whereas I really want to open a file in /tmp (as you can guess, a file named /tmp/b.pnm can be opened very quickly with 11 keystrokes if the dialog doesn't get in my way). A variation I might do is to look at just one color plane. While working on the Epson Stylus Photo R800 with its red and blue inks, for example, I might want to see the effect that changes in this code have on the red ink generation: unprint -m 100 /tmp/b.prn /tmp/b100.pnm or even for f in 1 2 4 8 100 200 ; do unprint -m $f /tmp/b.prn /tmp/b$f.pnm to get individual PNM's of each color plane separately (needless to say, I don't retype that command each time; I use ctrl-p in bash for that purpose). Since /tmp is usually full of all kinds of garbage, scrolling around in there in the new dialog isn't much fun. I sometimes use Cinepaint (taking the hit in extra memory consumption from having both the GIMP and Cinepaint running at the same time) to view these files just because the GTK2 dialog is so unwieldly for my purpose. Again: adding a simple text entry box for the filename, with tab completion but not autocompletion, would entirely solve my problem here! Navigating through all of this is a real pain; the ones I'm most interested in I simply memorize. Right, and I make bookmarks of the places I use the most. Anyway, what I said was just that going back to the old dialog removes the bookmark feature that I use a lot. So no matter if you use the new or old dialog one of us will be unhappy. Not that going back seems to be an option, but if it was I would be against it. I have no problem with bookmarks, but I just don't think they're a panacea. The reason I mentioned bookmarks is that the various bug reports, mailing list discussions, etc. seem to promote bookmarks heavily. For my purpose (at least with the GIMP) they're not useful. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ 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 Mon, 20 Jun 2005, Robert L Krawitz wrote: Again: adding a simple text entry box for the filename, with tab completion but not autocompletion, would entirely solve my problem here! And I would be happy if you could enter these things in the entry box that pop up when you just start to type. Maybe one should do some hacking and simply make some LD_PRELOAD hack that replaces the dialog in gtk with almost the same one but with an entry box added. Not very pretty but it could help some people.. Maybe a project for someone to play with during some lonely weekend. -- /Dennis ___ 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 Mon, Jun 20, 2005 at 11:14:03AM +0200, Dennis Bjorklund [EMAIL PROTECTED] wrote: One thing is that people, and _many_ people, just want their location entry back, for lots of reasons: discoverability, pastability and so on. But for some reason this simply does not happen. Do you want this only in gimp or in all programs that use the gtk+ widgets and dialogs? My understanding is that the dialog (mostly) resides in gtk+, and yes, I would want this functionality everywhere. I think the gtk dialog can be made better and should be improved for all applications, not just gimp. Agree. * In fedora 3 I can type in a filename and it selects that file in the file tree view and it just works. It does not work with full paths so I At leats in gtk+-2.6 (probably earlier, too), you can start typing the path and a location window will pop up. For absolute paths, start with /. never do this). If one fixes so one can type in any path directly, and not just filenames in the current selected dir, then the Ctrl-L is not needed anymore. That should be done in gtk+-2.6 already. * The file tree view does not always have input focus when the dialog is opened. So sometimes when I type in a filename the focus is in the bookmark part of the dialog and it matches a bookmark instead. I guess if the focus is that inconsistent you should check wether it's still behaving that way in gtk+-2.6 and report it as a bug if it is. I've not filed any bugs for the above and I don't know if maybe this have already been improved in later versions of gtk+ then what's in FC3. It's simply not a big enough problem for me that I've done that but I still would want these things to be improved. Well, eventually newer versins will arrive at your desktop. If you report it by then that should be fine. The more annoying a problem is the earlier it will be reported (and, unfortunately more often). The battle for you to fight is with gtk2 and not with gimp. If gimp started to use another dialog then what other gtk2 programs did, then people would start a fight about that. I'm not trying to battle with either the gimp or gtk+. I am trying to battle the continuous attitude of neglecting that there are problems for some users. My understanding here is that the new file dialog has nice features that improve it for many users. I am willing to pay the price of having a less optimal interface in favour of supporting most (hopefully) other users. The reasoning is that I often have a different workflow than the majority so what's good for me is not necessarily good for others. One could change behaviou base don some preferences, but that would priarily be my job to code. As long as I don't code it as I want it, I cannot complain that others don't do it for me. I think I can complain, however, whe other people claim that problems don't exist. For you reverting to the old dialog is a solution, If I think about it, yes, that would be by far the best solution for me. for me that would make the dialog a lot worse. I am fully aware of some features beign useful to others. That's why I always and clearly wrote me when refering to the usefulness of any such features. be improved so most of us are happy in the future. If not, then what do you suggest? Either way you choose someone will be unhappy. No, you can still go the preferences way and support both (or more) UI interactions. I am not complaining about missing code, I am merely complaining about neglecting that problems exist repeatedly, which unncessarily drives people mad. The most negative side effect of such comments is that you get endless threads on the issue: every comment of the style it works will provoke reactions like no, it doesn't. -- 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
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: 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 other GIMP developers have spent a lot of our free time discussing 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. 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. You also said file dialogs should go away (in some distant future) and people should use dragdrop. You misunderstood me. 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). Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [gwidion@mpc.com.br: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: to be the case with the early implementations but certainly not with the latest GTK+ 2.6 releases. The file dialog is getting better and better with each release. You keep repeating this as if it were some kind of religion - why do you ignore the people who simply disagree? Of course the new dialogs have many more features, but they are _much_ less usable for _some_ people. This is a simple fact. You should really accept that, even if it works for you, and even if you cannot understand it. I do accept that but I would like people to point out exactly what problems they have instead of just saying that they dislike the new dialogs. Without detailed complaints we can't do anything to improve the situation. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
Sven Neumann ([EMAIL PROTECTED]) wrote: [Fileselector] I do accept that but I would like people to point out exactly what problems they have instead of just saying that they dislike the new dialogs. Without detailed complaints we can't do anything to improve the situation. What occurred to me recently: The absence of a discoverable filename entry makes it quite hard to paste a filename into the fileselector. (plus the extra popping up window is quite annoying) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [gwidion@mpc.com.br: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
Hi, Marc Lehmann [EMAIL PROTECTED] writes: For some reaosn I cna hardly believe that after reading your original posting. You simply show no sign of understanding for the preferences other people have, as if one-size-fits-all would be the perfect solution. Huh? I've been collecting the wishes and problems regarding the file selector, making sure that the GTK+ developers are aware of the problem and even patching the file selector myself. We have also done quite some changes to the gimp file dialogs since the switch to the new GtkFileChooser widget. If you want to suggest that I would be ignoring the complaints, I really don't know what you've been smoking. If you want details then exactly as in gtk+-1.0 should suffice, because that dialog simply worked. No extra window, no slow extra popups that you have to wait for, no fancy and distracting _hiliting_, no stealing of the current selection etc. etc. Basically I want to be able to blindly enter paths as I could with gimp-1.0, press enter and presto - saved or loaded, with no other die effects. Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well. What I simply find annoying is this there is no problem attitude. I would find a there are problems, but we will not go back to that for the very few users who liked it attitude much much better. There's no such atttitude. The new file chooser has bugs and they need to be fixed. Asking us to revert to the old widget is however not an option. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
From: Sven Neumann [EMAIL PROTECTED] Date: Mon, 20 Jun 2005 00:40:37 +0200 If you want details then exactly as in gtk+-1.0 should suffice, because that dialog simply worked. No extra window, no slow extra popups that you have to wait for, no fancy and distracting _hiliting_, no stealing of the current selection etc. etc. Basically I want to be able to blindly enter paths as I could with gimp-1.0, press enter and presto - saved or loaded, with no other die effects. Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well. Did this change in GTK 2.6? In GTK 2.4, I tried doing precisely that. I typed ctrl-O while in an image named colors4.tif; I tried to type skier.tifenter and got another copy of colors4.tif. I don't much mind blindly entering paths, as long as I can see what I'm typing in case I make a mistake. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [gwidion@mpc.com.br: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
Hi, Bill Kendrick [EMAIL PROTECTED] writes: I'd love it if Gimp used KDE's file dialogs. The new Gimp one is quite annoying, compared to both the older Gimp file dialogs and the latest KDE ones. Asking the GIMP developers to implement native file selection dialogs is just silly. The new GTK+ file-chooser was designed in a way that allows for platform-specific implementations. If you really think that the file-chooser needs to be integrated better with KDE, then you can write a KDE-specific GtkFileChooser implementation. There is nothing that would have to be changed in GIMP. And, you aren't seriously trying to argue that the new GtkFileChooser would be worse than the old file selection widget, are you? That used to be the case with the early implementations but certainly not with the latest GTK+ 2.6 releases. The file dialog is getting better and better with each release. 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
On Fri, 17 Jun 2005, Leon Brooks wrote: Date: Fri, 17 Jun 2005 09:05:30 +0800 From: Leon Brooks [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP This may seem like an oxymoron, given GIMP's heavy defacto relationship with GNOME-flavoured GTK, but is there any GIMP equivalent to OpenOffice's KDE integration (http://kde.openoffice.org/)? The closest I could find was a vague reference to a pre-2.0 KDEified version of The GIMP, apparently called KIMP... http://dot.kde.org/1096230607/1096270511/ ...and this discussion, which is obviously approaching the issue from the KDE end and not the GIMP end of things (IMESHO, starting from the wrong end): http://lists.kde.org/?l=kde-develm=92756018422117w=2 I am guessing that a zero overhead (at least for GTK, I'd envision this as a 1:1 mapping using #defines) toolkit mapping layer at the source-code level would make ports for Qt/KDE, Carbon, wxWidgets or whatever considerably easier. Then there'd be only alternative shims to maintain, not a whole raft of debris integrated with The GIMP proper, and toolkit bugs would all be located in very few files. I am optimistic project like metatheme will help improve consistency between Gtk and KDE applications and help leave the choice of toolkits to the developers. If you are interested in looking into it futher here is their website: http://metatheme.advel.cz/ Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ 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 Friday 17 June 2005 22:25, Carol Spears wrote: On Fri, Jun 17, 2005 at 09:05:30AM +0800, Leon Brooks wrote: This may seem like an oxymoron, given GIMP's heavy defacto relationship with GNOME-flavoured GTK, but is there any GIMP equivalent to OpenOffice's KDE integration (http://kde.openoffice.org/)? do you know what GTK stands for? Yes. Hopefully one day GEGL will also be useful enough used by lots of GNOME apps as if it were a part of GNOME. I regularly use GTK apps (yes, including The GIMP) on MS-Windows. 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 Saturday 18 June 2005 09:08, Sven Neumann wrote: What aboout DND, the clipboard? Reporting on GIMP 2.2.7 under KDE 3.4.1. DND from GIMP does not work. The cursor changes but nothing happens if I drop onto (e.g.) KMail. Konqueror asks for a name, then turns a layer into a 2-byte file (0x0034, for the curious). DND to GIMP works, the result is a new image. Copy and Paste works both ways, at least for a whole image. Haven't tried things like masks or layers. Do images opened in GIMP show up in the KDE recent documents list? No. Does Konqueror show the thumbnails we created? No. Can I drag a layer out of the development version of GIMP and drop it into KOffice? Don't know about a development version, but not with this one. Does Klipper support the Clipboard Management Specification? Klipper can crash The GIMP, but doesn't seem to be able to meaningfully interact with it otherwise. 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 Sat, Jun 18, 2005 at 10:13:26PM +0800, Leon Brooks wrote: On Friday 17 June 2005 22:25, Carol Spears wrote: On Fri, Jun 17, 2005 at 09:05:30AM +0800, Leon Brooks wrote: This may seem like an oxymoron, given GIMP's heavy defacto relationship with GNOME-flavoured GTK, but is there any GIMP equivalent to OpenOffice's KDE integration (http://kde.openoffice.org/)? do you know what GTK stands for? Yes. Hopefully one day GEGL will also be useful enough used by lots of GNOME apps as if it were a part of GNOME. I regularly use GTK apps (yes, including The GIMP) on MS-Windows. the point is, GNOME is GIMP-flavored. thanks, carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
[This is a re-sent because my reent mails had been sent for moderation ut never appeared on-list: is the list still moderated?] On Sat, Jun 18, 2005 at 03:23:02PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: And, you aren't seriously trying to argue that the new GtkFileChooser would be worse than the old file selection widget, are you? That used Lots of people have expressed that the new filechooser feels worse for them. I, for example, as a heavy unix shell user (probably a totally unimportant part of the gimp user community as I am no graphics artist), still find the old (gtk+-1) file dialogs much easier and more intuitive to use, with less clutter. The best file dialogs ever, because they never got in my way. The new (gtk+-2.6) dialogs _do_ come in my way. They work like ms windows, they feel like ms windows, and they feel clumsy, in the parts that I use: entering filenames. (Despite still blocking for ages due to excessive stat() ing for remote filesystems not in the directory I started them, and many more minor annoyances that certainly _will_ be fixed, or at least be improved, but still make it slow business with gtk+-2.6.4). Other things (workflow) will not get fixed because the target (me!) is not the majority, and not important either. But that doesn't magically make the dialogs useful for me and claiming so again and again makes that more and more grotesque. to be the case with the early implementations but certainly not with the latest GTK+ 2.6 releases. The file dialog is getting better and better with each release. You keep repeating this as if it were some kind of religion - why do you ignore the people who simply disagree? Of course the new dialogs have many more features, but they are _much_ less usable for _some_ people. This is a simple fact. You should really accept that, even if it works for you, and even if you cannot understand it. -- 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
Von: Leon Brooks [EMAIL PROTECTED] This may seem like an oxymoron, given GIMP's heavy defacto relationship with GNOME-flavoured GTK, but is there any GIMP equivalent to OpenOffice's KDE integration (http://kde.openoffice.org/)? If KDE/Qt and GNOME/GTK+ both adhere to the freedesktop.org standards, you won't have to change anything to achieve integration. Michael -- Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden testen ++ http://www.gmx.net/de/go/promail ++ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: I actually run the GIMP on KDE, and it works just fine. Minor bug related to KDE integration are reported form time to time to bugzilla, and that is all there is that doesn't work. I'd love it if Gimp used KDE's file dialogs. The new Gimp one is quite annoying, compared to both the older Gimp file dialogs and the latest KDE ones. -bill! ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
