Currently, whoever needs to update statusbar calls sp_view_set_status() giving it the message and a pointer to a SPView object. This function emits a signal from that SPView object, and this signal is caught by the desktop object which does actual update to the statusbar (using gtk_statusbar_push()).
This seems strange. Why is SPView involved at all? In ALL cases when sp_view_set_status() is called, the caller code has (or finds out) the current desktop and then finds its SPView by saying SP_VIEW(desktop), only to pass this to the sp_view_set_status(). Given that the message ends up being handled by the desktop anyway, the entire mess with SPView and emitting/catching signals seems unnecessary to me. The code needing to update statusbar could call a function in desktop.c directly, either giving it some desktop pointer, or even letting it find out the current desktop automatically. The signal and the statusbar-setting functions in view.c could then be eliminated. I think the code would be simpler and more logical this way. Any comments?
_________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
On Fri, 2003-12-12 at 19:46, bulia byak wrote:
This seems strange. Why is SPView involved at all? In ALL cases when sp_view_set_status() is called, the caller code has (or finds out) the current desktop and then finds its SPView by saying SP_VIEW(desktop), only to pass this to the sp_view_set_status(). Given that the message ends up being handled by the desktop anyway, the entire mess with SPView and emitting/catching signals seems unnecessary to me. The code needing to update statusbar could call a function in desktop.c directly, either giving it some desktop pointer, or even letting it find out the current desktop automatically. The signal and the statusbar-setting functions in view.c could then be eliminated. I think the code would be simpler and more logical this way. Any comments?
The way the class hierarchy works is:
SPView - base class for all views of an SPDocument ^ SPSVGView - rendered graphical view ^ SPDesktop - editable rendered graphical view
SPViews are the 'model' side of the MVC equation, with various widgets (SPDesktopWidget is the one normally used with SPDesktops) acting as view/controllers. It's actually the SPDesktopWidget, not the SPView (SPDesktop) which is subscribing to the status message signal.
While there are presently no other SPView subclasses, my current plan is to do the new XML editor and the new layer UI as view/controller widgets for appropriate SPView subclasses. At least the XML editor might benefit from a status bar.
Btw, I do not want us to introduce more global state as far as "finding the current desktop automatically" -- eventually I want all signal handlers and SPActions bound to specific views, so they "know" their associated view rather than having to look at a global variable to know which is 'current'.
-mental
participants (2)
-
bulia byak -
MenTaLguY