Debian 7 is out since May 4th, and it carries Gnome 3.4 by default :) http://packages.debian.org/en/wheezy/gnome-core
2013/5/15 Jeremiah Benham <[email protected]> > > On May 15, 2013 3:52 AM, "Éloi Rivard" <[email protected]> wrote: > > > > What is the support policy with denemo ? > > In particular about gtk2. Is it planned to be long-term supported, is it > deprecated, will it be abandoned at a particular version ? > > We need to wait until I can fully suport gtk3 in gub and gtk3 needs to be > default in debian stable before we can consider it I think. > > Jeremiah > > > A lot of solution to the gtk3 deprecation warnings are not valid in > gtk2, and playing with ifdefs GTK_MAJOR_VERSION seems boring :) and won't > make denemo a lot more stable. But still, all those warnings are polluting, > and may drown interesting information. > > > > > > > > 2013/5/15 Éloi Rivard <[email protected]> > >> > >> > >> > >> > >> 2013/5/14 Richard Shann <[email protected]> > >>> > >>> On Tue, 2013-05-14 at 16:15 +0200, Éloi Rivard wrote: > >>> > I pushed a first pass on the master branch. > >>> I had to remove the private header file included in exportmidi.c as it > >>> would not compile (clearly, we should not be using anything that is > >>> private to libsmf anyway - what prompted you to include this?) > >> > >> I can't remember, but I suppose it was some implicit declaration. > >>> > >>> Also, it would not compile for GTK2 without a definition in bookmarks.c > >>> which I have added. > >>> I haven't had time to look at the code, but a first quick play with the > >>> program didn't throw up any big problem. > >>> > >>> > >>> > I removed most of unused variable, unused static functions (not in > >>> > generated files), implicit function declaration, untyped functions > and > >>> > vars warnings, plus some miscellaneous ones. > >>> > > >>> > I didn't touched most of warnings related to gtk deprecation, pointer > >>> > casting (gpoint to int, int to gpointer), and macros, for the moment. > >>> > > >>> > I commented unused functions, and tagged theme with UNUSED. Could you > >>> > grep this tag and check if function may be used later, or delete > >>> > them ? > >>> Yes, perhaps we should put this in the bug tracker. > >> > >> This is #38991 > >>> > >>> > > >>> > It would be great to be able to compile with -Werror one day for more > >>> > safety :) > >>> > > >>> > > >>> > Another thing, view.c is 11 000 lines long! It is almost 10% of the > >>> > src directory :) It would be great to split it in several other > files. > >>> > I can take a look, but if would probably be better if you start this, > >>> > as I don't know the mechanisms behind those 11k lines. What do you > >>> > think? > >>> > >>> It has been on my conscience for several years. I can thing of three > >>> major sections that should be separate: > >>> > >>> 1) All the scheme related code, especially everything for generating > >>> scheme primitives. > >>> > >>> 2) All the code related to music snippets, internally usually called > >>> rhythms. > >>> > >>> 3) The code relating to creating the main window (which is where the > >>> name view.c came from). > >>> > >>> But there are certainly others. Code for handling clicking on menus and > >>> more. > >>> > >>> I have always been daunted by this task. As you have found trying to > >>> refactor the keymap code it is a high risk occupation. I am not sure if > >>> I can honestly say that I have the courage to tackle it. Perhaps if we > >>> created a map of the file, that would be a start... > >>> > >> You mean separate functions in the categories you proposed ? > >>> > >>> Richard > >>> > >>> > >>> > > >>> > 2013/5/14 Richard Shann <[email protected]> > >>> > On Tue, 2013-05-14 at 11:47 +0200, Éloi Rivard wrote: > >>> > > Hi, > >>> > > > >>> > > Could you have a look at scheme_create_timebase function in > >>> > view.c. > >>> > > The "if" statement emits a warnings, but I don't know how > to > >>> > fix it. > >>> > > > >>> > > Should it be a double equals operator, or the affectation > >>> > before the > >>> > > "if" statement ? > >>> > > >>> > > >>> > Good work - it is actually an ! that is missing. I use the > >>> > idiom > >>> > if((a=b)) ... whenever I am tempted to assign and test in one > >>> > go. I have > >>> > fixed this line in git master, thanks for the detective work. > >>> > > >>> > Richard > >>> > > >>> > > >>> > > > >>> > > -- > >>> > > Éloi Rivard - [email protected] > >>> > > > >>> > > « On perd plus à être indécis qu'à se tromper. » > >>> > > > >>> > > >>> > > _______________________________________________ > >>> > > Denemo-devel mailing list > >>> > > [email protected] > >>> > > https://lists.gnu.org/mailman/listinfo/denemo-devel > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Éloi Rivard - [email protected] > >>> > > >>> > « On perd plus à être indécis qu'à se tromper. » > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> Éloi Rivard - [email protected] > >> > >> « On perd plus à être indécis qu'à se tromper. » > > > > > > > > > > -- > > Éloi Rivard - [email protected] > > > > « On perd plus à être indécis qu'à se tromper. » > > > > _______________________________________________ > > Denemo-devel mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/denemo-devel > > > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
