From: Tim E. R. <ter...@ro...> - 2011-07-03 21:43:03
|
On July 3, 2011 05:24:51 am Florian Jung wrote: > Am 02.07.2011 21:54, schrieb Tim E. Real: > > Hi Florian. Sorry for late reply. I'm taking a look at it. > > > > Turn out my jagged edge idea, while pleasing, was not good. > > The edge needs to be straight so users can clearly see the > > part boundary. If the edge was jagged, it would bleed into > > the left edge of a following part butt up against it. And if > > I make the jagged drawing only inside the part, it may > > obscure some note slivers near the part end. > > > > So I came up with a plan, working it out now... > > If it works I think it would be pleasing. > > > > Well, I don't want to say too much and jinx myself, so let's see what I > > can come up with. It involves a radical change to how part borders are > > drawn. Anyway it's an important task for other reasons, to fix existing > > border drawing issues, so I'd like to proceed with attempts. > > i'd have a less work-intensive idea for indicating that the part > contains hidden notes: > simply don't draw the right edge of the rectangle enclosing the part. > this will still show the part's end properly, because inside of that > rectangle, there is color, so we still see where it ends. I considered that too. An nice 'open-ended' kind of thing. But the existing problem I mentioned above is that when another part is drawn after this part, its solid left border will take up that space. Actually, it has to - the next part's solid left border needs to be drawn. Its an issue for clones as well. It is possible for a clone's dashed borders to be completely obscured by surrounding parts' solid borders if those parts are drawn after the clone is drawn. So my plan involves prioritizing the border segments so they are drawn in the right sequence to make important borders (or lack of them in this case) show up in front of all other regular borders. Of course, the problem there is the reverse - then parts with solid borders can be obscured by clone borders. Ugh. It's a tough problem. Yes, I considered making all borders semi-transparent, which is a very easy solution, but unfortunately borders need to be completely opaque because we don't want confusing different shades of black portions of border segments. Well, in the end, I may be forced to go with that solution! I'll see.. For parts with hidden notes, a special sparse border segment with, say three dots, say coloured white, will be drawn. Notice that our borders are two pixels wide. That gives me some leeway to draw a single-pixel-wide three dot segment up against a single-pixel-wide solid border of another part. Getting those borders correct is important visually when for example the horizontal magnification is so low that a short part only shows up as a couple of border lines and you can't see anything inside the part. Now, beyond that, when enough of the part's interior is visible, my plan is to draw a pleasing unobtrusive overlay of an 'arrow', or a 'chevron', or something, semi-transparent so the note slivers can be seen underneath it. A nice secondary visual effect. > > what do you (all) think about my treatment of clones in experimental (of > course, it's not quite done yet, but most parts already behave as i want > them to). > > the basic idea is that all same-length-clones get resized when one clone > is resized. with a special key, you can temporarily turn off that > behaviour. (theoretically, a config option would be possible which > inverts this to "no key -> old muse behaviour, with key -> new behaviour") > auto-expanding in the editors only expands, if a part doesn't already > contain hidden notes (if it does, the user probably wanted thjem to stay > hidden, so don't expand and reveal them again!) > shrinking a non-clone does NOT erase the notes which are past the part's > end now Sounds interesting, I'll check it out. Florian there's a bad bug that has only recently crept into the current trunk. Can you check it out and verify? Not sure how, or from where, it got in there. When you grab onto a part and make like you are going to move it, (the four-way mouse cursor appears and the special 'moving' part is drawn) but don't actually move it, then the part completely disappears! I also noticed a problem copying and pasting notes - it refused to paste more than a few of the copied notes. So far observed only once. It apparently happened after loading a song when another was already loaded. So it may be something pre-existing, possibly with my song-clearing code. I'll try to nail it down. Tim. > > > flo > |