On Fri, 2013-06-21 at 14:15 +0200, Éloi Rivard wrote: > There is a lot of unused functions in main.c : first_time_user, > uses_default_commandset, segdialog, remove_pid_file, denemo_client, > check_for_position, denemo_signal_handler > > Is there any reason to keep them ?
I think not - mostly they are junk, some we might want to come back to (new users, how to handle additional command sets) but I don't think there is anything precious in there. Richard > > > > 2013/6/21 Éloi Rivard <[email protected]> > > For readability and coherence, I think program options parsing > should not be done in view.c. > > 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
