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