I think what I want to do initially is have SPView provide two "virtual" methods (we'll need to use the GObject vtable for now rather than real virtual methods):
StatusMessageID SPView::postStatusMessage(StatusMessageType type, bool flash, gchar const *message);
void SPView::cancelStatusMessage(StatusMessageID id);
StatusType would be an enum indicating the "style" of the message -- warnings might get a little warning icon next to them, etc...
postStatusMessage returns an id which can be later used to cancel the status message with cancelStatusMessage.
I.e. that is different from the current system in that you added a style param and use an id to cancel messages. I don't see any problems with that, except that I don't see much use for the style param currently, and I also want to preserve the current pop function (popping whatever is at the top of the stack without an id) as well, because in many situations (such as dragging or navigating in menu) there's really no need to fiddle with ids. That would be extra work for no extra benefit, for in these cases nothing can conceivable overlay the message that you just pushed up.
_________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Sun, 2004-05-02 at 22:20, bulia byak wrote:
I also want to preserve the current pop function (popping whatever is at the top of the stack without an id) as well, because in many situations (such as dragging or navigating in menu) there's really no need to fiddle with ids. That would be extra work for no extra benefit, for in these cases nothing can conceivable overlay the message that you just pushed up.
I'm not sure I agree ... with dragging at least, warning/notification messages might get displayed by other code. Code using pop() is making a global assumption that's can't be guaranteed[1]. Simple cases can become a lot more complex when underlying code is altered.
I think it's better to provide a simple solution that works in all cases. Have a look at the proposed StatusMessageContext; it should work universally and handle ID tracking automatically.
But let me know if you think of cases where it would be inconvenient. I'm still sketching at this point.
-mental
---
[1] Exercise: could you add an assert() to pop() that would fail if code used pop() to pop a message it did not push?
If not, what API changes would be necessary to provide enough information for the assert()? Those changes would highlight the previously implicit assumptions.
participants (2)
-
bulia byak -
MenTaLguY