This is an excellent idea. What we would need to do is accelerate work on a "viewer" Gtkmm widget. Basically this would be an embeddable "inkview" using Gtkmm technology. I started such a widget in /src/ecma, but it is just a Gtkmm wrapper of the sp_view Gtk thing, and it works badly. I think that we need to do clean designs of these things from the ground up, totally in Gtkmm.

Just my IMHO. :)

Bob

Tobias Jakobs wrote:

Am Do, den 22.07.2004 schrieb bulia byak um 23:43:

...

...

I haven't committed it yet, but it is mostly done. It just needs some tweaks. If this works well enough, then we can throw away the buggy Win32 dialogs in the next few days. Any opinions?

Looks OK to me, though I would prefer to replace the left pane with a preview image.

Put the preview image on the right, like the new Gimp filechooser:

http://www.gnome.org/~jrb/files/filechooser-gimp.png

Tobias

On Fri, 2004-07-23 at 20:14, Bob Jamison wrote:

I started such a widget in /src/ecma, but it is just a Gtkmm wrapper of the sp_view Gtk thing, and it works badly. I think that we need to do clean designs of these things from the ground up, totally in Gtkmm.

What's wrong (architecturally) with SPView?

-mental

I was thinking that the way that we should do preview is by saving a thumbnail using the freedesktop.org standard for thumbnails when the user saves. Then we would get a preview the next time we got it open, we would be able to use our renderer (versus librsvg's), and we wouldn't have load a full SVG file every time someone clicked on the wrong file in the file dialog. Thoughts?

I like the idea, though in my experience these thumbnails tend to go out of sync and just generally get in the way of things. Also what if a user move the file to another place and (that's to be expected) forgot to move the thumbnails? For this situation, as well as for old files, we'll still need to render the svg on the spot. So this approach won't make the open dialog code much simpler, though it will make loading thumbs much faster in a typical situation.

Actually you're supposed to be able to type the filename and the selection will move as you type (though I've not tried it).

First, it does not work. Second, even if it did, typing without seeing the actual characters you type is the most hideous offence against usability I can imagine.

I don't think it would be impossible to add a text entry field to the dialog, though, if it were required.

I hope so. It's clearly required.

On Sat, 2004-07-24 at 19:35, bulia byak wrote:

...

I don't think it would be impossible to add a text entry field to the dialog, though, if it were required.

I hope so. It's clearly required.

We'll have to somehow. The old file dialog API will eventually go away and (from an API perspective) it's not as clean anyway.

I hadn't noticed it before because I use Debian, and debian replaced the file dialog with something more sensible in their version of Gtk (same API, but different behavior/appearance).

I knew the "official" version was a bit different, but I'd never used it before.

This really sucks. :/

-mental

On Sat, 24 Jul 2004 20:35:44 -0300, bulia byak wrote:

First, it does not work.

I think you need a very recent version of GTK - it was added after 2.4.0 shipped!

Second, even if it did, typing without seeing the actual characters you type is the most hideous offence against usability I can imagine.

Well, I'd probably agree to this ...

bulia byak wrote:

I just tried the new filedialog. I've never seen it before in any other program, and therefore I had not realized that it has one really bad problem: there's no text entry field for the filename anymore.

This means I cannot type in or paste a filename. All I can do is click click click, helplessly and infuriatedly. (Yes, I found I can press Ctrl+L from the dialog, but it's so stupid and inconvenient that I don't want to even discuss this. Besides, I actually read about it somewhere on the net - the dialog itself provides no clue on this hidden feature.)

OK, Gnome is free to blatantly disregard usability - I don't care, I don't use it anyway. But Inkscape is something I care about a lot. Hence my question: can we please restore the entry field and put default focus to it in the new dialog? If not, I think we should return to the old one.

I can't find the reference right now, but I found some message on Google about how to add a text widget to the open dialog. Just set_extra_widget(Gtk::Entry), and a couple of callbacks.

Bob

MenTaLguY wrote:

On Sat, 2004-07-24 at 19:55, Bob Jamison wrote:

...

I can't find the reference right now, but I found some message on Google about how to add a text widget to the open dialog. Just set_extra_widget(Gtk::Entry), and a couple of callbacks.

We'll also need to make sure we work well with Debian somehow -- their version of the dialog already has a text entry field.

-mental

Another possibility is that, since Open and Save are using the same code, the text widget in Open might be present, but merely hidden. Anyway, still doing a bit of research. Tried adding that text field manually; it was laid out perfectly beneath the panels as though it belongs there.

Bob

I'd really not recommend messing with the default layout in Inkscape. If people want to fork GTK over the issue they are free to do so (though i'd not really recommend that either) but I think Inkscape has to assume the GTK developers will sort things out in their own time.

I disagree. Such a blame game ("it's not our fault, complain to GTK") is useless and stupid. As a user, I do not want to know anything about GTK at all! All I want is Inkscape working properly.

So if we can fix a GTK problem on our own, especially such a bad problem as this one, we must. By the way this will also be a good hint to GTK for them to fix things, stronger than regular user complaints I think.

I know that the lack of easy keyboardability has been a consistent sore point with people so I think there are plans to address that, if not already done so.

The lack of transient dialogs in Gimp (and Sodipodi) was a sore point too, and it dragged on for years with a similar blame game ("it's not our fault, complain to your window manager"). In Inkscape, this was the first thing we fixed after the fork, and everyone is happy since then. Moreover, in 2.1 Gimp finally fixed this too (better late than never...)

Nathan Hurst dichiarò:

...

So if we can fix a GTK problem on our own, especially such a bad problem as this one, we must. By the way this will also be a good hint to GTK for them to fix things, stronger than regular user complaints I think.

Absolutely. The gnome people seem to have forgotten about actually testing their designs. The non-debian gnome 2.4 file dialog can only be described as primitive and sucky. They have also demonstrated disinterest in external improvements -- the 2.2 file dialog was attrocious and debian and mandrake both had replaced it with something functional and simple, yet gnome refused to incorporate this change, instead inventing their own even more dysfunctional system.

The old file dialog was very ugly, as it was a leftover from GNOME 1.x (which was ugly for a thousand reason).

Noone in GNOME 2.x remade the file dialog because there was the need to redo the API first, but noone did it before GNOME 2.6.

The only thing that was done was the simple patch from Ximina Desktop, included in Debian (and Mandrake, I suppose).

But the old file dialog was still very ugly. Only a little bit more functional, but still a pain to use.

The new file dialog is a lot better to use. It needs only a little bit of pratice to get used, but is a lot simpler, in particular using it with the mouse.

The decision to hide the text entry (it is still here, just press Ctrl-L as in a web browser) was taken to hide the complexities and the differences of the underlying OS from the user.

Now he can ignore if inkscape is running on linux ("/"), MacOS (":") or Windows (""): the file separator is hidden, giving a better consistency between different platforms. If he want to use it, just press Ctrl-L and be done, but for non-geek users I can guarantee it is a lot better (tested on my parents :)

...

The decision to hide the text entry (it is still here, just press Ctrl-L as in a web browser) was taken to hide the complexities and the differences of the underlying OS from the user.

Thanks for letting us know the rationale behind this. Honestly I would never have guessed myself :) Needless to say, I'm not convinced :)

IMO, at least adding an expander widget to the dialog would be a reasonable compromise.

Yes, and only if it remembered its expanded/contracted status across all applications, so that I could expand it once and forget about that.

bulia byak wrote:

...

...

IMO, at least adding an expander widget to the dialog would be a reasonable compromise.

Speaking of which, the bookmark list on the left is also a prime candidate for going into an expander, off by default.

I looked into hiding this thing today, with no luck. If anyone finds a way to do it, please let me know. I see no purpose for the bookmarks stuff.

Bob

MenTaLguY ricercò:

...

The new file dialog is a lot better to use. It needs only a little bit of pratice to get used, but is a lot simpler, in particular using it with the mouse.

Research has shown that most users keep their files in rather broad, flat hierarchies.

Semi-flat. As in ~/images, ~/music, ~/documents, etc.

Scroll-and-click by itself is neither a simple nor an efficient approach for them.

Yes, but the solution is select-as-you-type (as in nautilus), not the text entry.

What users really need is a simple (live) substring or prefix search to winnow the list and reduce hunt-and-scroll.

I think that using the nautilus behaviour of select-as-you-type would be sufficient and consistent with the other user experiences.

One possibility would be to use the entry field for that role -- explicit (fully typed) filenames or paths would become simple degenerate cases. (on the other hand, entries disappearing as they typed might be disconcerting)

I don't think that re-enabling the text entry is a good idea...

...

The decision to hide the text entry (it is still here, just press Ctrl-L as in a web browser) was taken to hide the complexities and the differences of the underlying OS from the user.

From a UI perspective, that is a failure. How is the user supposed to know Ctrl+L does this?

The UI will fail not when you can use a program for the first time, but when you cannot use it after someone has told you how to use it.

Ctrl-L is already used in nautilus (useful with the new spatial mode) and in the web browser (epiphany but also tested with mozilla).

I've been using thi file dialog for a while and, apart some minor annoyances as the lack of select-as-you-type, I find it quite comfortable.

I now it can appear strange at first sight, but it is not so terrible to use... :)

Most of the Inkscape developers are pretty hardcore. If _we_ were totally unaware of the text entry hidden by Ctrl+L (how were we to know? where is it documented?), there's a serious problem. And we're the target audience for that shortcut.

Well, I've read about during the development process. But I've already used it in mozilla and epiphany before. And also in nautilus, when I've upgraded to GNOME 2.6

There needs to be a visual "affordance". For example, Mac OS X's open dialog also hides part of its UI from the naive user, but it provides an expander widget -- a standard visual metaphor both indicating that there is more hidden UI, and providing a _visible_ means of revealing it.

This could be a good idea, but with the expander my use didn't change: I press Ctrl-L to get the text entry, which is now in the expanded part of the dialog, instead of a popup window.

IMO, at least adding an expander widget to the dialog would be a reasonable compromise. Pets and small children will not be scarred for life if they click it out of curiousity. The text entry widget is not Janet Jackson's boob.

:D

On Sat, 24 Jul 2004, bulia byak wrote:

Date: Sat, 24 Jul 2004 19:32:23 -0300 From: bulia byak <buliabyak@...400...> To: Bob Jamison <rjamison@...357...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Gtk2.4/gtkmm2.4 file dialogs

I just tried the new filedialog. I've never seen it before in any other program, and therefore I had not realized that it has one really bad problem: there's no text entry field for the filename anymore.

This means I cannot type in or paste a filename. All I can do is click click click, helplessly and infuriatedly. (Yes, I found I can press Ctrl+L from the dialog, but it's so stupid and inconvenient that I don't want to even discuss this. Besides, I actually read about it somewhere on the net - the dialog itself provides no clue on this hidden feature.)

OK, Gnome is free to blatantly disregard usability - I don't care, I don't use it anyway. But Inkscape is something I care about a lot.

there were endless usuability discussions and suggestions, they eventually went with one suggested design that was better in some ways and sucks in others.

I dont like the clever new location widget and I dont like that they have removed the text entry box for filenames/locations either.

I dont have it to hand but there is a bug report complaining about it and I'll post it later (but I encourage you to find it, complains about location bar and accessibitilty).

Hence my question: can we please restore the entry field and put default focus to it in the new dialog? If not, I think we should return to the old one.

The most important feature of the recent changes is the clean new FileChooser API. It should be relatively easy to completely replace the file chooser for everyone and aviod Inkscape specific solutions. (more ideas on how this could be done in a practical manner later).

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/