Re: [Denemo-devel] newview() and the GtkActions it creates

[Richard Shann]

On Wed, 2008-07-09 at 10:32 +0200, Jean-René Reinhard wrote:
> On Sat, Jul 05, 2008 at 04:21:32PM +0100, Richard Shann wrote:
> > 
> > I wonder whether it is sane, creating a new set of actions for each New
> > Window (i.e. each invocation of newview() which lets you edit a new
> > musical score in a separate window).
> > I suspect this was hacked in a long time ago, perhaps in different
> > circumstances...
> 
> I left it as is because for Toggle action and Radio action I think we want 
> this
> behaviour. For exemple, it may be relevant to have a window in edit mode and 
> another in insert mode. Since I think we want this I kept separate actions 
> for all the windows.
> 
This is a very good point, one which I hadn't thought about when I sent
the email. However, on switching windows we can set the toggles/radios
to the values appropriate to the window that has the focus. At least I
hope so!

> > The only useful difference between the actions is the parameter (a
> > DenemoGUI*) that is passed to the callback of the action. This parameter
> > is just the DenemoGUI* that newview() creates.
> > We don't want to be defining different keybindings on different windows
> > or anything like that. There must surely be an easier way of
> > establishing which window triggered the action, and hence which musical
> > score should be worked on.
> 
> There is, and I started adapting the code base before realizing that keeping
> separate actions is relevant. By the way, it may require to adapt every 
> callback
> function, which is a huge work and should in any case not be started just 
> before
> a release.

Yes it was a huge work - as I say in my later email, I had an unusually
good amount of time to spend on this over the weekend, and I have
something which is now working with a single set of actions. Each
DenemoGUI* has a page in a GtkNotebook. It has a few problems to do with
using notebook pages rather than toplevel windows, but I think it will
have been worth it. And I am still working on setting the toggles/radio
actions - the DenemoGUI does not currently have a flag set when the
LilyPond window is open/closed, unlike the modes, which is a nuisance
(it gets confusing if you have two LilyPond windows visible at once as
it is not obvious which belongs to which DenemoGUI. By default I am
intending to minimize the one not in use - which would allow opening up
for cut and paste; the alternative would be to page the LilyPond texts
in a GtkNotebook).
 
> and should in any case not be started just before a release.

This work is not intended for this release, which is ready apart from
those two accelerators and any showstoppers that might show during the
code freeze. (In the past we just released when no-one had reported any
showstopper for a few days, since there were know coredumps in the
release. There still is at least one known coredump in the present
release, though its a bit obscure, so perhaps a week of code freeze
might be good?)
What I have done is to make a branch and do all the new work there. I
did wonder if I could put this up on a branch in savannah git, so as to
feel secure about the backup, but I am a bit nervous about messing up
the git repository just before a release. 

> 
> > Are there any circumstances in which you might be working in two windows
> > at once (e.g. The callback for scrolling the music while doing midi
> > playback, or lokking into the future, a timer-operated callback
> > announcing that LilyPond had finished)? Can't we always pass the
> > relevant DenemoGUI* when we set such things up?
> 
> For the time being, the relevant GUI is passed when the action is registered 
> to
> the action group. When the action is later activated, it nows it's GUI. The
> other solution, resolving the active GUI during the callback is also possible,
> but needs to be done in every callback.

Right, that is what I have done, at the risk of some repetitive strain
injury :-)

Richard