In view.c, function load_scheme_init, what is the use of Denemo.gui->si->undo_guard++; and Denemo.gui->si->undo_guard--; ?
2013/6/21 Richard Shann <[email protected]> > On Fri, 2013-06-21 at 13:52 +0200, Éloi Rivard wrote: > > > > For readability and coherence, I think program options parsing should > > not be done in view.c. > > this arose when introducing scheme, I tried to keep the scheme headers > to just one file, anticipating that they could destabilize denemo's code > - we had an example of this recently, when Jeremiah introduce a foreign > header file (sffile.h) which defined things already defined in Denemo. > > However, view.c is monstrously overloaded, (my fault :( ) > > Richard > > > > > It seems that scm_with_guile() exists with 1.8 : > > > https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Guile-Initialization-Functions.html#Guile-Initialization-Functions > > > > > > > > 2013/6/21 Richard Shann <[email protected]> > > On Fri, 2013-06-21 at 13:42 +0200, Éloi Rivard wrote: > > > Is there a reason to use scm_boot_guile() instead of > > scm_with_guile() > > > in main ? > > > > > > I am not sure all these variants existed when I got guile > > working from > > inside C. Indeed, I am not sure which ones are available in > > guile 1.8. > > Do you see some advantage to using something different? > > > > Richard > > > > > > > > > > > > > > > > > > 2013/6/4 Richard Shann <[email protected]> > > > I've just tested this out and it seems to be working > > fine :) > > > > > > Richard > > > > > > > > > On Tue, 2013-06-04 at 16:57 +0200, Éloi Rivard > > wrote: > > > > On the split branch, evince is now enable by > > default, but no > > > more > > > > mandatory. So now I can compile denemo with gtk2 > > and make > > > some larger > > > > tests. > > > > > > > > > > > > > > > > 2013/6/4 Éloi Rivard <[email protected]> > > > > I pushed the branch split where the evince > > part of > > > print.c is > > > > now in printview.c . Could you tell me if > > it is good > > > for you ? > > > > > > > > > > > > > > > > 2013/6/4 Richard Shann > > <[email protected]> > > > > On Tue, 2013-06-04 at 13:23 +0200, > > Éloi > > > Rivard wrote: > > > > > > > > > > 2013/6/4 Richard Shann > > > <[email protected]> > > > > > On Tue, 2013-06-04 at > > 11:40 +0200, > > > Éloi > > > > Rivard wrote: > > > > > > > > > > > Tools are now built > > when you run > > > make. > > > > > > > > > > > > > > > I have run my usual make > > (in a > > > parallel > > > > directory to the > > > > > source > > > > > directory) and it ran > > ok, > > > generating the > > > > tools in a parallel > > > > > directory > > > > > to the tools directory > > containing > > > the source > > > > code of the > > > > > tools. > > > > > > > > > > > > > > > > > What do you think of > > > automatically > > > > call ./generate_source > > > > > > and ./extract_scheme > > before > > > compiling the > > > > src directory ? > > > > > > > > > > > > > > > This has to be done in > > the source > > > directory > > > > not the build > > > > > directory > > > > > though. > > > > > You mean in order to make > > extract_scheme > > > work ? > > > > > > > > and generate_source, they have to > > be > > > executed at > > > > particular places in > > > > the source tree, not a build > > directory. > > > > > > > > > > > > > > > How would you determine > > the > > > dependencies? > > > > > autotools are very convenient > > for this. It > > > is easy > > > > to set up > > > > > dependencies between targets by > > playing > > > with > > > > Makefile.am files > > > > > > > > > > > > In this case a new *.xml file > > somewhere in > > > the > > > > hierarchy below menus > > > > should trigger a re-run of > > extract_scheme. > > > It will be > > > > good if it can be > > > > done. > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > É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. » > > > > > > > > > > > > > > > > > -- > > É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
