Re: Re : Re : [Bug-gnubg] Tr : No-gui warnings ?

[Michael Petch]

On 19/08/09 9:35 AM, "Massimiliano Maini" <address@hidden> wrote:

> One strange thing I've found (or that I've never noticed). If you do an "help
> set" 
> in the CLI, you get this:
> 
> and when I start the CLI on it I see this:
> 
> Unknown keyword `annotation'.
> Unknown keyword `message'..
> Unknown keyword `gamelist'.
> Unknown keyword `window'.
> Unknown keyword `theorywindow'.
> Unknown keyword `commandwindow'.
> Unknown keyword `panels'.
> Unknown keyword `geometry'.
> Unknown keyword `geometry'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.
> Unknown keyword `gui'.

First off, the Jun build didn't print these errors as they are done now.
Previous builds printed to stderr, and in June it was modified to print
unknown keywords to stdout.

@@ -1264,10 +1252,7 @@
         break;
 
     if( !pc->sz ) {
-    outputf( _("Unknown keyword `%s'."), pch );
-    output("\n");
-
-    outputx();
+    outputerrf( _("Unknown keyword `%s'.\n"), pch );
     return;
     }

Its curious that stderr output didn't previously go to the console.

> 
> So the CLI version is complaining about commands it is not expecting, and they
> are
> not in the "help set" output.
> On the other hand, it is NOT complaining about commands like "set panelwidth"
> or "set fullscreen", because they are "visible" in CLI (proff by "help set")
> even if they
> make sense only in GUI exe.
> 
> In commands.inc some commands are in #if USE_GTK ...
> 
> Removing all the #if USE_GTK in command.inc would probably solve the warning
> issue,

Removing ifdefs USE_GTK may require you to pull in GTK related functionality
that liekly is built with USE_GTK. Not sure it would be so simple as you
suggest. This code needs cleanup as Jon suggested.

> but not the pfact that savingfrom CLI will lose GUI settings and the fact that
> "help set" in CLI
> will show GUI-only commands.
> 

In the *nix variants (not the Windows versions) you can build a GTK enabled
version of the software and disable the GUI at runtime (with -t option). The
side effect is that it appears as a command line version but supports all
the GUI commands (including loading and saving all the variables). I don't
have a windows environment to do such testing, but I wonder if the code can
be modified on Windows to provide similar functionality. This would be a
serious hack (The CLI would now be dependent on GTK for graphics, yet it
will never display).

I notice that the key section that drives this is in function main()
(gnubg.c). Among other things is:

#ifdef WIN32
    fNoTTY = TRUE;
#endif 

in main(). If someone can experiment, what happens if it is modified to
this:

#ifdef WIN32
    fNoTTY = FALSE;
#endif 

And then build with USE_GTK (And all GTK libraries). Does this work as a
command line build when run from the console (Likely there are changes
elsewhere but maybe it will work)? If it does work then you have a GUI build
without physical GUI, but all the GUI options can be loaded/unloaded from
gnubgautorc and will properly be saved.

And I reiterate this is a hack to keep all the GTK related function active
in a CLI build. I agree with Jon that this has to be really cleaned up /
re-evaluated.

Mike