denemo-devel
[Top][All Lists]
Advanced

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

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


From: Jean-René Reinhard
Subject: Re: [Denemo-devel] newview() and the GtkActions it creates
Date: Wed, 9 Jul 2008 10:32:27 +0200
User-agent: Mutt/1.5.11+cvs20060126

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.

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

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

Jean-René

> 
> Richard
> 
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel




reply via email to

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