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

[Bertrand Lorentz <bertrand lorentz gmail com>]

On Fri, Jul 6, 2012 at 8:30 PM, gnomeuser gmail com <gnomeuser gmail com> wrote:
> 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.

Sorry it took so long for me to respond. I seem to have trouble
keeping up with Banshee stuff these days.

I agree that, if we want to have native file selection dialogs, option
3 would be the best way to go. But I'm not sure we should have native
file selection dialogs.

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'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.

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.
Related question: Does MonoDevelop use the native file dialog on OS X
? On Windows, it uses the GTK dialog.

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 :)

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