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



Yes, I think (3) is the best approach, too. Just figured no matter what  
approach, other dialogs that derive/depend on FileChooserDialog exist  
(ImageChooserDialog, PlaylistExportDialog etc.). There will be larger code  
moves from Banshee.Gui.* to the platform specific backends. Maybe  
introduce a subfolder in Banshee.Osx/Gui and Banshee.Windows/Gui ?
Greetz
Timo

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

--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
_______________________________________________
banshee-list mailing list
banshee-list gnome org
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
_______________________________________________
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]