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.
Wouldn't we need to have at least two signals for pushing and popping?
Not necessarily; the SPView could maintain a stack of messages, and simply notify observers via the signal when the top of its message stack changes.
But GTK already has the stack of statusbar messages, why duplicate it? I think it's better to make two signals instead, one for push and one for pop.
On the other hand, wait a minute. You have explained why we need to go to SPView in order to set statusbar. But why SPView has to send signals? This only makes sense if there may be more than one listener; but do we want different document windows to display the same message, even if they show the same document? I think not. Messages are always displayed in the window where the things happen. So maybe we can handle this without signals, i.e. get directly from the selection (or whatever else issues the current message) to its desktop widget?
Right now, given the current desktop, you need to look at SP_NODE_CONTEXT (desktop->event_context)->nodepath->selection to get a GSList of the selected nodes.
By the way, now it's GList, not GSList :) I changed that some time ago to do tab-cycling back and forward in a more natural way.
You know, being a usability freak, I care about usability not only for
users
but for coders too. I think that the coder should not be forced to
provide
anything but the obviously necessary information for each task.
My experience with using global variables over the years is that they DON'T make code more usable for developers (I use the term "maintainable"), in the long run.
Hey, actually my favorite programming language is XSLT, so you don't need to explain that to me :) And I was not advocating using globals, only making function calls as short and simple as possible.
The button actions should have been created on a per-desktop basis, rather than having a shared set that all used SP_ACTIVE_DESKTOP. However, fixing that requires a major reorganization of parts of the codebase.
OK, I promise to never use SP_ACTIVE_DESKTOP anymore :) Instead I will create several functions that accept different kinds of "current things" (such as selection, event context, desktop) and do different ->...->...-> chains to always arrive at the desktop widget that corresponds to that argument object (if possible, without signals). Then in different parts of the code I'll have to call different functions, depending on what object I have at hand. Would you approve of that plan?
Otherwise the chances of errors will increase because people (like me :) will have to copy obscure bits around without fully understanding them.
I don't want to stymie you, since you do really exceptional UI work -- just, for now I would prefer that you copy the bits of indirect code (maybe shifting them into helper functions for your own use), and in your own new code try to stick with passing things as parameters rather than using globals as much as possible.
I'm not against passing parameters; I just want these parameters to be logical and short, with the fuiction itself doing all the ->->-> instead of me :)
P.S. Have you tried my "black magic" bug? I have even recompiled it with -O1 but that did not help :( Do you think I can commit the g_print "fix" with appropriate comments (well, at least it's guaranteed not to break anything)?
_________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2...
On Sat, 2003-12-13 at 23:42, bulia byak wrote:
But GTK already has the stack of statusbar messages, why duplicate it? I think it's better to make two signals instead, one for push and one for pop.
I may have talked about using the GTK statusbar stack earlier, but then I looked further into the GTK statusbar API and it's really pretty awkward (IMO). How do you feel about it?
On the other hand, wait a minute. You have explained why we need to go to SPView in order to set statusbar. But why SPView has to send signals? This only makes sense if there may be more than one listener; but do we want different document windows to display the same message, even if they show the same document?
Other things are attached to SPViews/SPDesktops besides just SPViewWidgets/SPDesktopWidgets -- for example, event contexts. Event contexts are as much a part of the view layer as SPViewWidgets are (see further down).
Event contexts in particular don't happen to care about status message right now (except setting them), but other things might in the future.
I think not. Messages are always displayed in the window where the things happen. So maybe we can handle this without signals, i.e. get directly from the selection (or whatever else issues the current message) to its desktop widget?
What this boils down to is that I'm very reluctant to abandon the MVC pattern here -- it's demonstrated itself again and again in many different frameworks and applications over the years.
[ Note that I'm using the Cocoa-esque version of the nomenclature -- see e.g. http://cocoadevcentral.com/articles/000003.php -- unfortunately our class names in Inkscape are misnomers ]
In particular, the controller (SPDesktop/SPView) should not need to know any particulars of the view (SPDesktopWidget/SPViewWidget) internals (e.g. what widgets constitute it, or how they're set up). It's something of a wart on the design, IMO, that SPDesktop has a pointer to an SPDesktopWidget right now.
Individual view components (SPDesktopWidgets, SPEventContexts, etc...) should also not need to know about each other more than they have to.
To that end, I want to keep the signal (or at least some kind of notification callback) to maintain that interface boundary.
Right now, given the current desktop, you need to look at SP_NODE_CONTEXT (desktop->event_context)->nodepath->selection to get a GSList of the selected nodes.
By the way, now it's GList, not GSList :) I changed that some time ago to do tab-cycling back and forward in a more natural way.
Ah, cool. Thank you. ^_^
OK, I promise to never use SP_ACTIVE_DESKTOP anymore :) Instead I will create several functions that accept different kinds of "current things" (such as selection, event context, desktop) and do different ->...->...-> chains to always arrive at the desktop widget that corresponds to that argument object (if possible, without signals). Then in different parts of the code I'll have to call different functions, depending on what object I have at hand. Would you approve of that plan?
Well, at present SP_ACTIVE_DESKTOP is a necessary evil in a few places -- but I'd certainly appreciate if you could minimize its usage.
Creating helper functions to get the associated SPDesktop for something, in the cases where they don't already exist, would be great.
Adding a method to SPEventContext to set the status message for that event context's desktop would be good too (maybe something printf-like ... e.g. sp_event_context_set_statusf (SPEventContext *context, const gchar *format, ...)?).
However, I don't think event contexts or related code should be directly touching the SPDesktopWidget or its children. Ever.
I'm not against passing parameters; I just want these parameters to be logical and short, with the fuiction itself doing all the ->->-> instead of me :)
That's the direction I'd like to take the code in too. ^_^
I just want to be careful about which simplifications are made, because some are only short-term gains, at the epense of bigger simplifications in the long-term.
P.S. Have you tried my "black magic" bug? I have even recompiled it with -O1 but that did not help :( Do you think I can commit the g_print "fix" with appropriate comments (well, at least it's guaranteed not to break anything)?
I still need to see if I can replicate the bug -- if so, comparing the generated assembly code with and without the g_print() would be informative. It sounds like a compiler bug...
-mental
participants (2)
-
bulia byak -
MenTaLguY