GNOME.org
 

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



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: 
https://dl.dropbox.com/u/14469783/Banshee-OSX/dialogs/macchooser.png (OS X)
https://dl.dropbox.com/u/14469783/Banshee-OSX/dialogs/gtkchooser.png (GTK)
(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: https://dl.dropbox.com/u/14469783/Banshee-OSX/dialogs/hidden_volumes.png 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 post: http://banshee-media-player.2283330.n4.nabble.com/help-td4650367.html 



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. 



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: http://monodevelop.com/index.php?title=Download/What's_new_in_MonoDevelop_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. 

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
banshee-list gnome org
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)



--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]