On Sat, 2003-12-13 at 16:47, bulia byak wrote:

...

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.

OK, but what if there's no selection currently?

The example I gave was from sp_selection_update_message(), which takes a selection as a parameter. It is essentially a method of SPSelection; it has no meaning if it is not supplied a selection object (and will currently segfault in that case, actually).

I was just citing it as an example of what not to do and (a little bit) why, rather than suggesting a general API.

And what if I want to update statusbar in the node editor? Its idea of selection is different (nodes).

I think we likely need to revise the selection API to handle node selection in a more consistent way, but I have not had time to look into that yet.

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.

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.

I agree that our codebase _does_ have significant maintainability problems at this point, but using globals more heavily would only make them worse.

A really succinct description of the problem is that globals break encapsulation:

* they make code context-dependent, and harder to analyze

* they break reentrancy and thread-safety

* they break testability

* they make refactoring much more difficult

Concrete example: when we switched to having per-window toolbars, we originally had a problem with the tool buttons getting confused, because no matter which window was active, the buttons were looking at SP_ACTIVE_DESKTOP.

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.

Rather than doing that just before the release, I wrote a very ugly hack that works, but I had to deliberately break toggle buttons for other purposes to do it.

Similarly, the reason it's now so needlessly complex to get at the node selection is precisely because SP_ACTIVE_DESKTOP was used in the first place. As the code grew, the use of the nodepath selection got buried under many layers.

Wouldn't it have been much more maintainable if these functions had been passed e.g. the current nodepath, or even the list of selected nodes, or the particular desktop the action was intended for in the first place?

The problem right now is that APIs aren't getting passed the information they need, and are sometimes being passed a lot of information they don't.

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.

We need to rework the internal interfaces so that all the needed information is already available from (a few!) parameters. I don't want to start pulling global state information in a more widespread fashion -- that will just make that process much, much harder than it is now.

-mental