Created attachment 85526 [details] [review]
patch 0.125 to download headers from the command line

Created attachment 85679 [details] [review]
patch 0.126 to download headers from command line

Please note bug #424248, in the attachments section, there's a patch that I wrote so that when in --nogui mode, the pan process quits when the work is done and doesn't hang around sleeping forever.

You may find that patch, in combination with this one, to be useful.

Note: The two patches (this one and the one in #424248) do not clash, although they hit the same file, pan.cc.  If you allow the patch program to tolerate the fuzz, things should be ok.

I've checked in a version of this.

When I try out headers:group.name with the --no-gui flag, I get the following error:

Error: --no-gui used without nzb files or news:message-id.

Created attachment 85980 [details] [review]
Fix for --no-gui

Fixes --no-gui problem reported by Jack Cuyler

Thanks Eric.  That takes care of the --no-gui error, but I think there's still something wrong.  pan headers:group.name --no-gui doesn't pull in new headers for me.  Here's the steps I took:

Opened pan normally and searched for a group (without opening it) to make sure there were no unread headers.

Closed pan.

pan headers:alt.fan.spawn --no-gui

When that completed, I opened pan again normally and searched for alt.fan.spawn.  Pan showed 10 new headers in the group list "alt.fan.spawn (10)" but when I double clicked on the group, the "10" disappeared and the "Get Headers" dialog box popped up.  When I selected "Get all headers", sure enough, 10 new headers were downloaded.  But that defeates the purpose, I think, to have to download the headers again.

I looks like something is still missing.  I wish I could help more.

the patch in comment #6 is checked in, but I couldn't reproduce the error Jack's describing.

Upon further testing, it looks like the problem I described is intermittent.  Some groups work perfectly, while others need to be re-downloaded.  Luckily, it looks like those that need to be re-downloaded are rather small.

One more --no-gui bug.  Pan is attempting to make a connection to the user's $DISPLAY even when the --no-gui or --help flags are used:

Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key

(pan:22531): Gtk-WARNING **: cannot open display:


If --no-gui or --help is in the arguments, there should be no reason to connect to the X server.

Line 214 in pan.cc calls gtk_init().  I fired up the debugger and it's this call that implicitly has gtk contact the X server.

I completely agree that nothing should be talking to the X server in the --no-gui case.

I am going to submit a patch to conditionally call gtk_init() later in the program, only after parsing args and deciding we need/don't need a gui..

Created attachment 86213 [details] [review]
Fix to make gtk not contact X server if and only if --no-gui

Created against svn rev 226 which I *think* takes into account the other patches up here...

Created attachment 86216 [details] [review]
Fix to make gtk not contact X server if -v or -h

This modifies Calin's patch in comment #12 to prevent x server contact if the -h, --help or --version options, in addition to --no-gui, are included in the command line.

Well, the modifications to set the boolean 'gui = false' in the --version and -h/--help cases are superfluous, but harmless. 

In both those usages pan is exited right away (return 0), so setting 'gui = false' is not really terribly useful.

Already having moved the gtk_init() call after argument parsing is enough to fix the -h and --version cases too.

Strange.  I was still getting the error when I tried it.  I guess I was still using the old binary.  The patch in Comment #13 can be ignored.  My bad.  Thanks Calin!

Comment #12's patch is now in svn 227.

Thanks to both of you for looking into this. =)