> So while there is only one cursor to do all jobs now, some of the cursor > actions are still quite local and specific to the individual edit view > you're working with at the time. > > This seems to suggest to me what we need is some kind of local cursor > actions toolbar that stands by itself, not folding these orphaned actions > into something else.
Well that was all interesting. I've really got some catching up to do getting my head around the new model, don't I? My initial response to Jani's suggestion really demonstrates how little I thought thought about the ramifications of Chris trying to implement the often requested "one cursor" model. Everything I was thinking about these being "local actions" has traditionally been true, but you're quite right Jani that these all might as well be included with the transport controls now, because there is only one cursor for everything everywhere, and whatever you're doing with it in one edit view, it does the same thing in every other edit view too. So how is that even supposed to work with things like cursor up/down staff and previous/next segment? These concepts have no meaning in the global context, so I guess we just have to abandon these actions completely, and find some other mechanism for accomplishing the intended result? (These four in particular were mostly or entirely designed to facilitate working with overlapping segments on the same notation staff, where the only big problem is controlling which bit of what you're editing at the moment, not with actually drawing or laying anything out.) Then what about the transport. Indeed, these should go on the transport now if that's what they are, but who wants to see a transport with another... Well how many? "cursor_back" "cursor_forward" "cursor_back_bar" "cursor_forward_bar" "extend_selection_backward" "extend_selection_forward" "preview_selection" "clear_loop" "cursor_up_staff" "cursor_down_staff" "cursor_prior_segment" "cursor_next_segment" That would be 14 new icons! We can cut the list down by removing: "cursor_start" "cursor_end" Those are totally redundant in this scheme, and functionally identical to "rewind to beginning" and "fast-forward to end" That in of itself begs another question. Five edit views, five segments that all end at a different boundary. Fast-forward to end, the cursor out on the main window is at bar 100, but in any edit view, it only goes to the last visible bar. So if I try to insert something, where will it go? Where the edit view in front of me shows its cursor sitting, or somewhere else? So three views, they end at 33, 27 and 15. I'm in the one that ends at 15 and I'm going to insert something with the keyboard. And pow, now all edit views are at bar 15. OK, that functions whether I find I like it or not, so yes, the "cursor_start" and "cursor_end" actions are completely redundant now. Moving on from that, we've already talked about how these have no clear meaning now: "cursor_up_staff" "cursor_down_staff" "cursor_prior_segment" "cursor_next_segment" If the cursor is strictly attached to the transport, then it only has one axis, so there is no "up staff" or "down staff" to it at all. "Next segment" and "previous segment" could have meaning, but they'd almost never have a meaning that made any sense across multiple contexts at the same time. So these turn out to be a very large question mark. Then these ones too: "extend_selection_backward" "extend_selection_forward" "preview_selection" "clear_loop" A selection really is only meaningful at the local level, but the nature of this beast now implies that these actions, like everything else, will have to work globally. So we select to the left in every edit view, and every edit view makes a selection at the same time? If we copy, what are we supposed to be copying anyway? And then there's the matter that selections on the main window are a completely different animal, and there is no way to select less than an entire segment. The "range" mechanism, using the ruler, is the hack around that. It's arguably not a good design, but I feel pretty strongly that changing something like that around is way out of scope for Thorn. Ugh. This is just a great heaping mess, really. -- D. Michael McIntyre ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
