GNOME.org
 

Re: [Banshee-List] Native file open dialogs, feedback needed



-- 
David Nielsen
Sent with Sparrow

On Tuesday den 17. July 2012 at 04.12, Timo Dörr wrote:


Using the GTK dialog means it's not consistent with other apps on OS X
or Windows, but at least Banshee is consistent with itself. I guess a
native file dialog would look different from all dialogs in Banshee:
theme, buttons, icons, etc. Wouldn't that be weird, like the file
dialog doesn't belong with Banshee ?

I can't tell about the quality of the Gtk Chooser on Windows, since I
never used it.

As for Linux, the GTK file chooser IS the native chooser for all gnome
users. It shows your bookmarked folders, external connected drives,
network shares/mounts and so on, just perfectly as one would want to.

On OS X, the gtk chooser is poorly integrated into the OS, and it does not
display any of them (no bookmarks besides the one you add from within gtk
chooser, no external/mounted media, no network shares). So it not only a
cosmectic enancement, but a functional one.

For comparisson I created screenshots of how the file open dialogs look on
OS X:
(I dont have a usb drive connected but 2 internal harddrives, and as one
sees the 2nd harddrive is not shown in GTK).

Right now, if a User wants to import media from external hdd drive, he/she
has to know the underlying mountpoint, which is /Volumes/ on the root (or
main harddisk). This somehow corresponds to the /mnt/ oder /media folder
on linux. But in contrast to linux, Mac OS X always "hides" the /Volumes
folder away from the user. It is not displayed if you select your hard
drive in Finder, and even if you want to, there is no way of getting into
the /Volumes/ folder from within the OS X native file chooser - the UI is
just not meant to get there.

Here is a screenshot of how OS X displays your / (root) folder from within
the UI:
Not only is /Volumes/ hidden, but the /opt, /var, /usr/ etc. that are
present on OS X, but always and consistently get hidden throughout the
GUI. Knowing that your drives are mounted in /Volumes/ is something only
pro users know, that use the terminal. So at the moment, with the gtk
chooser the user has to navigate to Filesystem->Volumes to get your
external/network media, while a user will certainly never have navigated
there before when using only OS X interfaces.

Althogh there a very few OS X questions on the mailing list, we had that
very same problem by a user who couldn't access his usb drive, see this


I'm also wondering about how the various features of the GTK file
chooser dialog would be "translated" into the native dialog: the
action (open, save, select folder, create folder), the shortcuts, the
file filters (see ImageFileChooserDialog), adding an extra widget in
the dialog (see PlaylistExportDialog), maybe some other stuff I'm
forgetting, and not counting the different API semantics between
platforms.

That is indeed a problem which I did not see on my original post. I have
currently a patch that is very non-intrusive on current code, but only
provides a native chooser for Media->Import Local file/Import local
Folder. For other Dialogs (like the ImageFileChooser) the
FileChooserDialog from Gtk is used as a fallback. I'm still having
problems integrating with the Mono.Addins, but once the patch is ready
I'll post to discuss on that when having the code.


If we use the native OSX file selection dialog, would this bring other
benefits than cross-OS consistency ? Thinking about the Windows file
dialog, which I'm more familiar with, I can't see anything other it
would bring.

As I said its not only about consistency, but the gtk chooser lacks very
important functionality on OS X.

The fact that you have to know that external mounts are in /Volumes even tricked me for a minute and I have seen several users experience problems with this. I would love to see it addressed and I think the right way to do it would be to switch to the native file dialog.

I guess one could attack this upstream in GTK+ as well but frankly that sounds like a big job and something one would very quickly be volunteered to maintain.
Related question: Does MonoDevelop use the native file dialog on OS X
? On Windows, it uses the GTK dialog.

On OS X, it uses the native OS X dialogs which have been added in MD 2.6:


Then finally, using native file dialogs would be our first step away
from using GTK for all UI stuff, and towards having platform specific
UI. But maybe that's just me being old and afraid of change :)

I am 100% commited to sticking with GTK and introduce as few platform
specific UI as possible. All Widgets should be platform independent and
all platforms should share the same GUI. Just the parts that introduce
serious drawbacks should be done natively.
Long term I would like to see a fully separate UX on OS X and Windows, I know it has been requested by our users and I feel like we could offer a superior experience that way. GTK+ on OS X and Windows are not very well tested, tends to look out of place and development on these platforms tends to be an afterthought at best.

However today and in the foreseeable future I agree GTK is our best bet, we should though as you say overwrite GTK with native functionality where it seriously regresses the user experience. 

- David
Greetz
Timo



So I'd be happy to hear more about this, and maybe be convinced to
change my mind...

--
Bertrand

Am 06.07.2012, 16:46 Uhr, schrieb David Nielsen <gnomeuser gmail com>:


I admit my preference is for option 3, it seems the most in line with
how
Banshee is generally designed.

- David

Sendt fra min iPad

Den 06/07/2012 kl. 11:10 skrev Timo Dörr <timo latecrew de>:

Hi all,

I was just playing around with implementing native OS X "file open"
dialogs in banshee. I am somewhat unsure of what is the best design
decision
of implementing that.

Right now, (all (or at least the most) platform-specific code goes
into
its according backends which are Banshee.Osx, Banshee.Unix and
Banshee.Windows. This works for the HardwareManager and other
plattform
specific code very well. The FileChooserDialog.cs resides in the
Banshee.Gui.Dialogs within Banshee.ThickClient, and is compiled on
all
plattforms atm.

I see a bunch of possibilities of how I could implement the native
FileChooser:

(1): Create a OsxFileChooser.cs within Banshee.Gui.Dialogs and have
it
completely surrounded by #if PLATFORM_DARWIN compile conditionals.
This
would require changes to the autofoo scripts. Same could be done
with a
future possible WindowsFileChooserDialog.cs. Current
FileChooserDialog.cs is
moved into GtkFileChooser.cs and the FileChooser.cs (and its class)
are
replaced by a bridge class (using the bridge design pattern), that
uses
Hyena.PlatformDetection to decide which of the classes is to be
instantiated
and returned. This would require compile conditionals #if in the
FileChooserDialog.cs, to.

(2): like (1), but without the bridge design pattern and without the
#if
in the FileChooser.cs file. Instead, create an empty partial class
FileChooserDialog, and the other implementations
({Osx|Gtk|Win}FileChooserDialog) are also partial - again the #if
compile
conditionals surround each platform-specific version, and thus
decide which
class is compiled into the actual FileChooser

(3): Move the platform dependent {Osx|Gtk|Win}FileChooser (and
possibly
other dialogs) in the according Backends like
Banshee.{Osx|Windows|Unix}.
Change the FileChooserDialog.cs to load the correct implementation
via
mono.addins as an ExtensionNode, depending on
Hyena.PlatformDetection. This
has the advantage of not having to introduce preprocessor
conditionals, as
the autofoo code for conditionally compile the correct
Osx/Windows/Unix
backends is already in place. Disadvantage is, it is the solution
which
changes the most code and design change.

Any suggestions or feedback which is the best way to go?

Greetz
Timo
_______________________________________________
banshee-list mailing list


--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
_______________________________________________
banshee-list mailing list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]