denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Button missing


From: Richard Shann
Subject: Re: [Denemo-devel] Button missing
Date: Mon, 29 Oct 2012 14:34:11 +0000

On Mon, 2012-10-29 at 11:38 +0100, Andreas Schneider wrote:
> Am 29.10.2012 10:19, schrieb Richard Shann:
> > On Mon, 2012-10-29 at 09:11 +0100, Andreas Schneider wrote:
> >> in some informational dialogs, e.g. "Your pdf file has now been
> >> created", the Ok button has disappeared. Maybe this is a sideeffect of
> >> internationalisation?
> > This was a result of my starting to use this dialog in a new way; the
> > button could be re-instated, but it needs to give a "delete-event"
> > signal rather than a "destroy" signal, or some such subtlety. I thought
> > it might be better to drop it as it is redundant, there is already a
> > button for killing the window provided by the window manager.
> > (For the new way the dialog is used, select - in the print preview
> > window - a note with a beam-start and choose the beam-moving option from
> > the menu).
> You're right, but what the standard user is used to is that a message 
> box has a button. In my opinion, the standard user will be irritated by 
> such a window without a button. Maybe he'll think something's wrong (in 
> the sense that the program might crash soon).
Good points.
There may be an even more pressing reason to restore the button - I
think you can close such a dialog without leaving the keyboard by
pressing Return. (If you can't you should be able to). I'll look into
getting the right functionality on the button.

> 
> >> 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?

Richard





reply via email to

[Prev in Thread] Current Thread [Next in Thread]