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

["gnomeuser gmail com" <gnomeuser gmail com>]

2012/7/6 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 ?

It is starting to feel like we might want to do just that, however I
think that is up to Bertrand to decide, him being our fearless leader
and all.

- David

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