Transition from MainWindow.Toplevel to App.Instance.Organizer
- From: Paul Wellner Bou <paul purecodes org>
- To: F-spot-list gnome org
- Subject: Transition from MainWindow.Toplevel to App.Instance.Organizer
- Date: Tue, 10 Nov 2009 13:41:48 +0100
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
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:
What do you think?
] [Thread Prev