Little GUI for PDFPC

[rastersoft]

I created a little Graphical User Interface for PDFPC. It only supports the most basic options, but it should be sufficient for the average user. Other options can still be passed through the command line.

[davvil]

Thanks for the pull request!

First impression is good, but it seems you deactivated the command line options. As I see it the gui should appear only if no file is specified in the command line. If it is, then the presentation should start. I didn't have time to look into the code, probably it's simple to do this.

[rastersoft]

Not really: all the command line options are honored, and modifies the GUI widgets. I did it that way because it could be interesting to link it to the .pdf extension, and allow to launch PDFPC just by double-clicking a PDF file (or with "Open with..." option), and still be able to set the options. Anyway, is possible to add another command line option (like -r, for "run") that launches the presentation directly, without showing the GUI.

[rastersoft]

I added two command line options to regain full command-line operation:

-r forces PDFpc to start the presentation directly, without showing the GUI

-n is the opposite of -s; it forces to NOT switch the screens. This is needed because the -s option is remembered between GUI launches, so if in the previous launch with GUI, the user unmarked the Switch screens option, it would be able to select it from command line with -s, and now, with this option, if in the previous launch with GUI the user marked the Switch screens option, the user can choose to not switch them. In case of no specifying -s nor -n, the last option used from the GUI will be used.

[rastersoft]

By the way, I also added the option of storing the pdfpcrc config file in $HOME/.config/pdfpc, which is more compliant with current standards.

[rastersoft]

This should be the last change to the GUI, so this should be the final patch.

[davvil]

I hadn't noticed that the GUI is initialized with the pdf file if given in the command line. My bad.

I'm busy these days, so I cannot invest as many time as I would like. But here some comments:

• make install complains with

    CMake Error at po/cmake_install.cmake:36 (FILE):
      file INSTALL cannot find "/home/david/src/pdfpc/po/es.mo".
    Call Stack (most recent call first):
      cmake_install.cmake:41 (INCLUDE)

Forgot to add one file?

• It seems you remember some settings in ~/.config/pdfpd/pdfpc.cfg (BTW typo in pdfpd ;-)), but some things, like duration, are more suited on a per-presentation basis. These are stored in the .pdfpc files in the same dir as the original pdf file. We should look where we store each thing, and the gui should honor the .pdfpc settings for each file.
• It would be nice to be able to choose between duration or end time (option -e) in the gui
• I would also add a config option in ~/.pdfpcrc to bypass the gui completely (I'm a command-line guy ;-)), but I find it good that the default is to show it. It will be probably more user friendly this way.
• Probably the location of the .ui files should be parametrized via the variables defined in paths.{in,vala}
• Github reports that it cannot be automatically merged with the current head. I expect this is probably due to the new version number (3.1.1), so it should be easy to resolve.

The one thing that you should definitely take care of is the missing file. For the other issues feel free to address them if you want. Else I will do it (but certainly not this week!)

[rastersoft]

Ops... my fault. The .mo files are generated from the .po files by the script "update_mo_files.sh". I want to add to CMAKE the ability to update the MO files from the PO files, but I'm running out of time this week :(

I agree in everything else. As soon as I have some spare time I'll address them.

About the merge, I'll try to apply my changes to your current HEAD, to allow a direct merge. Again, as soon as I have some spare time.

Thanks!!!!!

[rastersoft]

By the way... I see you are a fan of Mortadelo y Filemón :)

[rastersoft]

Now you should be able to do the merge.

[rastersoft]

By the way, if you add the -r parameter, you will skip the GUI

[rastersoft]

Well, I think I have added all the options you commented.

[rastersoft]

Sorry, I forgot this last commit.

[davvil]

Hi, just a quick note: I haven't forgotten about this. I hope to merge it soon.

[rschroll]

A few comments from the peanut gallery: I'm a big CLI fan, so this is obviously not for me. But I do want to ensure that the CLI experience isn't messed up. With that in mind....

There should be a switch to enable the GUI, not to disable it. That way, you can add the flag the one time you set up your desktop environment or file manager to launch pdfpc, and not every time you wish to run it from the command line.

Previous switch use shouldn't be magically remembered (the -n/-s issue). If we let the user make an rc file to override the default switches, that's fine. But it's very surprising to have that happen uncommanded with command line use. The result here is that either the GUI doesn't store settings automatically, or that pdfpc should only store settings automatically when using the GUI.

Together, these make me wonder if the GUI should really be part of the main binary. Why not have a second program, whose purpose is just to launch a little GUI, load saved preferences, and then launch the main pdfpc binary with appropriate flags?

[davvil]

I'm also a big advocate of CLI, but I think a GUI would widen the audience for pdfpc. My current plan, when I finally get a free afternoon to look at this in detail, is to show the gui if no file was specified in the command line, or if a special flag is given (e.g. useful if you want to adapt some parameters). In this way, the CLI way of working is unaltered, but pdfpc is easier to use.

The GUI should honor the config files (both global and per-file) and load and store the appropriate options. I find for the most part automatically remembering the options is ok, if the switch option is clicked in the gui, it can write it the in ~/.pdfpcrc. The combo -n/-s doesn't seem so appropriate, a checkbox in the gui would be more consistent.

[Beuh]

I second rscholl on this one : most CLI programs have a second binary, distinct from the first one, to handle GUI. For instance, git and gitgui. It is a standard way of doing the things. Why not have a gpdfpc program that has a GUI and launches pdfpc with the appropriate flags ?

This has the advantage to separate the problems and not to create new ones (like the -r flag)