In file dialogs, I removed the name of the file above the preview:
- it's a bit tautologic, as the file is already selected in the list anyway
- removing it frees a bit more space for the preview itself
- most importantly, long filenames stretch the preview and thus distort the dialog layout, and there's no way to ellipcize the filename label (at least yet, as of GTK 2.6)
I like this change, but I realize there may be different opinions, so comments are welcome.
On Mon, 20 Dec 2004, bulia byak wrote:
In file dialogs, I removed the name of the file above the preview:
it's a bit tautologic, as the file is already selected in the list anyway
removing it frees a bit more space for the preview itself
most importantly, long filenames stretch the preview and thus
distort the dialog layout, and there's no way to ellipcize the filename label (at least yet, as of GTK 2.6)
I like this change, but I realize there may be different opinions, so comments are welcome.
For this change I don't have an opinion, but have some broader opinions of the file dialogs:
The main problem is that I typically work with files in large, complex directory trees (e.g., openclipart, etc.) so often it is fastest for me to type the paths and filenames in, and then hit enter to load it. This does not work in inkscape (afaik), so I have to pick, scroll, pick, scroll, and eyeball for the file. I don't know if this is a GNOME thing or is something that can be overridden in Inkscape, but it is very annoying.
The save dialog is also strange because it is laid out differently than the file dialog. The name is at the top of the dialog instead of in the same place as the load dialog, for instance. That seems very different from how one would expect. Also, with the save dialog it seems redundant to have 'Save in folder' as well as a tree view; it's confusing.
Bryce
On Mon, 20 Dec 2004 17:43:17 -0800 (PST), Bryce Harrington > The main problem is that I typically work with files in large, complex
directory trees (e.g., openclipart, etc.) so often it is fastest for me to type the paths and filenames in, and then hit enter to load it. This does not work in inkscape (afaik),
Why, it does! Haven't you tried?
so I have to pick, scroll, pick, scroll, and eyeball for the file. I don't know if this is a GNOME thing or is something that can be overridden in Inkscape, but it is very annoying.
The only reason I agreed to the new file dialogs is that Ishmal restored the text input field that the Gnome folks removed in GTK 2.4. I agree that not having this field is an incredibly stupid limitation, but I don't understand why you blame Inkscape for it :) We are perhaps the only GTK 2.4+ app that does NOT suffer this problem.
And by the way in GTK 2.6 they added type-ahead find in the file list (I'm using it already). So now we have the best of both worlds: the regular filename field and the type-ahead find in the list.
The save dialog is also strange because it is laid out differently than the file dialog. The name is at the top of the dialog instead of in the same place as the load dialog, for instance. That seems very different from how one would expect. Also, with the save dialog it seems redundant to have 'Save in folder' as well as a tree view; it's confusing.
They are not redundant because enabling one disables the other, and vice versa. Normally the save dialog is folded up and does not have the full filedialog, which is when you use the "save in folder" drop-down. This and the position of the filename field might indeed be changed, but these are relatively minor issues, and I prefer to leave them to the GTK folks to fix in future versions. Changing the standard dialogs is only justified for really serious usability problems, such as the missing filename field.
On Mon, 20 Dec 2004, bulia byak wrote:
On Mon, 20 Dec 2004 17:43:17 -0800 (PST), Bryce Harrington > The main problem is that I typically work with files in large, complex
directory trees (e.g., openclipart, etc.) so often it is fastest for me to type the paths and filenames in, and then hit enter to load it. This does not work in inkscape (afaik),
Why, it does! Haven't you tried?
Yes, I did, on a build from last week. Are you indicating that this has already been fixed, or just that you cannot replicate it?
so I have to pick, scroll, pick, scroll, and eyeball for the file. I don't know if this is a GNOME thing or is something that can be overridden in Inkscape, but it is very annoying.
The only reason I agreed to the new file dialogs is that Ishmal restored the text input field that the Gnome folks removed in GTK 2.4. I agree that not having this field is an incredibly stupid limitation, but I don't understand why you blame Inkscape for it :) We are perhaps the only GTK 2.4+ app that does NOT suffer this problem.
No not Inkscape's fault, like I said I wasn't sure if we could override it in Inkscape but if so, we should because it's hard to use. ;-)
And by the way in GTK 2.6 they added type-ahead find in the file list (I'm using it already). So now we have the best of both worlds: the regular filename field and the type-ahead find in the list.
Oh good, I like in KDE apps. Good to see GNOME catching up there.
The save dialog is also strange because it is laid out differently than the file dialog. The name is at the top of the dialog instead of in the same place as the load dialog, for instance. That seems very different from how one would expect. Also, with the save dialog it seems redundant to have 'Save in folder' as well as a tree view; it's confusing.
They are not redundant because enabling one disables the other, and vice versa. Normally the save dialog is folded up and does not have the full filedialog, which is when you use the "save in folder" drop-down. This and the position of the filename field might indeed be changed, but these are relatively minor issues, and I prefer to leave them to the GTK folks to fix in future versions. Changing the standard dialogs is only justified for really serious usability problems, such as the missing filename field.
Okay, well I still think it's really weird, even if there's nothing to do about it but grumble. ;-)
Bryce
On Mon, 20 Dec 2004 18:28:40 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:
On Mon, 20 Dec 2004, bulia byak wrote:
On Mon, 20 Dec 2004 17:43:17 -0800 (PST), Bryce Harrington > The main problem is that I typically work with files in large, complex
directory trees (e.g., openclipart, etc.) so often it is fastest for me to type the paths and filenames in, and then hit enter to load it. This does not work in inkscape (afaik),
Why, it does! Haven't you tried?
Yes, I did, on a build from last week. Are you indicating that this has already been fixed, or just that you cannot replicate it?
These fields have always been there. Are you saying you're not seeing them, or are you referring to something different, such as Enter not working? If the text fields do not work as one would expect, please file a bug with detailed steps to reproduce.
Okay, well I still think it's really weird, even if there's nothing to do about it but grumble. ;-)
I think the file chooser is weird too. Bookmarks are the redeeming feature for me (once type ahead find is fixed that is, and knowing about Ctrl+L to get the Location dialog helps too). It is unfortunate that it managed to be good in ways so completely opposite to what the old version was good at. Six of one, half a dozen of the other.
It has been discussed to death and people are pretty jaded about it and as a result it is difficult to get changes made to it but there are a few outstanding bugs and the abscense of type-ahead find in the intial version of the New File Chooser was considered a big glaring ommission. The amount of modifications various programs have made to the file chooser is not a good sign either, one would hope that the stock file chooser would cover most bases and discourage developers from adding things in an inconsistant manner but hopefully things will continue to be improved and the clean API underneath keeps things all a lot more managable.
I jokingly suggest it was a conspiracy by anti-filechooser plotters so that we would revolt and kill off the file chooser entirely and use other methods (file managers, drag and drop, etc) instead. It isn't really a joke though.
- Alan H.
On Mon, 20 Dec 2004 22:15:19 -0400, bulia byak wrote:
The only reason I agreed to the new file dialogs is that Ishmal restored the text input field that the Gnome folks removed in GTK 2.4. I agree that not having this field is an incredibly stupid limitation,
I guess I should re-iterate that the reason this was done is because the GNOME guys want to eliminate file paths from the UI a la MacOS Classic.
As anybody who has ever tried to explain what ~/ or /mnt/net/homes/d20xt3 is to a non-technical user can appreciate, hiding the UNIX filing system is probably wise ... whether it makes sense for Inkscape users though I have no idea. They are perhaps in a different demographic to what GNOME is targetting.
thanks -mike
On Tue, 21 Dec 2004 13:10:30 +0000, Mike Hearn <mike@...333...> wrote:
I guess I should re-iterate that the reason this was done is because the GNOME guys want to eliminate file paths from the UI a la MacOS Classic.
As anybody who has ever tried to explain what ~/ or /mnt/net/homes/d20xt3 is to a non-technical user can appreciate, hiding the UNIX filing system is probably wise ...
I don't want to start a flamewar, but I still think it's an incredibly stupid idea. "Non-technical" users are NOT INTERESTED in what ~/ means. They are well aware of the fact that this computer thing has some stuff they do not understand, so they don't mind if it's cryptic sometimes. All they want is some way to get the result they need quickly and reliably every time. They are not obsessed with "understanding" every step they are making, so long as it works. And the filename field is a powerful shortcut that lets you get to the result much faster, especially for people who remember words better than pictures (and there are plenty of such people even among non-technical users) and for those who know how to use copy/paste (which is also far from uncommon among users of any kind).
So, even for non-technical users, this "improvement" is dubious at best. For the rest of us, it's a disaster, plain and simple.
On Tue, 2004-12-21 at 09:21 -0400, bulia byak wrote:
On Tue, 21 Dec 2004 13:10:30 +0000, Mike Hearn <mike@...333...> wrote:
I guess I should re-iterate that the reason this was done is because
the
GNOME guys want to eliminate file paths from the UI a la MacOS
Classic.
As anybody who has ever tried to explain what ~/
or /mnt/net/homes/d20xt3
is to a non-technical user can appreciate, hiding the UNIX filing
system
is probably wise ...
I don't want to start a flamewar, but I still think it's an incredibly stupid idea. "Non-technical" users are NOT INTERESTED in what ~/ means. They are well aware of the fact that this computer thing has some stuff they do not understand, so they don't mind if it's cryptic sometimes. All they want is some way to get the result they need quickly and reliably every time.
I'm not sure if I agree that people don't mind things being cryptic, especially if they are exposed in the UI, but I think that just hiding stuff isn't the goal; consistency is, including treating network virtual file systems (gnome-vfs can e.g. use an SFTP-accessible remote server as a file system) identically to local files; with this, the Unix single-rooted directory tree simply doesn't make any sense any more. The only thing that does make sense is actually an URI, but those are really ugly and besides for the user the netword transfer protocol should be pretty irrelevant. So they chose to work on making it look the same whether a file is on an actual mount point or on a virtual network filesystem. You may disagree with the decision, but there certainly is method to the madness.
With typeahead find I actually find the stock GTK+ filechooser to be pretty good. Without that feature (which IIRC was always patched into the Fedora version) I could see it being quite bad though. I would possibly agree that there should be a more obvious way of getting to the path dialog than '/' or ^L.
So, even for non-technical users, this "improvement" is dubious at best. For the rest of us, it's a disaster, plain and simple.
I bet that it really depends on what you're used to. I'm not one of the designers but I do find the design to be a huge improvement over many other file dialogs, much less cluttered and confusing than many of them.
/Per
On Tue, 21 Dec 2004, Mike Hearn wrote:
Date: Tue, 21 Dec 2004 13:10:30 +0000 From: Mike Hearn <mike@...333...> To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Re: filedialog change
On Mon, 20 Dec 2004 22:15:19 -0400, bulia byak wrote:
The only reason I agreed to the new file dialogs is that Ishmal restored the text input field that the Gnome folks removed in GTK 2.4. I agree that not having this field is an incredibly stupid limitation,
I guess I should re-iterate that the reason this was done is because the GNOME guys want to eliminate file paths from the UI a la MacOS Classic.
Too many cooks.
My feeling is that in an effort to make a decision that pleased the majority (even those people who didn't really want a file chooser at all) that GTK went about things a bit backwards (I'll explain in minute...)
As anybody who has ever tried to explain what ~/ or /mnt/net/homes/d20xt3 is to a non-technical user can appreciate, hiding the UNIX filing system is probably wise ...
This is very true.
Rerooting the directory tree starting at the users home directory works fairly well at hiding a lot of the complexity irrelavant to the ordinary user.
whether it makes sense for Inkscape users though I have no idea. They are perhaps in a different demographic to what GNOME is targetting.
The problems is that this demographic consists of the people least likely to use the file chooser at all, and they are far more likely to use drag and drop or open files using the file manager as advocated by those who would do away with the file chooser entirely (which is never going to happen)[1].
The reason I say GNOME/GTK has it backwards is that the defaultis to a fairly complicated file chooser and you must hit Ctrl+L to get the visually more simple location box where you can use regular expressions. Mac OS X on the other hand understands that ordinary users are not likely to be using the FileChooser that often and provide the visually simple location box first and a browse button that expands the dialog to a more complicated one.
I give it a year maybe two before things get to be reordered to be a lot more like Mac OS. (Possibly sooner if I bring it up on the lists, explain it clearly and can provide code).
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
[1] For accessibility reasons the Location box if fairly important, the current file chooser and the alternatives that have been suggested tend to rely fairly heavily on drag and drop or are not as clear and unambigious as a Location box.
participants (5)
-
Alan Horkan -
Bryce Harrington -
bulia byak -
Mike Hearn -
Per Bjornsson