Transition from MainWindow.Toplevel to App.Instance.Organizer

[Paul Wellner Bou <paul purecodes org>]

Hi,

As some of the changes in f-spot's git source broke my tabbed sidebar 
addon I tried to look a bit deeper into what had changed and why the 
transition is not as easy as replacing MainWindow.Toplevel with 
App.Instance.Organizer. (And, of course, MainWindow.Toplevel.Database 
with App.Instance.Databes -- which is absolutely no problem).

I'd really like to do something here -- so /please let me know/ if this 
is complete nonsense and/or there is another strategy for the transition 
to use unique#'s App exclusively and/or there is another reason why my 
thoughts and suggestions to remove some of the constructor dependencies 
are not welcome.

In theory, the MainWindow.Toplevel is referencing the same MainWindow 
instance as App.Instance.Organizer (see 
http://gitorious.org/f-spot/paulwbs-clone). The only problem is at 
startup. The constructor of MainWindow is doing tons of stuff and if 
there is any reference to App.Instance.Organizer in any method which is 
called by the constructur this causes an infinite recursive loop of 
MainWindow instantiations.

I discovered a few lines where it is now not possible to use 
App.Instance.Organizer instead of MainWindow.Toplevel. For example:

src/Widgets/InfoBox.cs:191: InfoBox() is instantiated in the MainWindow 
constructor. The constructor of InfoBox is calling SetupWidgets(), and 
SetupWidgets is using MainWindow.Toplevel.Window to get out the 
Gdk.Color to draw the histogram widget. To get rid of the 
MainWindow.Toplevel dependency, which would be nice, I think, would be 
either to use default colors and create a method to set the colors 
afterwards or to create a InfoBox ctor parameter accepting a Gdk.Color.

Other affected lines:

src/QueryWidget.cs:155,161
src/Widgets/InfoBox.cs:191
src/FolderQueryWidget.cs:32

What do you think?

Regards
Paul.