I do very much try to make things easy to customize - so if there are any default settings that any users do not like, I'd happily consider a feature request to make them configurable. But for those that are already configurable, it's not worth pondering which defaults would be best.
For the pacnew file I'll have to think about that. It would be trivial to do, but it seems to give the wrong idea. The /usr/share/slider/config really shouldn't be edited. It should be copied to $XDG_CONFIG_HOME. This will be clarified in the much-needed and upcoming man page. I am considering moving it from /usr/share to /etc/xdg/slider/config which would seem to fit this intended use better. I do need to check up on which path is the current best practice as I've seen different standards and I'm not sure which ones are older/newer and/or more or less adhered to.
]]>2) I would swap j and k in the default config. k should be forward and j backwards, not as per your previous post
j and k come from the vi keybindings where j is down and k is up. The thought process is like this: next = down = j, and prev = up = k
An alternative would be prev = left = h and next = right = l
PS: your history implementation makes sense to me.
EDIT: yes I can send you the PDF if you want. I have tested with Okular which I believe uses Poppler and it works.
]]>As for the bug, is this a pdf you can share so I can do some testing? Also, can you test it with other poppler-based tools. Slider relies on the poppler-glib library for rendering the pdf - so if poppler can't do it, neither can slider. If other poppler tools handle that well, then this is a slider bug, but if they don't, then it is a poppler bug.
EDIT: New HISTORY implementation:
I just pushed a history implementation. It needs a lot of testing yet, but it seems to work so far. I have not added bindings to the default config yet as I want it to get some more testing first. But if you'd like to try it out and provide feedback, just add keybindings for any of the 6 new commands: history back, history forward, history start, history end, history push, history clear. Only the first four of these would likely be of any use for bindings, the other two are used internally - though I prefer transparency where possible to allow users to come up with interesting uses I might not have thought of. 'history push' is used internally every time there is any sort of page change, so the new current page is pushed on to a stack of page numbers.
The back and forward should be self-explanatory - start and end may also be pretty obvious in general, but there are some interesting specifics: start goes to the first page in the history stack which would generally be the first page of the pdf, but this could be changed with a call to 'history clear' which clears/resets the history; end goes to the last page in the history stack, keep in mind that this will depend on how you've been moving around. For example if you move normally from pages 0 to 3, then follow a jump link to page 7 then move forward normally to page 8, the history stack will be "0 1 2 3 7 (8)" where 8 is bracketed as the current position in history. If you then use "history back" twice the same history stack will be "0 1 2 (3) 7 8". If you then use "history forward" or "next" you will get different results: history forward will move you to page 7 and the history stack will be "0 1 2 3 (7) 8" so you could still do another 'history forward'. If instead you use "next" this will overwrite any trailing history and move you to page 4 with a history stack "0 1 2 3 (4)": the previous visit to pages 7 and 8 will no longer be in the history.
This is a very verbose description - but I think this is the standard behavior expected from a history buffer. It is the same logic used by every web browser I've used. In short, if you go back many steps, you can only retrace forward again as long as you don't make any different new steps.
Here's what I've added to my config to test out history:
*.Bind.15.Key: j
*.Bind.15.None: history forward
*.Bind.15.Shift: history end
*.Bind.16.Key: k
*.Bind.16.None: history back
*.Bind.16.Shift: history start
Also found a kinda bug: I have a PDF which contains another PDF which has °C symbol (\textcelcius in LaTeX). Other PDF readers see the °C, slider does not.
]]>OdinEidolon wrote:Just wanted to pop by to say that this program is fantastic. Thanks Trilby for creating and maintaining it so well.
Thanks for the appreciation - and more so for the critiques. Software can only improve when issues are reported. Slider is over due for some attention, and these points will help direct the updates where most needed. I should be able to address these all soon. For now some thoughts on each:
1 + 2) Yes, there was a man page for version 1+2, but version 3 was a complete rewrite with drastic changes, so the previous man page is no longer accurate. I do need to write a new one.
3) Thanks - that's just in the comments though right?
4) Good idea - I don't use jump links much so it didn't occur to me. That should be relatively easy to add
5) I don't know much about international keyboards or settings. Slider passes the string provided in the config file through the Xlib XStringToKeysym function. You should be able to use xev (from xorg-xev) to get the strings associated with any key. For square brackets it would be bracketleft and bracketright, for curly braces it would be braceleft and braceright (at least on my en_US system). Xev should be the complete reference: see the third line of xev output for any key press, the string is in the parentheses after the coma.
6) Ah, yes, that is a bug. For a temporary work around you can hit "esc" then "enter" to end the dot 'mode' then redraw the current page.
Thank you.
As for #3, yes it's in the comments only.
#5, thanks for the hints.
Keep up the good work!
]]>Just wanted to pop by to say that this program is fantastic. Thanks Trilby for creating and maintaining it so well.
Thanks for the appreciation - and more so for the critiques. Software can only improve when issues are reported. Slider is over due for some attention, and these points will help direct the updates where most needed. I should be able to address these all soon. For now some thoughts on each:
1 + 2) Yes, there was a man page for version 1+2, but version 3 was a complete rewrite with drastic changes, so the previous man page is no longer accurate. I do need to write a new one.
3) Thanks - that's just in the comments though right?
4) Good idea - I don't use jump links much so it didn't occur to me. That should be relatively easy to add
5) I don't know much about international keyboards or settings. Slider passes the string provided in the config file through the Xlib XStringToKeysym function. You should be able to use xev (from xorg-xev) to get the strings associated with any key. For square brackets it would be bracketleft and bracketright, for curly braces it would be braceleft and braceright (at least on my en_US system). Xev should be the complete reference: see the third line of xev output for any key press, the string is in the parentheses after the coma.
6) Ah, yes, that is a bug. For a temporary work around you can hit "esc" then "enter" to end the dot 'mode' then redraw the current page.
]]>EDIT: figured out some constructive criticism could be appreciated.
1) Config options are a bit too hidden. Maybe pop out a message in the terminal (both on installation and opening slider?) to point to the config file(s)?
2) Config files refers to a man which is not found on my system (but I see on github that it's there)
3) Config file typo: 1 - left button, 2 - left button, 3 - right button -> 1 - left button, 2 - central button, 3 - right button
4) I'm missing a very vital "back" command, which is very useful when navigating links inside the pdf
5) What key string is bracket{left,right}[OK, answered to that myself, my bad I don't have an US keyboard]? Can you point me to a resource stating all the standard key strings (also for non-US keyboards characters)?
6) When you want to use the "Dot" as a pointer, it appears to be no way you can cancel the dot without pinning it to the page, am I wrong?
Those are the symptoms I was seeing as well. I traced it to switching from an override_redirect window (which is ignored by window managers) to using a normal window and using a NET_WM signal to tell the WM to make it fullscreen.
Thanks Trilby, I will test it as I get to my second monitor in a few days... (I use dwm.)
]]>EDIT: if there are other formats that I should consider, feel free to let me know - but it's not particularly likely. Relatives of pdf (e.g. PS) could be doable, but I'm not sure if that'd serve much purpose.
]]>accepted as primary presentation tool
btw: any other formats supported? not that it's THAT important ...
As I only occasionally get to test this on a 'multihead' setup, I didn't realize that most WMs will not place the fullscreen window on the monitor I expected them to. I just pushed a revision that will do this in two steps: the presentation window is first mapped as a normal window on the correct screen/video output, then it is toggled into fullscreen. This is essentially instantaneous, and should not be noticable.
So far I've only tested this new code in openbox (where it works as intended) and in alopex (my wm) where I discovered I totally botched multi-head managing in alopex too. So now I'm patching up both projects.
]]>