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

[Timo Dörr <timo latecrew de>]

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/