Hi,

Bill Kendrick 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

On Saturday, June 18, 2005, 15:23:02, Sven Neumann wrote:

The file dialog is getting better and better with each release.

It's usability will remain severely limited until you need to press Ctrl+L to actually be able to type-in a relative path (or any path on Windows). There also must be a reason why Windows ports of some GTK+ programs offer the native file open dialog box even though it means more code.

jernej@ena.si wrote:

On Saturday, June 18, 2005, 15:23:02, Sven Neumann wrote:

The file dialog is getting better and better with each release.

It's usability will remain severely limited until you need to press Ctrl+L to actually be able to type-in a relative path (or any path on Windows).

Oh, come on. You can just start to type the directory - relative or absolute, no difference...

There also must be a reason why Windows ports of some GTK+ programs offer the native file open dialog box even though it means more code.

s/the native/a native/

The win32 dialog sucks - there is no easy way to create bookmarks, for example, and there are multiple ones. If there was one which is up to par with the GTK+ one, it might be worthwile to consider integration, but at the present state, Microsoft and Windows application developers have a long way to go.

Just my 2 cent, Michael

On Saturday, June 18, 2005, 18:42:17, Michael Schumacher wrote:

The file dialog is getting better and better with each release.

It's usability will remain severely limited until you need to press Ctrl+L to actually be able to type-in a relative path (or any path on Windows).

Oh, come on. You can just start to type the directory - relative or absolute, no difference...

Relative path/filename work so-so (you have to type first few letters, then either wait and press Enter or press Enter twice to make the selection, and you can't dive more than 1 directory deep at once). Absolute paths on Windows don't work at all if you don't press Ctrl+L manually. (There are also other things that bother me about Ctrl+L dialog, namely the implementation of autocompletion and the fact that if you type the full path to a file, you still have to confirm the selection in the open dialog itself).

There also must be a reason why Windows ports of some GTK+ programs offer the native file open dialog box even though it means more code.

s/the native/a native/
The win32 dialog sucks - there is no easy way to create bookmarks, for example, and there are multiple ones. If there was one which is up to par with the GTK+ one, it might be worthwile to consider integration, but at the present state, Microsoft and Windows application developers have a long way to go.

I don't care about bookmarks that much (besides, they don't work at all in GTK+ file opener, at least as of 2.6.7), the inability to call up the open dialog and just start typing the path to file makes it much less useful. Bookmarks would be only useful to me in Gimp, where I use mouse all the time, otherwise I mainly use the keyboard, so the absence of File Name entry box is a real letdown for me. I need to compile the list of things that bother me about the GTK+ file chooser and submit it to bugzilla someday. I know I'm not the only one being bothered with it's design.

On Sunday 19 June 2005 01:46, jernej@ena.si wrote:

There are also other things that bother me about Ctrl+L dialog, namely the implementation of autocompletion and the fact that if you type the full path to a file, you still have to confirm the selection in the open dialog itself.

Before I respond to this, I want to make it plain that I don't consider the Qt/KDE dialogs especially "holy" in any sense.

If you use GIMP on KDE (as I do), it's almost painfully obvious why people refer to it as a GNOME application: it *looks* like one. Yes, it is only the GTK libraries, really, but components like the file-open dialog look quite alien when compared with practically everything else.

This by itself is not a real problem, although undesirable.

The issue for most people, I'm guessing, will be that the whole flow of the dialog is alien to everything else around it as well. It has the whole "dumbed down but if you click on Advanced enough times you might get somewhere" feeling, compared to the relatively cluttered and intimidating (but also efficient) KDE dialogs.

This is something which (as a techie) I don't find too disturbing, but which drives my wife completely twittery. She is an artist and a musician, not a techie (which is one reason I'm interested in doing artistic brushes for GIMP). I've "tricked" her into using GIMP for cropping and scaling images for EBay, but the alien appearance of the file-open dialog gets it categorised in her artistic little brain as being completely different to a KDE dialog aimed at exactly the same set of files.

I need to compile the list of things that bother me about the GTK+ file chooser and submit it to bugzilla someday. I know I'm not the only one being bothered with it's design.

Agree. But I'm not sure that changing the existing GTK dialog as such would be as useful as offering user-configurable alternatives, which is why I spoke of a "zero overhead" shim.

Using such and compiling GIMP would by default result in binaries identical to the current ones, but you could use it to (at compile time) invoke alternatives in some places, one of which could concievably be a (no longer quite zero overhead, you'd have to at least bounce each call through a table) run-time choice of default GTK, alternate GTK or Qt-through-wrapper.

By default, GIMP remains unchanged, but for those annoyed or panicked by differences, the option to erase the most disturbing differences would be available.

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

[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 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.

On Sun, Jun 19, 2005 at 08:48:33AM +0800, Leon Brooks wrote:

On Sunday 19 June 2005 01:46, jernej@ena.si wrote:

I need to compile the list of things that bother me about the GTK+ file chooser and submit it to bugzilla someday. I know I'm not the only one being bothered with it's design.

Agree. But I'm not sure that changing the existing GTK dialog as such would be as useful as offering user-configurable alternatives, which is why I spoke of a "zero overhead" shim.

Using such and compiling GIMP would by default result in binaries identical to the current ones, but you could use it to (at compile time) invoke alternatives in some places, one of which could concievably be a (no longer quite zero overhead, you'd have to at least bounce each call through a table) run-time choice of default GTK, alternate GTK or Qt-through-wrapper.

You're basing your idea on an assumption that is wrong. GIMP doesn't simply call a set of functions to display open and save dialogs. It derives a new object type from GtkFileChooseDialog and implements extended functionality that way.

So a wrapper for the Qt dialog would have to implement a full GObject type, and wrap most of GtkWidget's functionality, which is not a small task. It's certainly possible, but it'd be a maintainence nightmare.

-Yosh

Hi,

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

Hi,

Leon Brooks writes:

The issue for most people, I'm guessing, will be that the whole flow of the dialog is alien to everything else around it as well. It has the whole "dumbed down but if you click on Advanced enough times you might get somewhere" feeling, compared to the relatively cluttered and intimidating (but also efficient) KDE dialogs.

So the main complaint is that the dialog (which one?) shows up with the expanders collapsed? That is something that could be taken care of even though I am not convinced that it would be a change to the better.

This is something which (as a techie) I don't find too disturbing, but which drives my wife completely twittery. She is an artist and a musician, not a techie (which is one reason I'm interested in doing artistic brushes for GIMP). I've "tricked" her into using GIMP for cropping and scaling images for EBay, but the alien appearance of the file-open dialog gets it categorised in her artistic little brain as being completely different to a KDE dialog aimed at exactly the same set of files.

Why is she using the file open dialog at all? She could as well use the file manager and drag the files into GIMP. The file open dialog should really only be used if the file isn't readily selected elsewhere which should be rather unlikely if you are working in a document oriented way.

Also, you might want to explain bookmarks to your wife. She might find the dialog a lot more usable then.

What I am missing is support for XDS in the common desktops so that one would have to use the file save dialog less.

Sven

Hi Sven,

Sven Neumann wrote:

Why is she using the file open dialog at all? She could as well use the file manager and drag the files into GIMP. The file open dialog should really only be used if the file isn't readily selected elsewhere which should be rather unlikely if you are working in a document oriented way.

True enough - drag'n'drop and gimp-remote are very useful here. Personally I tend to drag'n'drop from GQView into The GIMP - but the usefulness of DnD is hampered in stock Gnome by the impossibility of turning off click-to-front. (I'm technically minded and motivated enough to apply a patch, but end users aren't).

DnD can also be a problem between multiple desktops.

Also, you might want to explain bookmarks to your wife. She might find the dialog a lot more usable then.

Bookmarks are indeed great.

What I am missing is support for XDS in the common desktops so that one would have to use the file save dialog less.

Yes, for me the Save dialog is an annoyance. I very rarely want to save directly into the default directory, and changing directories takes too much mousework, and is clumsy with the keyboard (tabbing to get the focus in the right place, then Ctrl-L, then enter path...) Is there any reason why the save dialog's filename entry box can't support paths directly?

Could the expanded/collapsed status of the directory selector be made persistent across sessions?

All the best, --
Alastair M. Robinson

Hi,

"Alastair M. Robinson" writes:

Why is she using the file open dialog at all? She could as well use the file manager and drag the files into GIMP. The file open dialog should really only be used if the file isn't readily selected elsewhere which should be rather unlikely if you are working in a document oriented way.

True enough - drag'n'drop and gimp-remote are very useful here. Personally I tend to drag'n'drop from GQView into The GIMP - but the usefulness of DnD is hampered in stock Gnome by the impossibility of turning off click-to-front.

Right-click any image in gwview and choose Edit->in The GIMP (or Ctrl-1).

Yes, for me the Save dialog is an annoyance. I very rarely want to save directly into the default directory, and changing directories takes too much mousework, and is clumsy with the keyboard (tabbing to get the focus in the right place, then Ctrl-L, then enter path...) Is there any reason why the save dialog's filename entry box can't support paths directly?

But the entry does support entering absolute paths directly.

Could the expanded/collapsed status of the directory selector be made persistent across sessions?

I already said that it could be done but that I am not convinced that it is a change to the better.

Sven

Hi,

Sven Neumann writes:

But the entry does support entering absolute paths directly.

and of course also relative paths

Sven

On Sunday 19 June 2005 18:02, Sven Neumann wrote:

the alien appearance of the file-open dialog gets it categorised in her artistic little brain as being completely different to a KDE dialog aimed at exactly the same set of files.

Why is she using the file open dialog at all? She could as well use the file manager and drag the files into GIMP.

Now that I know it works, she's dragging a link from Konqueror and dropping it on GIMP to open files.

GNOME weirded her out completely; KDE was different enough to disturb her.

Cheers; Leon

Hi Sven,

Sven Neumann wrote:

True enough - drag'n'drop and gimp-remote are very useful here. Personally I tend to drag'n'drop from GQView into The GIMP - but the usefulness of DnD is hampered in stock Gnome by the impossibility of turning off click-to-front.

Right-click any image in gwview and choose Edit->in The GIMP (or Ctrl-1).

Yep, I do that too. But surely we should be trying to maximise the usability of the dialogs rather than merely suggesting that people don't use them?

(Not that I'm complaining about the Open dialog :) )

But the entry does support entering absolute paths directly.

Oh good. I'm a few versions behind on my Linux machine because I don't currently have time to update GTK, FreeType and everything else :)

I already said that it could be done but that I am not convinced that it is a change to the better.

I'm not suggesting that it should always be open - just that it should remember its last status.

I would personally find that a huge improvement; somehow not being able to see "where" in the filesystem you are is a bit disorienting.

All the best, --
Alastair M. Robinson

On Sunday 19 June 2005 19:38, Leon Brooks wrote:

Now that I know it works, she's dragging a link from Konqueror and dropping it on GIMP to open files.

Should add, right-click => open-with => The GIMP was bearable for her, but she really feels at home with "drag this picture onto this program to work with it".

Cheers; Leon

On Sunday 19 June 2005 19:48, Alastair M. Robinson wrote:

I'm a few versions behind on my Linux machine because I don't currently have time to update GTK, FreeType and everything else

Live dangerously, point your package manager at Debian Testing or Mandrake Cooker and update overnight every night. (-:

Cheers; Leon

Hi,

"Alastair M. Robinson" writes:

Yep, I do that too. But surely we should be trying to maximise the usability of the dialogs rather than merely suggesting that people don't use them?

In the long run, file dialogs and file locations in general should become something that the normal user would never have to use.

I already said that it could be done but that I am not convinced that it is a change to the better.

I'm not suggesting that it should always be open - just that it should remember its last status.

The point of the expander is to hide the UI elements that you are unlikely going to use. Now if the dialog would remember this state and since I don't expect users to ever collapse the expander again, that would basically make the expander be open all the time, thus rendering it pointless.

Sven

On Sunday 19 June 2005 20:17, Sven Neumann wrote:

The point of the expander is to hide the UI elements that you are unlikely going to use. Now if the dialog would remember this state and since I don't expect users to ever collapse the expander again, that would basically make the expander be open all the time, thus rendering it pointless.

The obvious solution is to add a small "sticky" pin which one can click to nail the thing open (or closed, if the app starts it open) when it gets irritating.

But then, IIRC, this goes against a GNOME policy of having all such things in a config program somewhere.

Cheers; Leon

Hi Sven,

Sven Neumann wrote:

In the long run, file dialogs and file locations in general should become something that the normal user would never have to use.

Realistically, that's a good few months / years away. In the meantime, we're pretty much stuck with using the Save dialog in one form or another.

The point of the expander is to hide the UI elements that you are unlikely going to use. Now if the dialog would remember this state and since I don't expect users to ever collapse the expander again, that would basically make the expander be open all the time, thus rendering it pointless.

Yes, I see your point.

I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format.

Anyway, just my two-penneth :)

All the best, --
Alastair M. Robinson

"Alastair M. Robinson" wrote:

I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format.

I have the opposite experience : I tend to group images of a drawing session / photo manipulations session in one directory, so when I save my first image I unfold the directory view to pick a bookmark and create a subdirectory in it, but from then every new save will only need the folded dialog, which is small and uncluttered, to my liking.

On Sun, Jun 19, 2005 at 05:11:08PM +0200, Karine Delvare wrote:

"Alastair M. Robinson" wrote:

I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format.

I have the opposite experience : I tend to group images of a drawing session / photo manipulations session in one directory, so when I save my first image I unfold the directory view to pick a bookmark and create a subdirectory in it, but from then every new save will only need the folded dialog, which is small and uncluttered, to my liking.

is it within your ability to understand that there are still several people who have been using gimp since the 1.0 development era and expect configurability?

perhaps even deserve it?

carol

Sven Neumann (sven@gimp.org) 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

On Sun, Jun 19, 2005 at 11:53:32AM +0200, Sven Neumann wrote:

You should really accept that, even if it works for you, and even if you cannot understand it.

I do accept that

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.

but I would like people to point out exactly what problems they have instead of just saying that they dislike the new dialogs.

... but people do that. And you tell them this is the gimp and not the right place to do that. This is contradictory.

Without detailed complaints we can't do anything to improve the situation.

Well, let's make an example (this has been said before):

"I would like to have the file open and save dialogs work the same as the ones in gtk+-1.0, with typing paths into the dialog and tab completion".

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.

Now, lots of people want other things, for example bookmarks etc. I don't, and some others don't either. There is great diversity. I am not even able to find out wether the file dialog I would like to have is even remotely compatible with the file dialogs other people want to have. I can only say that nice features I found both cool and supportive have been removed, and not been put back in, with the new file dialogs.

I am not telling you to go and "fix" it (it ain't even broken!). Other features have been removed or made more difficult or different to use as well and it seems the majority of users found this an improvement. I can live with that.

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.

Hi,

Bill Kendrick writes:

Also, you might want to explain bookmarks to your wife. She might find the dialog a lot more usable then.

The bookmarks are okay, until you end up having 5 different folders called "bitmaps", and it's impossible to tell which project folder it's from. (I use fairly standardized folder heirarchies and makefiles at work, so every game has a "bitmaps" folder.)

Bookmarking more than one folder with a particular name causes confusion, since you can't tell which is which. Perhaps I should post a wishlist item to Gimp's bug tracker. :^) When there are multiple bookmarks pointing to folders with the same name, show more context. e.g.:

There's already a bug-report on that in the GTK+ bug-tracker.

Sven

Hi,

Marc Lehmann 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

From: Sven Neumann
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.tif" 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.

On Sunday, June 19, 2005, 21:17:14, Bill Kendrick wrote:

[*] I've tried the Microsoft "PowerToy" for virtual desktops. It's utterly useless. Doubly-so since it (1) rearranges the window listing in the taskbar, and (2) Visual Studio is a piece of crap, and does stuff like unminimize when you switch between virtual desktops.

Try VirtuaWin from . Not sure how it works with Visual Studio, but I like it much more than MS's virtual desktop tool.

On Monday 20 June 2005 07:02, Robert L Krawitz wrote:

I don't much mind blindly entering paths, as long as I can see what I'm typing in case I make a mistake.

Um.

English sucks. My brain twitched a fair bit trying to parse that, so I'm going to re-word it as:

I don't mind typing when there is no indication of any place to type, but as soon as I start typing I would like some feedback in case I make a mistake.

Correct me if I'm wrong.

Cheers; Leon

On Monday 20 June 2005 02:04, Carol Spears wrote:

On Sun, Jun 19, 2005 at 05:11:08PM +0200, Karine Delvare wrote:

"Alastair M. Robinson" wrote:

I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format.

I have the opposite experience : I tend to group images of a drawing session / photo manipulations session in one directory, so when I save my first image I unfold the directory view to pick a bookmark and create a subdirectory in it, but from then every new save will only need the folded dialog, which is small and uncluttered, to my liking.

is it within your ability to understand that there are still several people who have been using gimp since the 1.0 development era and expect configurability?

I don't think Karine was speaking against configurability as such, just in favour of the default.

Would a simple "push-pin" toggle control to optionally stick the default configuration one way or the other be difficult to implement?

Cheers; Leon

On Mon, Jun 20, 2005 at 08:56:07AM +0800, Leon Brooks wrote:

On Monday 20 June 2005 02:04, Carol Spears wrote:

On Sun, Jun 19, 2005 at 05:11:08PM +0200, Karine Delvare wrote:

"Alastair M. Robinson" wrote:

I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format.

I have the opposite experience : I tend to group images of a drawing session / photo manipulations session in one directory, so when I save my first image I unfold the directory view to pick a bookmark and create a subdirectory in it, but from then every new save will only need the folded dialog, which is small and uncluttered, to my liking.

is it within your ability to understand that there are still several people who have been using gimp since the 1.0 development era and expect configurability?

I don't think Karine was speaking against configurability as such, just in favour of the default.

Would a simple "push-pin" toggle control to optionally stick the default configuration one way or the other be difficult to implement?

that is the issue. a good thing for beginners has been foisted on everyone.

"just blindly type into the selector" is terrible advice for how to use something. especially software.

carol

On Sun, Jun 19, 2005 at 07:36:21PM -0700, Carol Spears wrote:

On Mon, Jun 20, 2005 at 08:56:07AM +0800, Leon Brooks wrote:

On Monday 20 June 2005 02:04, Carol Spears wrote:

On Sun, Jun 19, 2005 at 05:11:08PM +0200, Karine Delvare wrote:

"Alastair M. Robinson" wrote:

I can only speak for myself, of course, but personally, I end up unfolding the directory view perhaps 90-95% of the times I used the dialog. The only time I generally don't need to expand the directory view is if I'm just saving off an existing image in a different file format.

I have the opposite experience : I tend to group images of a drawing session / photo manipulations session in one directory, so when I save my first image I unfold the directory view to pick a bookmark and create a subdirectory in it, but from then every new save will only need the folded dialog, which is small and uncluttered, to my liking.

is it within your ability to understand that there are still several people who have been using gimp since the 1.0 development era and expect configurability?

I don't think Karine was speaking against configurability as such, just in favour of the default.

Would a simple "push-pin" toggle control to optionally stick the default configuration one way or the other be difficult to implement?

that is the issue. a good thing for beginners has been foisted on everyone.

"just blindly type into the selector" is terrible advice for how to use something. especially software.

i am replying to myself -- not a good situation.

i also realize that i am combining two different thoughts from this original thread and not combining it well.

karine is a new user and therefore likes the default. this is all fine and good, however, i still need to open that expander almost every single time i work and expected that the behavior of the expander be configurable long before now.

then you got the other thread running about the file selector. the fact that i confuse the two is probably related to the way the developers answer the complaints. the answers are rude, suspiciously lacking in logic and fall way below the expectations anyone would have if you have been following gimp development for more than the last three years.

my opinions do not matter, but "blindly type into it"???

carol

On Mon, Jun 20, 2005 at 12:40:37AM +0200, Sven Neumann 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 drag&drop. This is another very bad way to force unnatural (for some) workflow on people: for one thing, drag&drop doesn't work very wlel under X, for another thing it is quite difficult to actually "drag&drop" while prpessing your mouse button for some people. Even I who can easily do drga&drop 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.

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 :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.

On Monday, June 20, 2005, 0:40:37, Sven Neumann wrote:

Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well.

Not on Windows, and you still have to confirm your selection twice.

On Mon, Jun 20, 2005 at 11:14:03AM +0200, Dennis Bjorklund 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."

Date: Mon, 20 Jun 2005 11:14:03 +0200 (CEST) From: Dennis Bjorklund

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.

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.

On 6/20/05, Dennis Bjorklund 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

Date: Mon, 20 Jun 2005 13:59:44 +0200 (CEST) From: Dennis Bjorklund

> 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.

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.

Von: jernej@ena.si

On Monday, June 20, 2005, 0:40:37, Sven Neumann wrote:

Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well.

Not on Windows, and you still have to confirm your selection twice.

Maybe we can at least turn a part of this thread into something useful....

Jernej, I couldn't reproduce your problem with the bookmarks on windows - they work just fine for me. And your current description is a bit too vague, too - there might be problems and needed improvements, but it's impossible to determine what you're referring to.

We should probably take this to a GTK+ list, but first I'd like to figure out why the file chooser seems to work fine on my system and not on yours.

Michael

On Monday, June 20, 2005, 15:22:12, Michael Schumacher wrote:

Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well.

Not on Windows, and you still have to confirm your selection twice.

Jernej, I couldn't reproduce your problem with the bookmarks on windows - they work just fine for me. And your current description is a bit too vague, too - there might be problems and needed improvements, but it's impossible to determine what you're referring to.

My comment was about the absolute paths actually - on Linux, Ctrl+L dialog is triggered by the / key, too, but this (for obvious reasons) doesn't work on Windows.

jernej@ena.si writes:
> is triggered by the / key, too, but this (for obvious reasons) doesn't work > on Windows.

Actually, it does, at least for me, with GIMP 2.2 and GTK+ 2.6.8. Although if you need to enter a drive letter, after typing the slash, you have to backspace once to erase it, type the drive letter, colon, slash (or backslash), etc. Tab completion works, but you do have to press enter twice after arriving at the file you want. I could try to check if it would be easy to make a colon following a single letter bring up the path entry dialog.

--tml

On Monday, June 20, 2005, 18:42:56, Tor Lillqvist wrote:

is triggered by the / key, too, but this (for obvious reasons) doesn't work on Windows.

Actually, it does, at least for me, with GIMP 2.2 and GTK+ 2.6.8.

It doesn't for me - either it does nothing, or shows the textbox under a listbox if focus is there. (Gimp 2.2.7 and GTK+ 2.6.8)

On Mon, 20 Jun 2005 jernej@ena.si wrote:

My comment was about the absolute paths actually - on Linux, Ctrl+L dialog is triggered by the / key, too, but this (for obvious reasons) doesn't work on Windows.

Wouldn't it be nice if the same text entry widget used by the treeview when you type "abc" also be used if you type "/tmp". If it also could support tab completion then all is solved and we would not need the CTRL-L dialog.

In the end of course someone that want it bad enough have to sit down with the code.

Hi,

Leon Brooks writes:

Would a simple "push-pin" toggle control to optionally stick the default configuration one way or the other be difficult to implement?

I'd even say that it is impossible to implement.

Sven

Hi,

Leon Brooks writes:

English sucks. My brain twitched a fair bit trying to parse that, so I'm going to re-word it as:

I don't mind typing when there is no indication of any place to type, but as soon as I start typing I would like some feedback in case I make a mistake.

But you get feedback, pretty clear feedback even. What's your point?

Sven

Hi,

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 drag&drop.

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

On Tue, Jun 21, 2005 at 01:02:34AM +0200, Sven Neumann 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 drag&drop.

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!

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 Marc, Sven.

I don't know if there's a list protocol about this, or maybe it's well established that peacemakers like myself are pretty much bound to fail, but I thought I'd give it a shot ...

I've been on the internet for many years, and I've been insulted and flamed quite a number of times. The best way to keep the peace is to ignore the flames entirely and not reply at all. If you think you need to reply, reply to the cogent points of the post, not the insults. Something else I've found: ignoring the flames only makes the flamer look more foolish, so by doing so you keep the peace _and_ make your would-have-been opponent look worse.

I don't think the list can afford to lose the input of either one of you.

-------------------------------------------------------------- Giles giles@dreaming.org http://www.gilesorr.com/
--------------------------------------------------------------

On Tuesday 21 June 2005 19:55, Giles wrote:

I don't think the list can afford to lose the input of either one of you.

Agree. Please find a way to work together, or at least constructively ignore one another.

Cheers; Leon

On Tue, 2005-06-21 at 13:02 +0200, jernej@ena.si 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

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: (I only used Enter key
once, when I had the complete path to file entered and wanted to open the file).

On Tue, Jun 21, 2005 at 07:16:25PM +0200, jernej@ena.si 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: (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.

Hi,

Giles writes:

I don't think the list can afford to lose the input of either one of you.

Don't worry. We are just having some fun. At least I hope that Marc does. I am certainly enjoying it.

Sven

Hi,

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

On Tue, Jun 21, 2005 at 10:24:46PM +0200, Sven Neumann wrote:

Giles writes:

I don't think the list can afford to lose the input of either one of you.

Don't worry. We are just having some fun. At least I hope that Marc does. I am certainly enjoying it.

I am certainly not enjoying it; I don't see it as "having fun", either, and I must say you have weird ways of enjoying yourself.

I am trying to make you realize that ignoring problems does not make them go away. Sorry for being a pain in the ass...

On Tue, Jun 21, 2005 at 10:48:15PM +0200, Sven Neumann 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 something useful.

I do so all the time. For some reason, you keep ignoring all my efforts, with weirder and weirder arguments.

On Tue, Jun 21, 2005 at 10:48:15PM +0200, Sven Neumann wrote:

(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.

Sorry, I was completely wrong earlier. I just spent some more time with the 2.6.8 file dialog.

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).

So what you said above is wrong (in your langauge "is a blatant lie"). Why do you claim that if it isn't true?

What is the purpose behind your behaviour? Really, just claiming that problems aren't there doesn't make them go away.

Hi,

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

Hi,
sven@gimp.org (2005-06-22 at 0018.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

http://bugzilla.gnome.org/show_bug.cgi?id=136541#c53 does not keep the path always on, but it brings it back a bit, at least better for accessibility and discoverability. Make the field replace the list of buttons and be forced to start on via gtkrc or similar, and you got a solution for no clutter and people that want the input field without extra work.

GSR

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?

Hi,

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.

Sven

Hi,

writes:

I am trying to make you realize that ignoring problems does not make them go away. Sorry for being a pain in the ass...

Marc, if I wanted to ignore the problems, I would simply ignore you. Can you please stop using the ignore argument? This is silly. Not even explaining you how insulting this is, stops you from repeating this over and over again?

Sven

Hi,

jernej@ena.si 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

From: Sven Neumann
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 would even *think* of doing anything like this, that should say something about just how bad this really is.

On Wed, 22 Jun 2005, Sven Neumann wrote:

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...).

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.

For the popup entry box TAB doesn't need to work to jump to another widget since it's a popup. It's one level above the other widgets and a proper way to get out if it is to press escape.

I want to just be able to start with gimp and press these buttons

CTRL-O t really see that as a problem since the new behaviour is a proper superset of the current behaviour.

Hi,

Dennis Bjorklund 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

Here's what I do to achieve that: Ctrl-O, "/t", Enter

CTRL-O
/tmp/foo.png

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

Hi,

Robert L Krawitz 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

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.

Hi,

Dennis Bjorklund 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

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 :-)

On Wed, Jun 22, 2005 at 12:59:33AM +0200, Sven Neumann wrote:

Hi,

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).

On Wed, Jun 22, 2005 at 12:18:34AM +0200, Sven Neumann 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 does a better job because it works somewhat better even before you discover that it can be used without the mouse.

That could well be. Now the question is wether a text entry with tab completion would frustrate users. I don't think so, but if you think so, speak on.

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).

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.

Well, you said more than once that I am not taken to be seriously if I want tab completion, alway sin response to me saying that the old way of tab completion was wrong.

Claiming my interpretation is "nuts" is IMHO completely unfounded. Do you realize how insulting you are? No? Thoguth so...

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.

Why do you imply I haven't? Sorry, but that's rather close to ad-hominem again, by undermining my ability to judge.

Sorry, but I am well capable of installing gtk+-2.6.8 and trying it out, even if you try to imply otherwise.

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.

Well, people other than me said it doesn't, so your subjective judgement is far from general. I, too, think it does not at all work well, because I have to wait for visual (and usually slow) feedback when entering filenames. Believe it or not, this makes it very awkward to use tab completion, at leats for people who are accustomed to it and now their paths 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.

That is an interesting comment. So you think the ctrl-l feature shouldn't be there at all? I wouldn't call those people who asked for something like that as "trolls"...

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 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.

It doesn't matter wether the file dialogs work well for newbies if they don't work well for everyday users.

You *are* ignoring the ample evidence people posted here.

If you or someone else can come up with a detailed mockup of an alternative dialog

I don't understand what the problem is there. Just include a text entry *somewhere*. I'd guess somewhere at the bottom would be most useful, but it's not as if we were talking about very complicated widget here. Nothing else needs to be changed, so asking for a mockup is just making it unneccssarily difficult.

If there are questions on ui logic (that cannot be solved by using mockups), that should be discussed. The really annoying feature of the completion right now is the popup of the location entry and the (slow) popup of the completion entries. I am not sure wether a large delay would be good, or wether not displaying it at all would be better. Right now, it's simply too slow because it pops up and changes while you type.

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.

Much much more than I'd ever ask for.

From: Sven Neumann
Date: Wed, 22 Jun 2005 10:12:05 +0200

Robert L Krawitz 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).

On Tue, Jun 21, 2005 at 09:53:20PM -0400, Robert L Krawitz 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.

On Wed, Jun 22, 2005 at 10:12:05AM +0200, Sven Neumann 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.

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

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

On Wed, 22 Jun 2005, Robert L Krawitz wrote:

Date: Wed, 22 Jun 2005 07:32:11 -0400 From: Robert L Krawitz
To: sven@gimp.org
Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

From: Sven Neumann Date: Wed, 22 Jun 2005 10:12:05 +0200

Robert L Krawitz 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.

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

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).

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).

Hi,

Robert L Krawitz 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

Hi,

"Alastair M. Robinson" 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

Hi,

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

Hi,

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.

Given that there *are* proposals, [...] b) what would the possible problems be?

I did that, several times, in this thread and before.

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.

(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).

I don't understand what "talking down a problem" means. If someone raises a problem, there are two ways to deal with it. It can either be ignored or the one who complains can be asked to explain his concerns. He/she might even have to face other opinions and have to defend his/her view. That doesn't help to decide if the complaint is valid or not (simply because any complaint is valid) but it helps to find out how important it is, where the actual problem lies and if there are ideas to solve it. If we are talking about problems, that's a good thing and I am not going to let you stop me doing that. So please, let's stop discussing the discussion and get back to something useful like talking down your problems.

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.

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.

Sven

From: Sven Neumann
Date: Thu, 23 Jun 2005 00:09:06 +0200

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?

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.

Hi,

Robert L Krawitz 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

Von: Bill Kendrick

* 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

From: Sven Neumann
Date: Thu, 23 Jun 2005 10:35:51 +0200

Robert L Krawitz 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.

Date: Thu, 23 Jun 2005 07:43:07 -0400 From: Robert L Krawitz

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.

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.

Date: Thu, 23 Jun 2005 21:13:41 +0100 (BST) From: Alan Horkan

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.

Hi,

Robert L Krawitz 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

On Wed, Jun 22, 2005 at 11:53:18PM +0200, Sven Neumann 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"

Hi,

writes:

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.

"actively ignoring", haha. That's a nice one. You know, I have all the right to ignore these complaints since this list is definitely the wrong place to complain about the file chooser and I am not maintaining this code. But I have chosen not to ignore the complaints but to listen to them and to forward any complaints that I agree with to the appropriate people. I will of course not do that for complaints or proposals that I disagree with. It is up to you and anyone else to address the relevant people and to persuade them to do something about your problem or even to accept your patches that solve the problem.

Posting to gimp-developer about file chooser issues can only mean one thing. It means that you want to have your points discussed. And of course you will have to defend your view in such a discussion. If you don't want to do that, what's the point of bringing up the topic then?

Sven