Re: [Denemo-devel] preview window (was: Button missing)

[Andreas Schneider]

Am 29.10.2012 15:34, schrieb Richard Shann:
> > > > Btw, why is the preview window always on top?
> > > It is only on top if you have continuous update set on it. If you change
> > > that to manual it will stop being on top, and when you next start it
> > > that will be true too.
> > > > On my laptop that is not
> > > > very useful; I always close the preview to be able to see all the notes
> > > > in the main window which are hidden behind the preview window otherwise
> > > > -- I don't have enough space on the screen to have both windows beside
> > > > one another. Even when having both windows beside one another, I don't
> > > > see a reason for the preview to be always on top.
> > > If you are continuously typesetting it makes no sense if you can't see
> > > the typeset. But also I am feeling my way towards a different way of
> > > looking at Denemo - seeing it as a program with a music-entry window and
> > > a printed-output window. In the past it looked at first glance like the
> > > music-entry window, which we called the display-window, was what Denemo
> > > created, then you would try to run LilyPond and discover that you hadn't
> > > closed a slur or had some other small error resulting in a bad pdf,
> > > which you didn't know where to look to fix.
> > > If Denemo is useful on small screens, then we could detect the screen
> > > size and default to some different arrangement. The GTK library has nice
> > > routines for seeing how many and what size monitors a user has.
> >
> > As soon as the cursor moves behind the preview window, you don't see
> > what you're editing.
> >   Then you have to do some extra scrolling, i.e. grab
> > the mouse, scroll such that you see the cursor again, and then go back
> > to the keyboard (or alternatively, if you're not too close to the end of
> > the piece, you can navigate further right and back, until the program
> > autoscrolls such that you can see the part you want to edit). That's
> > annoying. I can't imagine a situation where you do not want to see what
> > you're editing.
> In the past this has been absolutely the case, but you can now drag
> beams and slurs and insert page and line breaks without leaving the
> print preview window. And you *can* even type notes there (the key
> presses are actually going to the entry window) and watch them appear in
> the print view window. It would be too slow on many machines, (or with a
> lot of music being continuously typeset), and there is no "cursor"
> showing in the print-view window to show where you are entering music,
> so it feels quite unnerving, but it may be the shape of things to come.

> >   And it always comes back to that when the preview
> > windows is always on top.
> Is it a candidate for a special button to pin it on top, or does turning
> Continuous off satisfactorily resolve that for the user? Or some other
> idea?

A special button to pin it on top would be a good solution. Although I 
still don't see a use for it. If I want to input music while only 
looking at the preview, I can make the preview the active window. For 
that purpose, it would make sense to be able to insert music while the 
preview window has the focus. But in my opinion, it makes no sense when 
I have to close the preview (or move it half out of the screen) to be 
able to reach the menu / command I need, or see where my next input 
would be. On the other hand, the continuous preview is still usefull if 
one only sees a part of the window (e.g. the part one is working at).

Andreas