denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] Refactoring


From: Éloi Rivard
Subject: Re: [Denemo-devel] Refactoring
Date: Wed, 6 Nov 2013 14:38:50 +0100

If have commited some changes on the branch command-hash-table. Now in DenemoKeymap commands are stored in a hashmap and no more in a GtkListStore, and bindings are stored in a GList instead of in a GtkListStore. This should reduce a bit the dependency toward Gtk, so it is a first step to make denemo launch without Gtk.

For what I have seen I seems to work. Commands are executed. You can add and remove bindings in command manager etc.

Can you please test and tell me if it is mergeable ?


2013/11/3 Éloi Rivard <address@hidden>
One major thing here is that commands are stored in a gtk_list_store in DenemoKeymap.commands.
Any objection for using a g_hash_table instead ?
It would also improve a bit performance I think.


2013/11/3 Éloi Rivard <address@hidden>
There is a comment on generate_sources about this line :
//define a property "scm" on the action to mean scheme can call the action.


2013/11/3 Éloi Rivard <address@hidden>
Richard, in scheme.h there is a lot of call to g_object_set_data where "scm" field is set to "1" on actions. For example:
  g_object_set_data(G_OBJECT(lookup_action_from_name("CursorLeft")), "scm", (gpointer)1);
This value seem to never be read:

~/dev/denemo [gtk-display|± 2] $ grep -RI g_object_get_data | grep scm
52:src/view.c:9248:  //g_print("event button %d, idx %d for %s recording = %d scm = %d\n", event->button, idx, func_name, Denemo.ScriptRecording,g_object_get_data(G_OBJECT(action), "scm") );
~/dev/denemo [gtk-display|± 2]


This line is commented. Do you know what is the use of those calls ?


2013/11/3 Éloi Rivard <address@hidden>
Your tests sound good. For now I am looking at how to launch denemo without gtk, then I will try to look at GLib testing framework, as it should not add any dependency.
https://developer.gnome.org/glib/stable/glib-Testing.html


2013/11/1 Richard Shann <address@hidden>
On Tue, 2013-10-29 at 17:40 +0100, Éloi Rivard wrote:
> Since you can access Denemo.gui from everywhere in the code, do you
> think it is judicious to get rid of "DenemoGUI * gui" parameters in
> every functions ? Or is it somewhere where you do need this
> parameter ?

The place where I am aware of DenemoGUI * being passed as a parameter is
in creation; so test scripts to

1) Open a file
2) Add Staffs from a file
3) Add Movements from a file

should be in place before trying to do this I think.

There could be other places when switching from one tab to another (that
is when the user has multiple scores open at once - each of these is
represented by a DenemoGUI* structure kept in a list in
DenemoRoot.guis). In such code the current musical score Denemo.gui is
changed to point to another element in Denemo.guis so care would be
needed not to assume that a parameter DenemoGUI *gui referred to the
global stored currently in Denemo.gui.

As I mentioned, it is a good idea, but I think we should have some basic
testing set up first. The actual tests will be quite easy to create (I
can do that easily) but the machinery to run them (create working
directories, store reference files, update reference files in cases
where the regression is desired etc) would be more of a challenge for me
just now. (I did, many years ago, set up an over-ambitious testing
scheme for the actual gui itself, hence the existence of the test
directory - this was much too early, but now is a good time for simple
testing, indeed it is long overdue and would save us a lot of
headaches).

Richard








--
Éloi Rivard - address@hidden
       
« On perd plus à être indécis qu'à se tromper. »



--
Éloi Rivard - address@hidden
       
« On perd plus à être indécis qu'à se tromper. »



--
Éloi Rivard - address@hidden
       
« On perd plus à être indécis qu'à se tromper. »



--
Éloi Rivard - address@hidden
       
« On perd plus à être indécis qu'à se tromper. »



--
Éloi Rivard - address@hidden
       
« On perd plus à être indécis qu'à se tromper. »

reply via email to

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