#298 Horizontally constrained selection move in matrix editor

Maybe
open
nobody
None
1
2013-10-08
2006-10-21
Brunetton
No

Hi all,

I noticed that William requested a similar hint in
2004, but there was no response to him.

I trie in my turn, suggesting to assign a keyboard
modifier to horizontal constrain when move selection.
I'd like to have an answer from the developement
community like
- "we don't want this, this is useless"
or
- "we agree, but it's not our priority for the
moment. Just make it and give a patch"
or
- "ok, this will be included in the next version,
thanks for taking time to participate !"

Thanks

Bruno Duyé

Discussion

  • Chris Cannam
    Chris Cannam
    2006-10-22

    Logged In: YES
    user_id=13489

    I think this would be very useful.

    An alternative would be to use some sort of hysteresis
    effect when dragging, with logic like:

    • don't start dragging until the mouse has moved more
      than a few pixels (say 5) away from its click point

    • when the mouse has moved more than (say) 5 pixels in
      horizontal or vertical direction (whichever direction this
      threshold is crossed in first), start a constrained drag
      in that direction only

    • if the mouse subsequently is found to have moved more
      than a larger number of pixels (say 15) in the other
      direction as well, switch to a free drag in both
      directions.

    If tuned right this sort of thing can work very well,
    providing most of the right behaviour without the user
    really noticing it's doing it at all. The difficulty
    comes when there are common usage idioms that involve very
    small drags, such as the dragging up or down by one
    semitone in the matrix. It might be worth experimenting
    though.

    A more general comment (and lengthy technical digression)
    on the matrix:

    There are probably a dozen usability improvements for the
    matrix that have been talked about or proposed on the
    lists and trackers. A couple of them can be found here:

    https://sourceforge.net/tracker/index.php?func=detail&aid=1540168&group_id=4932&atid=104932

    (note that "1.3" refers to the current 1.4 release, and
    none of those matrix improvements in fact was implemented
    for the release owing to lack of time.)

    I think most of us would agree that the matrix could be
    hugely more enjoyable to use with a few, perhaps small,
    improvements of this kind.

    However, one limiting factor in our enthusiasm for making
    fixes like these is that we also agree that the matrix
    needs a complete rewrite. The Qt QCanvas class that it is
    based on simply isn't up to the job.

    (The idea of the QCanvas is that you can represent objects
    using an abstract coordinate scheme and then map them onto
    the screen using a matrix transform for zooming and the
    like. Unfortunately it only handles integral abstract
    coordinates and cannot represent a line that would appear
    longer than 32K pixels when transformed, even though only
    part of it could be visible at a time. These limitations
    together make it incapable of handling the sort of zoom
    and precision requirements we need for the matrix.)

    The main segment canvas was recently rewritten as a plain
    widget that handles its own drawing and interaction, for
    exactly these reasons, and we always planned to do the
    matrix next. But for various reasons associated with
    developer availability it took nearly a year for the new
    segment canvas to be completed, and we aren't keen to
    spend another year on the matrix (although to be fair, it
    is a lot simpler than the segment canvas). It's also been
    suggested that we simply wait and do nothing until KDE4
    (using Qt4) is out and about, and then when we eventually
    have to port to that, we also switch to the new Qt
    QGraphicsView, which fixes the problems I mentioned above
    with QCanvas. That would take even longer, but might
    avoid some waste.

    In the mean time it almost certainly is worth making
    usability fixes to the current matrix, just because of the
    likely timescales involved. But it does seem a little bit
    pointless to put too much effort into trying to perfect
    the current one, when we know already that it cannot be
    perfected beyond a fairly limited extent.

    All thoughts welcome (particularly if accompanied by
    code).

     
  • Chris Cannam
    Chris Cannam
    2006-12-01

    Logged In: YES
    user_id=13489
    Originator: NO

    To respond to my own aside: I've decided it is worth making a decent
    effort to improve the usability of the current matrix, so I'm
    committing some changes along those lines.

    Haven't actually committed anything that addresses this particular
    feature request yet though.

     
  • Logged In: YES
    user_id=663564
    Originator: NO

    We're sorry, but there is no chance anyone presently on our staff will have time to consider this request. Perhaps you'd like to apply for a job here by presenting us with this request re-expressed in patch form.

     
    • Group: --> Maybe
     
  • It's still a good old idea. I don't use the matrix much, or probably would have been annoyed by this sooner.