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.
I still don't see why SPView is involved in statusbar handling... but anyway, if you say this is right, let it be. What ails me is that I want to provide a richer and more convenient interface for statusbar messages. For example, I want a function for temporary displays that are pushed and then popped after some timeout. This means the statusbar signal must be split in two, or at least given extra arguments. Is this the right approach?
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'.
Right, but what is to be done now? As I wrote, now all calls to sp_view_set_status start from the desktop and figure out its view. If this is wrong, what is right? Starting from some object on the canvas that logically "issues" the message, ascending to its SPView, and then sending a message from SPView to the associated desktop widget? That seems overly complicated to me, but I'm OK with it if its implemented and if I'm given a convenient interface to it.
In other words, what is the minimum of arguments that a statusbar-setting function (callable from anywhere) must have? Now it accepts a message and an SPView, but I don't like having to figure out the SPView every time I call it. Can there be a function that accepts only the message and if yes, how to program it properly?
_________________________________________________________________ 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 Sat, 2003-12-13 at 12:26, bulia byak wrote:
I still don't see why SPView is involved in statusbar handling...
Because it is desirable to permit multiple views of the same document with different states and status messages. Hence, the current statusbar message is per-view rather than per-document.
What ails me is that I want to provide a richer and more convenient interface for statusbar messages.
BTW, I think your idea for push/pop/timeout is good.
For example, I want a function for temporary displays that are pushed and then popped after some timeout. This means the statusbar signal must be split in two, or at least given extra arguments. Is this the right approach?
I would prefer that you implement the push/pop/timeout behavior and API in SPView, perhaps supplementing or replacing sp_view_set_status().
The signal itself should not need to change.
Right, but what is to be done now? As I wrote, now all calls to sp_view_set_status start from the desktop and figure out its view.
SP_VIEW() is just a cast-to-pointer-to-superclass macro. The SPDesktop IS the SPView.
If this is wrong, what is right?
The only wrong part is that sometimes SP_ACTIVE_DESKTOP is used, instead of determining which desktop is really appropriate. More on that below.
Starting from some object on the canvas that logically "issues" the message, ascending to its SPView, and then sending a message from SPView to the associated desktop widget? That seems overly complicated to me, but I'm OK with it if its implemented and if I'm given a convenient interface to it.
There can be more than one desktop (view) displaying an SPItem at the same time. Which desktop would be meant?
In other words, what is the minimum of arguments that a statusbar-setting function (callable from anywhere) must have? Now it accepts a message and an SPView, but I don't like having to figure out the SPView every time I call it.
The current message is effectively a property of an SPView, though...
Can there be a function that accepts only the message and if yes, how to program it properly?
Not unless we wanted to switch to all statusbars showing the same message. Using SP_ACTIVE_DESKTOP is not reliable.
For example, in sp_selection_update_statusbar() in selection.c:
sp_view_set_status (SP_VIEW (SP_ACTIVE_DESKTOP), message, TRUE);
What happens if SP_ACTIVE_DESKTOP is not the desktop that the selection object is attached to? What if it's a desktop for an entirely different document. This won't normally happen (yet), but it could in the future.
There is no need for the extra indirection anyway. An SPSelection knows which desktop it is from; this should be:
sp_view_set_status (SP_VIEW (selection->desktop), message, TRUE);
-mental
participants (2)
-
bulia byak -
MenTaLguY