libxdg-vfs - screenshots

[Bastian, Waldo]

>On Mon, 2006-06-26 at 21:57 +0200, nf2 wrote:
>> The problem is, that this will only work for standard file-open/save
>> dialogs, but a lot of applications want to customize file-dialogs
with
>> their own widgets (previews, filter options, checkboxes etc...). In
this
>> case the coupling between the toolkit of the application and
>> file-choosers seems too tight for defining a standard interface.
>>
>> Perhaps a clean separation between presentation layer (toolkits,
>> widgets, dialogs) and infrastructure layer (VFS API) would work
better
>here.
>
>This still has the problem of decreasing usability of an application
>though. The behavior of several widgets will be different across
>toolkits, and the button order in the dialog may be different. And then
>the theme may look entirely different as well. I don't think it's
really
>worth the effort to try opening the appropriate dialog until the rest
of
>the look & feel issues are sorted first.

Sure, that's a problem, but you have that problem nowadays as well. Look
at the usability of the system as a whole and you will find that it is
horrible as long as you have different themes and button order settings
between Gtk and Qt applications. It's hard to say whether an application
with a file-dialog that doesn't match the widget of the rest of the app
is worse than an application with a file-dialog that doesn't match the
other file-dialogs on the system. I'm inclined to think that a user
adapts easier to an "out-of-place" file dialog if there is only one kind
of file dialog he has to deal with. But let's not go there. Yes, fix the
look & feel, but while we wait for that to happen, let's not use it as a
stop-energy excuse for not looking into solutions for other issues.  

Cheers,
Waldo