Re: [zathura] pwmt bug tracker
On 2016-12-29 00:59:40, sivmu wrote: > Hello, > > just wanted to say that the bugtracker at https://bugs.pwmt.org/ is > broken, in case this has not been noticed. It's a known issue with the hoster. > PS: > Please adopt zathura-pdf-mupdf to use the new Mupdf 1.10 API. This should be fixed in the develop branch already. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Zathura can not open valid PDF file
On 2016-07-27 14:05:47, XVilka Haos of System wrote: > Hello! > Any decision on this? > I'd suggest fallback to search PDF signature at any offset, if > libmagic failed, since the standard allows that. > Kind regards, > XVilka. If those are valid PDF files, then libmagic should detect them correctly. Cheers (Sorry for the delay.) -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 1/1] update API for mupdf 1.9
On 2016-05-13 12:50:18, Leonardo Taccari wrote: > Hello Sebastian, > > Sebastian Ramacher writes: > > [...] > > Could you send an updated patch against zathura-pdf-mupdf's develop branch? > > Ideally something easily git am-able. > Sure! I'll attach the patch in this mail (please let me know if I missed > something or if the format isn't good). Thank you, applied. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 1/1] update API for mupdf 1.9
Hello Leonardo
On 2016-05-13 11:37:21, Leonardo Taccari wrote:
> Hello Christian!
>
> Christian Hesse writes:
> > [...]
> > --- a/document.c
> > +++ b/document.c
> > @@ -109,12 +109,12 @@ pdf_document_save_as(zathura_document_t* document,
> > mupdf_document_t*
> >}
> >
> >fz_try (mupdf_document->ctx) {
> > -/* fz_write_document claims to accepts NULL as third argument but
> > doesn't.
> > +/* pdf_save_document claims to accepts NULL as third argument but
> > doesn't.
> > * pdf_write_document does not check if the third arguments is NULL
> > for some
> > * options. */
> >
> > -fz_write_options opts = { 0 }; /* just use the default options */
> > -fz_write_document(mupdf_document->ctx, mupdf_document->document,
> > (char*) path, &opts);
> > +pdf_write_options opts = { 0 }; /* just use the default options */
> > +pdf_save_document(mupdf_document->ctx, (pdf_document*)
> > mupdf_document->document, (char*) path, &opts);
> >} fz_catch (mupdf_document->ctx) {
> > return ZATHURA_ERROR_UNKNOWN;
> >}
> > [...]
> IIUC I think that the comment is no longer valid for the 1.9 API and so
> it can be simplified to just call pdf_save_document() with NULL instead
> of passing `opts' (I'm using the patches attached here:
> <https://lists.pwmt.org/archive/zathura/2016-April/056577.html>)
Could you send an updated patch against zathura-pdf-mupdf's develop branch?
Ideally something easily git am-able.
Thanks
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Visual mode/yanking text
On 2016-05-04 13:04:12, Andrew Sanchez wrote: > Is it possible to navigate text in a pdf in visual mode? E.g. search for a > word with `/`, press “v”, then select a few sentences with `)`, and y to copy > the text? No, it's not. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] LaTeX segfault
Hi On 2016-04-06 15:20:15, David Denoncin wrote: > I just thought I'd mention in case anyone is interested in fixing this that > when I compile a TeX document while the corresponding pdf is opened with > Zathura, if the compile fails then Zathura shuts down with a segmentation > fault. The following error message is shown in xterm in my particular case: > " > error: cannot find startxref > warning: trying to repair broken xref > warning: object missing 'endobj' token > zsh: segmentation fault (core dumped) zathura name_of_file.pdf > " > I think this is fixed in the devlop branch. Could you it? Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] help to fix synctex error while compiling
Hi On 2016-02-21 00:06:45, gansteed wrote: > Hi, all: > I've clone zathura to my disk, and I got an error when I try to compile > it: > > [CC] zathura/main.c > zathura/main.c: In function ‘init_zathura’: > zathura/main.c:89:11: warning: unused parameter ‘synctex_editor’ > [-Wunused-parameter] > char* synctex_editor, Window embed) >^ > zathura/main.c: In function ‘main’: > zathura/main.c:254:26: error: ‘synctex_editor’ undeclared (first use in > this function) >plugin_path, argv, synctex_editor, embed); > ^ > zathura/main.c:254:26: note: each undeclared identifier is reported only > once for each function it appears in > Makefile:103: recipe for target 'build/release/zathura/main.o' failed > make: *** [build/release/zathura/main.o] Error 1 A fix for this has been release some days ago (zathura 0.3.5). > but I got another bug, when I type tab to get completion, what I got is a > "files" string in it. I suppose that string refers to the name of the completion group. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Synctex support disabled by default now?
Hi Jakob
On 2016-02-03 13:35:49, Jakob Hetzelein wrote:
> yesterday, Arch Linux shipped the new version of zathura (0.3.4) and
> included the patch¹ that was posted by Leonardo in its build script².
>
> When I tried to use zathura with synctex today, I couldn't get it to
> work. I used the same framework [vimtex] as yesterday, the only
> difference being the new version of zathura.
>
> This is what happens:
> zathura -x "vim --servername VIM --remote +\%{line} \%{input}"
> /home/jakob/masterthesis/masterthesis.pdf
> error: Error parsing command line arguments: Unknown option -x
>
> I described it all in a little more detail in a vimtex issue³.
>
> Am I right in concluding that the new patch disables synctex support by
> default now? How to enable it at compile time? Sorry if the answer to
> this is obvious but I'm no expert at compiling programmes myself and
> didn't find it in the README nor could I get it from the Makefile.
This patch does not disable synctex by default. This patch makes zathura not
fail to build if libsynctex is not available. You need to build zathura against
libsynctex to have synctex support.
As stated in the README file:
Requirements
...
libsynctex from TeXLive (optional, for SyncTeX support)
So please ask the Arch Linux maintainer to build it against libsynctex.
(We shipped a copy of libsynctex before. But now Arch Linux has a new enough
texlive that is able to build a libsynctex, so we dropped it.)
Cheers
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Set Zoom level explicitly
Hi Bijan On 2016-01-11 23:29:33, Bijan Binaee wrote: > Hi > It is nice to have a very lightweight pdf reader like zathura and I love it > in many way. > Recently I want to set zoom level to something like 200 or 250 (an exact > value) and so I did it with typing 200zz in command mode (like goto style > in vim) and it works out of the box. > > Now I want to bind a shortcut key to do that so i tried > :map f 200zz :map f feedkeys "200zz" should work. I tried with :map f zoom specific 200, but for some reason that does not work. I'll need to look at the code for that. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] --synctex-forward change in 0.3.4
On 2016-01-10 10:46:46, gi1242+zath...@gmail.com wrote: > On Sat, Jan 09, 2016 at 03:12:45PM +0100, Sebastian Ramacher wrote: > > >> Can I find any documentation for the --synctex-forward mechanism? > > > > There is some in the man page. > > Indeed; however it is a little brief. To quote: > > --synctex-forward=input > Jump to the given position. The switch expects the same format > as specified for synctex's view -i. > > However, I could find nothing on synctex's view -i (and don't know what > that means). I did get it working after searching the mailing list > and a little experimenting. Run 'synctex help view' to get some info on that. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] --synctex-forward change in 0.3.4
Hi On 2016-01-06 16:40:52, gi1242+zath...@gmail.com wrote: > Hi All, > > Can I find any documentation for the --synctex-forward mechanism? There is some in the man page. > Suppose I run > > zathura --synctex-forward 20:1:paper.tex paper.pdf > > In 0.3.1, if an instance of zathura wasn't already showing paper.pdf, > this would fail with an unfriendly error message. In 0.3.4, it launches > a new instance if one isn't already running. > > However, if you run > > zathura --synctex-pid XXX --synctex-forward 20:1:paper.tex paper.pdf > > then it succeeds (and exits immediately) if a process with ID XXX is > already showing paper.pdf, and launches a new instance with an error > message otherwise. > > This makes things a little more inconvenient to script. (See my attached > hack script.) Can I suggest instead that if zathura is run with > --synctex-pid, then it *ALWAYS* returns immediately, and the exit status > signals whether it succeeded or failed. Should be fixed with f1d027e656. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] New location for git repositories, new bug tracker
Hi On 2015-11-24 21:26:32, Sebastian Ramacher wrote: > The repository mirrors on GitHub have not been updated yet. They should be working again. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
[zathura] New location for git repositories, new bug tracker
Hi! We have migrated our bug tracker from roundup to Taiga: https://bugs.pwmt.org. All active user accounts have been migrated, but since the password scheme has changed one is forced to reset his password via email. Logging in with GitHub accounts should now be possible. Also, all issues have been migrated to the new bug tracker. Additionally we have moved from gitolite to GitLab: https://git.pwmt.org. If you have checkouts of any repositories using git://git.pwmt.org URLs, you need to update them. The new URLs are: $ git clone https://git.pwmt.org/pwmt/.git We will use GitLab to provide CI support for our projects. First builders are set up and we should see first test results soon. Taiga and GitLab should be running fine already, but we certainly will have to do some more configuration. Feel free to give us feedback and tell us if you have any problems. Gojira will be replaced as well. The required plugins have been written already. The repository mirrors on GitHub have not been updated yet. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Calibrate zoom to physical monitor size?
On 2015-10-10 19:04:31, Caleb Maclennan wrote: > Huh. I hate to ask what an ETA looks like, but is this immanent or a someday > thing? I wasn't even aware there was a GTK port in the works. zathura was always using GTK+. But the current design made it necessary to redo some parts from scratch. Now we have libzathura (managing all the plugins and providing the document interface) and libzathura-gtk (widgets to render pages in a GTK+ based application). We are currently in the process of finishing up some parts in libzathura and libzathura-gtk and then we will port zathura to the new libraries. > In the mean time I'm wondering if there isn't a way to hack this in. Since > this is machine specific anyway I'm totally okay with compiling my own copy > from source and running that. I looked around earlier today in the source > repo but wasn't able to locate any since place where the code could be > easily hacked with a multiplier, but I have to imagine this exists somewhere > and that a simple source code change could hard code the relative scale on > the canvas. > > Know where that might be? You can take a look at libzathura-gtk/page/callbacks.c [1] and look for the code protected by #ifdef HAVE_HIDPI_SUPPORT. This should get you started. Code like this may be needed in other places too. Cheers [1] https://git.pwmt.org/?p=libzathura-gtk.git;a=summary -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Calibrate zoom to physical monitor size?
On 2015-10-10 10:15:11, Caleb Maclennan wrote: > I'm using Zathura (using the MuPDF plugin) to review various layouts for > printing. It's important to me that I'm looking at things approximately the > same size as they will come out on paper. I realize the difference between > screen pixels and how things look in print will still affect perception, but > to save test prints while I rough out margins and trim sizes I want to be > able to hold up a paper to the screen and have it match the on-screen > canvas. > > Zathura's default zoom level (100%) is anything but actual size for my > particular hardware configuration. In fact it's off by almost ⅓. If I set > the zoom to 133% I get something very close to actual size. How do I make > this the default zoom level? I would like everything else to scale against > that so that 50% is actually half size, etc. Is there a way to calibrate > the settings to my monitors—some sort of scale factor setting perhaps? > > Interestingly, Evince seems to know something about my monitor size because > it scales things exactly right out of the box. 100% turns up on my monitor > as exactly the right paper size (actually it's off by a smidgen, 100.5% is > more like it but it would be close enough). On the other hand Acroread is > off by a mile, but in the opposite direction as Zathura. There, a value of > 87% works out about right—actual-size is actually jumbo scale. > > How does Zathura decide what size to show at all? Is there a way to fix this > so 100% is actually actual-size? Is there a system DPI value that can be set > that will calibrate this? At the moment zathura isn't considering the DPI value at all and this is causing the symptoms you see. However, libzathura-gtk already considers the DPI value. So once we switch zathura to libzathura-gtk, this should work as expected. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Provide `f' shortcut in presentation mode as well
Hi On 2015-10-10 13:47:37, Denis Bitouzé wrote: > > On 2015-06-28 15:54:29, Denis Bitouzé wrote: > >> > >> But, AFAICS, it is impossible in this mode to follow links with `f' > >> shortcut. Would it be possible to add this feature? > > > > That's the idea of the presentation mode. We only provide a limited > > set of shortcuts there. > > But it is common to have to open local files (text, pdf, image, video, > etc.) or Web pages while in presentation mode. > > > If you still want it, you can just map it in your zathurarc. > > I'll check the documentation but, IMHO, this should be enabled by > default. There is also the fullscreen mode which has all these shortcuts enabled. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Provide `f' shortcut in presentation mode as well
Hi On 2015-06-28 15:54:29, Denis Bitouzé wrote: > many thanks to zathura's team for the presentation mode implementation! > > But, AFAICS, it is impossible in this mode to follow links with `f' > shortcut. Would it be possible to add this feature? That's the idea of the presentation mode. We only provide a limited set of shortcuts there. If you still want it, you can just map it in your zathurarc. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Pdf doesn't render properly with poppler plugin
On 2015-05-04 23:16:42, Alessandro Pezzoni wrote: > > > On Mon, 4 May 2015 17:22:34 +0200, Sebastian Ramacher > wrote: > > > On 2015-05-04 12:10:58, Alessandro Pezzoni wrote: > > > Hi all, I found a pdf [1] (214K) that doesn't render properly with the > > > poppler > > > plugin (the text looks quite "grainy") -- tested with git version > > > 0.2.5.2.gc95b805 in zathura git version 0.3.3.3.g3032771, both latest at > > > the > > > time of writing, and poppler version 0.32.0. > > > > > > I'm attaching screenshots of the abstract of [1] rendered by zathura with > > > the > > > poppler and mupdf plugins. I'm also attaching a screenshot rendered with > > > the > > > Firefox internal pdf viewer, for reference, because with mupdf the > > > characters > > > are slightly misaligned (both with the zatura plugin and the stand-alone > > > viewer). > > > > > > Can we do something about this or should I report the bug upstream? > > > > Does it render correctly with other poppler based viewers (like evince or > > okular)? If not, this should be reported to the poppler developers. > > This is odd... with evince it renders like with the poppler plugin, while with > flaxpdf it renders like in mupdf. They were both compiled against the same > version of poppler, though evince came from the Arch repositories and I > compiled flaxpdf myself. I didn't try okular because I would prefer not to > pull all those KDE dependencies... > > What does this mean? Is flaxpdf built against poppler's C++ backend? But if evince is affected as well, this looks like a poppler bug to me. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Pdf doesn't render properly with poppler plugin
On 2015-05-04 12:10:58, Alessandro Pezzoni wrote: > Hi all, I found a pdf [1] (214K) that doesn't render properly with the poppler > plugin (the text looks quite "grainy") -- tested with git version > 0.2.5.2.gc95b805 in zathura git version 0.3.3.3.g3032771, both latest at the > time of writing, and poppler version 0.32.0. > > I'm attaching screenshots of the abstract of [1] rendered by zathura with the > poppler and mupdf plugins. I'm also attaching a screenshot rendered with the > Firefox internal pdf viewer, for reference, because with mupdf the characters > are slightly misaligned (both with the zatura plugin and the stand-alone > viewer). > > Can we do something about this or should I report the bug upstream? Does it render correctly with other poppler based viewers (like evince or okular)? If not, this should be reported to the poppler developers. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Content partially obscured
On 2015-04-13 08:23:43, Stefan Klinger wrote: > On 2015-Apr-12, Sebastian Ramacher wrote with possible deletions: > > Is the situation better with girara's develop branch? > > No, same situation. I've just tried what you describe in [1], and see > the same black borders. By the way, I've saved the messages produced > by `zathura`, see attachment. > > No need to hurry, for the next couple of lectures I can fall back to > `mupdf`. > > (zathura:5847): Gtk-WARNING **: unmatched gtk_style_context_save/restore() > detected while validating context for GtkEventBox 0x1df2460 > > (zathura:5847): Gtk-WARNING **: unmatched gtk_style_context_save/restore() > detected while validating context for GtkLabel 0x1f4e1d0 > > (zathura:5847): Gtk-WARNING **: unmatched gtk_style_context_save/restore() > detected while validating context for GtkEventBox 0x1df2460 > > (zathura:5847): Gtk-WARNING **: unmatched gtk_style_context_save/restore() > detected while validating context for GtkLabel 0x1f4e1d0 Note that girara had a SONAME bump in the develop branch. You need to rebuild zathura against the new girara. As long as you see these messages, the zathura binary is still linked against girara 0.2.3. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Content partially obscured
On 2015-04-12 20:48:58, Sebastian Ramacher wrote: > On 2015-04-12 20:16:47, zathura-pwmt@stefan-klinger.de wrote: > > Oh, I'm really f***ed now. I'll giv a lecture tomorrow, and zathura > > partially obscures the document... As described here [1,2]. > > > > Can this be configured away? Downgrading gtk is not an option for me. > > > > Thanks in advance! > > Is the situation better with girara's develop branch? Should be fixed by 2f51b2e. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Content partially obscured
On 2015-04-12 20:16:47, zathura-pwmt@stefan-klinger.de wrote: > Oh, I'm really f***ed now. I'll giv a lecture tomorrow, and zathura > partially obscures the document... As described here [1,2]. > > Can this be configured away? Downgrading gtk is not an option for me. > > Thanks in advance! Is the situation better with girara's develop branch? Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] ~/.config/zathurarc ignored lubuntu
On 2014-12-27 10:54:56, bhairu wrote: > Sebastian Ramacher writes: > > > Because there is none. zathura checks if /etc/zathurarc exists and if it > > does, > > the file is read. > > Could you please tell me how to fix the problem that settings in my > zathurarc file are ignored. Now I am trying the following settings. > > set adjust_open width It's adjust-open. > map [fullscreen] left navigate previous > map [fullscreen] right navigate next The left and right arrow keys are special keys. They need to be in angle brackets and the first letter needs to be in upper case (, ). See zathurarc(5) for more details. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] ~/.config/zathurarc ignored lubuntu
On 2014-12-26 19:27:37, bhairu wrote: > Sebastian Ramacher writes: > > > > > Hi > > > > from the subject it seems like you are missing a zathura in the path. The > config > > file is read from ~/.config/zathura/zathurarc. > > Sorry, my mistake in the subject line. I do have ~/.config/zathura/zathurarc > > Another thing: there is no /etc/zathurarc, and I could not find (with find > command) anywhere else a default zathurarc. Because there is none. zathura checks if /etc/zathurarc exists and if it does, the file is read. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] ~/.config/zathurarc ignored lubuntu
Hi from the subject it seems like you are missing a zathura in the path. The config file is read from ~/.config/zathura/zathurarc. On 2014-12-26 13:49:24, bhairu wrote: > I use lubuntu 14.10 and zatura from lubuntu repos. It seems that zathura > ignores my zathurarc file. I have the following entries. I also tried > starting each line with o as on some page (which I cannot find now). Zatura > remembers the zoom of a file when I re-open it. I would really like to get > it to open maximized with fit width for every file by default. Thank you. > > set ADJUST-OPEN width > map zoom in > map zoom out > set WINDOW-HEIGHT 600 > set WINDOW-WIDTH 1200 The setting names should be in lower case. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org https://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] ***UNCHECKED*** Re: Set the page of a running zathura instance from the command line
Hi Alexander
On 2014-11-07 09:58:40, Alexander Baier wrote:
> On 2014-11-06 23:41 Sebastian Ramacher wrote:
> > On 2014-11-02 16:22:35, Alexander Baier wrote:
> >> Hello pwmt-devs!
> >>
> >> Is there any way to tell a running zathura instance to change the page
> >> it is currently displaying? If I simply issue the following command
> >> line, a second instance of zathura is started. I, however, want the
> >> already running instance (displaying /tmp/test.pdf) to display page 5.
> >>
> >> zathura --page=5 /tmp/test.pdf
> >>
> >> I want this to work on every PDF, which implies (IIUC) that using the
> >> synctex support is not an option here.
> >>
> >> If the description above was not clear, just try the the above with
> >> evince or okular to see what I am talking about. Okular accepts an extra
> >> option "--unique" to toggle this behaviour. Evince just always does
> >> this - if you want it or not.
> >>
> >> Is this achievable with the current zathura version? And if not, would
> >> you consider adding such a feature in a future version?
> >
> > The D-Bus interface offers a GotoPage method. You can do the same what
> > we do for --syntex-forward: look for a prg.pwmt.zathura instance that
> > has the correct file open (check the filename attribute) and run
> > GotoPage on it. The code that does this for --synctex-forward is located
> > in dbus-interface.c (iterate_instances_call_synctex_view).
>
> Thank you for the pointer to the dbus interface. My C experience,
> however, amounts to almost nothing which is why I probably won't try to
> implement this feature myself.
Here is a simple Python script that does what you want:
import dbus
import sys
filename=sys.argv[1]
page=sys.argv[2]
session = dbus.SessionBus()
for name in session.list_names():
if not name.startswith("org.pwmt.zathura"):
continue
proxy = session.get_object(name, "/org/pwmt/zathura")
zathura = dbus.Interface(proxy, "org.pwmt.zathura")
properties = dbus.Interface(proxy, "org.freedesktop.DBus.Properties")
ofilename = properties.Get("org.pwmt.zathura", "filename")
if ofilename != filename:
continue
zathura.GotoPage(page)
Call it with python $foo.py /absolute/path.pdf page
> If you think this feature is use full, I can open a feature request on
> the bug tracker. What do you think?
Maybe we should start a collection of scripts instead of putting them
all in the binary. I don't know yet.
Cheers
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Set the page of a running zathura instance from the command line
On 2014-11-02 16:22:35, Alexander Baier wrote: > Hello pwmt-devs! > > Is there any way to tell a running zathura instance to change the page > it is currently displaying? If I simply issue the following command > line, a second instance of zathura is started. I, however, want the > already running instance (displaying /tmp/test.pdf) to display page 5. > > zathura --page=5 /tmp/test.pdf > > I want this to work on every PDF, which implies (IIUC) that using the > synctex support is not an option here. > > If the description above was not clear, just try the the above with > evince or okular to see what I am talking about. Okular accepts an extra > option "--unique" to toggle this behaviour. Evince just always does > this - if you want it or not. > > Is this achievable with the current zathura version? And if not, would > you consider adding such a feature in a future version? The D-Bus interface offers a GotoPage method. You can do the same what we do for --syntex-forward: look for a prg.pwmt.zathura instance that has the correct file open (check the filename attribute) and run GotoPage on it. The code that does this for --synctex-forward is located in dbus-interface.c (iterate_instances_call_synctex_view). Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] xpdf can render file all right but not zathura
On 2014-10-08 04:49:51, Globe Trotter wrote: > Hi, > I am lost. I can not get zathura to render the attached file, but it > does show up fine on xpdf. Any ideas as to what is wrong? I am on > zathura-0.2.9-1.fc20.x86_64 (Zathura 0.2.9 on Fedora 20). > Many thanks! hmm, it also works in evince. That's interesting. We must be doing something wrong. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Float selection
On 2014-08-14 17:54:03, Igor Almeida wrote: > Hi, > > I'd like to implement a 'float selection' functionality, to be able > to extract some selected region (maybe with right-click, to distinguish > from current behavior?) to a separate window. > This would be useful for keeping a diagram visible while I read its > description along the original document's text, for example. With a long > enough text, eventually you need to scroll and lose sight of what the > document is referring to. > > Can anyone offer hints as to how I could implement that with zathura? > > Today, I can mimic that by opening a second instance and shrinking the > window to fit only what I want to see, which is far from ideal. > > I'm not really sure if this needs to be specific to the PDF plugin, but > that's my main goal for now. > > Any help is appreciated. So, there is already code to store the text of a selected area in the clipboard. I think you can adapt the code to just copy parts of the rendered image instead of the text. See page-widget.c for details. In particular cb_zathura_page_widget_button_release_event. Let me know if you need more info. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] zathura memory usage
On 2014-08-14 15:24:15, Matthieu CASTET wrote: > Hi, > > Nobody is able do reproduce it ? > > I tried valgrind, it show no memleack, but lot's of memory allocation. Well, that's somewhat expected. We iterate over every page and search for the string. So of course, we need to load all the pages into memory. We could be a bit more intelligent and just load the current page, search for the string and wait for the user to hit n and then continue searching. But even that wouldn't help if the result is at the other end of the document. Does disabling incremental search help a bit? At least it won't search for every string while you're still entering the search string. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Synctex in 2.9
On 2014-07-25 11:30:50, Sebastian Ramacher wrote: > On 2014-07-23 11:12:29, gi1242+zath...@gmail.com wrote: > > PS: Can I convert my blunder here to a desperate plea for a setting in > > the RC file for all synctex options, instead of us having to resort > > to command line options every time? > > I guess we should support that and make it possible to override it via the > command line option. Done. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Synctex in 2.9
On 2014-07-23 11:12:29, gi1242+zath...@gmail.com wrote: > PS: Can I convert my blunder here to a desperate plea for a setting in > the RC file for all synctex options, instead of us having to resort > to command line options every time? I guess we should support that and make it possible to override it via the command line option. > Also, it might make life a > little easier for users if there was an option for --synctex-forward > to open a new window if the file isn't already being viewed. > (Admittedly this can easily be worked around by scripting.) We should probably do that, yes. Unfortunately this needs some more work, but then we could finally implement support for opening files a specific locations too. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Synctex in 2.9
Hi
On 2014-07-22 21:46:58, gi1242+zath...@gmail.com wrote:
> This might very well be a bug in my setup, but I couldn't figure out
> what's going on so I thought I would post for help.
>
> 1. With verion 0.2.7 (which I compiled myself), I have synctex
>forward/backward search working perfectly.
>
> 2. Using 0.2.9 (from Debian/testing), I only have forward search
>working, but not backward search. Namely, if I control click in a
>PDF file, *nothing happens*. If I open the same PDF file in 0.2.7
>and control click, then I get taken to my TeX source as expected.
>
> For version 2.9 (actually zathura-0.2.9-2 from Debian/testing) I run it
> under a chroot. I have libsynctex installed, and also the executable
> synctex in my path.
>
> Does anyone have any ideas?
How do you invoke zathura? What happens if you try zathura -s -x "echo
%{linestr}". Does it print the line number if you control click?
Cheers
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] girara is not recognized
On 2014-06-28 01:36:09, Pedro Armando Ojeda May wrote: > Hi, > > I have installed girara as root in my computer with opensuse 13.1 > without any error. I installed girara because I wanted to install > zathura the pdf viewer. When I try to install zathura I get the message: > > > The minium required version of GIRARA is 0.2.2 > make: *** [.version-checks/GIRARA] Error 1 > > > but I have installed girara already. Do you know how to fix this issue? Do you have pkg-config installed? How did you build and install girara? Please attach logs from make and make install with VERBOSE=1. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] building zathura-pdf-mupdf
On 2014-06-15 22:47:41, Pablo Rodríguez wrote: > Hi there, > > congratulations for your excellent piece of software and many thanks > fore releasing it under a free license. > > I’m interested in having the zathura-pdf-mupdf plugin in Fedora. > > I have two questions: > > Does the latest version 0.2.6 work with mupdf-1.5? > > Is it really required that mupdf is compiled with -fPIC option? > > The last question was asked to me when I opened an issue requesting this > flag in compilation > (https://bugzilla.redhat.com/show_bug.cgi?id=1109589#c1). I must confess > that this is all Greek to me. Yes, compiling mupdf with -fPIC is necesary. Otherwise building zathura-pdf-mupdf will fail while linking with something like "symbol xyz can not be rellocated, recompile with -fPIC." Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Open links with...
On 2014-05-09 14:48:23, Stefan Klinger wrote: > Hi, > > by default, zathura seems to launch `xdg-open` to follow a link. Can > this be configured? At the moment I don't think that's possible. What are you trying to achieve? Do you want to change the application that is launched to follow a link? In this case it should be possible to change the default in your DE (if you are using one) or use xdg-mime to set the application to handle a specific mimetype. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] jumplist-size option generates critical warning
On 2014-05-03 13:05:24, Abdó Roig-Maranges wrote: > > Hi, > > >> There is a separator that appears in 2 places: around the input buffer in > >> the statusbar, and between commands and descriptions in the completion > >> menu. > >> [...] > > > > This should be fixed in 8009f7e in girara's develop branch. > > > I attach a patch removing the padding for the statusbar, which casued vertical > strips of default-bg color, the same as in the completion menu. Thank you! Applied. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Sphinx theme error
On 2014-04-27 21:02:10, Αριστοτέλης Πανάρας wrote:
> Well, actually there was a slight problem.
> More specifically, the manpages were not installed. It was not a packaging
> error, but a Makefile mishap.
> It seems that *Sphinx* (ran through the Makefile in ./doc) is used to build
> the complete manpages, but the thing is that the following lines in the
> root Makefile do not work as they are supposed to:
>
> install-manpages: build-manpages
> $(call colorecho,INSTALL,"man pages")
> $(QUIET)mkdir -m 755 -p ${DESTDIR}${MANPREFIX}/man1
> ${DESTDIR}${MANPREFIX}/man5
> ifneq "$(wildcard ./doc/_build/man/${PROJECT}.1)" ""
> $(QUIET)install -m 644 ./doc/_build/man/${PROJECT}.1
> ${DESTDIR}${MANPREFIX}/man1
> endif
> ifneq "$(wildcard ./doc/_build/man/${PROJECT}rc.5)" ""
> $(QUIET)install -m 644 ./doc/_build/man/${PROJECT}rc.5
> ${DESTDIR}${MANPREFIX}/man5
> endif
>
> That is because *Sphinx*, after building the manpages for *zathura* and
> *zathurarc*, it does not leave them under *./doc/_build/man/*, but rather
> under *./doc/_build/*.
> So removing the */man/* part of the path in these four lines fixes the
> problem.
Thanks for noticing. This should be fixed now.
Cheers
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Sphinx theme error
On 2014-04-24 09:05:33, Αριστοτέλης Πανάρας wrote: > I am using zathura in Arch Linux, using package 'zathura-git'. > After trying to build the latest develop snapshot (89113e3), it fails with > the following error: > > Exception occurred: > File "conf.py", line 6, in > import sphinx_rtd_theme > ImportError: No module named 'sphinx_rtd_theme' > The full traceback has been saved in /tmp/sphinx-err-d62em_yk.log, if you > want to report the issue to the developers. > Please also report this if it was a user error, so that a better error > message can be provided next time. > A bug report can be filed in the tracker at < > https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks! > Makefile:23: recipe for target 'man' failed > make[1]: *** [man] Error 1 > make[1]: Leaving directory > '/tmp/yaourt-tmp-ale1ster/aur-zathura-git/src/zathura/doc' > Makefile:188: recipe for target 'build-manpages' failed > make: *** [build-manpages] Error 2 > > . > I have installed 'python-sphinx' (which is sphinx with python3 > dependencies) and 'doxygen'. Also pip is present > Since there is a requirements.txt file containing a sphinx-rtd-theme line, > is there another reason the install fails? There should be some auto-detection happening for that now. If Sphinx is available, the manpages will be built. If doxygen, breathe and sphinx_rtd_theme are also available, the HTML documentation will be built too. If there are any problems with that, please let me know. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] jumplist-size option generates critical warning
On 2014-04-23 23:25:39, Αριστοτέλης Πανάρας wrote:
> In that case, the index colors mode could well be due to an issue with
> girara.
> Should I file a bug report or is this mail sufficient?
There's now index-{fg,bg} and index-active-{fg,bg} to style the index mode. It
defaults to the same as the completion for now.
Cheers
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] jumplist-size option generates critical warning
On 2014-04-23 23:25:39, Αριστοτέλης Πανάρας wrote: > 4. Since you mentioned a restructuring in girara's theming, there is one > more thing. > There is a separator that appears in 2 places: around the input buffer in > the statusbar, and between commands and descriptions in the completion menu. > I am not sure anymore, as I am becoming more accustomed to the new look, > but I think that previously it was not visible (it had the same color with > its surroundings), but after the change to develop branch it became visible > as it is currently black. This should be fixed in 8009f7e in girara's develop branch. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Sphinx theme error
On 2014-04-24 09:05:33, Αριστοτέλης Πανάρας wrote: > I am using zathura in Arch Linux, using package 'zathura-git'. > After trying to build the latest develop snapshot (89113e3), it fails with > the following error: > > Exception occurred: > File "conf.py", line 6, in > import sphinx_rtd_theme > ImportError: No module named 'sphinx_rtd_theme' > The full traceback has been saved in /tmp/sphinx-err-d62em_yk.log, if you > want to report the issue to the developers. > Please also report this if it was a user error, so that a better error > message can be provided next time. > A bug report can be filed in the tracker at < > https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks! > Makefile:23: recipe for target 'man' failed > make[1]: *** [man] Error 1 > make[1]: Leaving directory > '/tmp/yaourt-tmp-ale1ster/aur-zathura-git/src/zathura/doc' > Makefile:188: recipe for target 'build-manpages' failed > make: *** [build-manpages] Error 2 > > . > I have installed 'python-sphinx' (which is sphinx with python3 > dependencies) and 'doxygen'. Also pip is present > Since there is a requirements.txt file containing a sphinx-rtd-theme line, > is there another reason the install fails? > > I am sorry if I have misunderstood something. I am not quite familiar with > python yet. You will also need breathe and sphinx_rtd_theme, I guess. It might be a good idea to split building of the manpages and the full blown documentation and only build the doxygen doc if we breathe + doxygen + sphinx_rtd_theme are installed. I'll look into that. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] jumplist-size option generates critical warning
On 2014-04-23 20:08:39, Αριστοτέλης Πανάρας wrote: > 1. On develop branch, and more specifically commit 3285d61, setting > jumplist-size option in zathurarc seems to generate a critical warning. > > Reproducible by creating a zathurarc with the following line: > > set jumplist-size 2000 > > , the output is as follows: > > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/djvu.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/djvu.so': > version 0.2.3 > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/pdf.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/pdf.so': > version 0.2.6 > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/ps.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/ps.so': > version 0.2.2 > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/cb.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/cb.so': > version 0.1.2 > > ** (zathura:12942): CRITICAL **: zathura_jumplist_trim: assertion 'zathura > != NULL && zathura->jumplist.list != NULL && zathura->jumplist.size != 0' > failed > debug: (zathura_init:202) Using plain database backend. > debug: (bus_acquired:88) Bus acquired at 'org.pwmt.zathura.PID-12942'. > debug: (name_acquired:111) Acquired 'org.pwmt.zathura.PID-12942' on session > bus. > debug: (guess_type_magic:57) magic detected filetype: application/pdf > debug: (zathura_jumplist_load:1364) Loaded the jumplist from the database > debug: (page_cache_is_cached:820) Page 1 is a cache miss > debug: (zathura_renderer_page_cache_add:920) Page 1 is cached at cache > index 0 > debug: (render_job:749) Rendering page 1 ... > debug: (emit_completed_signal:505) Emitting signal for page 1 Fixed in develop. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] jumplist-size option generates critical warning
On 2014-04-23 23:25:39, Αριστοτέλης Πανάρας wrote: > 1. Thanks. > 2,3. That is correct, zathura-git pulls girara.git's develop branch and > links it with gtk3 (package girara-gtk3-git). > In that case, the index colors mode could well be due to an issue with > girara. > Should I file a bug report or is this mail sufficient? The mail is sufficient. If you find anything else, please let us know. > 4. Since you mentioned a restructuring in girara's theming, there is one > more thing. > There is a separator that appears in 2 places: around the input buffer in > the statusbar, and between commands and descriptions in the completion menu. > I am not sure anymore, as I am becoming more accustomed to the new look, > but I think that previously it was not visible (it had the same color with > its surroundings), but after the change to develop branch it became visible > as it is currently black. Yes, I saw that too. Just haven't found a way to give them the correct background color. In other words: I do not know which widget has the wrong background color. (I think this issue exists since the GTK+ 3 switch, but I'm not sure.) Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] synctex, open a new file on a specified line
On 2014-04-23 10:05:40, Maxim Gonchar wrote:
> Hi,
>
> after some playing and searching the internet I was able to use zathura
> synctex support, by opening a file:
> zathura -s -x 'gvim --servername SYNCTEX --remote +\%{line} \%{input}'
> Introduction_en.pdf
> and switching to the specified line:
> zathura --synctex-forward 100:1:/Introduction_en.tex
> Introduction_en.pdf
>
> If I try to combine these two commands I get an error saying that the
> opened instance for Introduction_en.pdf is not found.
> I wonder why this distinction is made? Is there a way to open zathura and
> sync if file is not opened, or simply sync if the opened instance exists?
It's just that nobody had any use for anything like that yet so it's just not
there - doing anything after a document has been opened was always a pain to
time right. But if there's interest in something like that, we can fix that.
Cheers
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] jumplist-size option generates critical warning
On 2014-04-23 20:08:39, Αριστοτέλης Πανάρας wrote: > Hello. I am new here, so forgive me for asking things that might have > already been discussed. > > 1. On develop branch, and more specifically commit 3285d61, setting > jumplist-size option in zathurarc seems to generate a critical warning. > > Reproducible by creating a zathurarc with the following line: > > set jumplist-size 2000 > > , the output is as follows: > > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/djvu.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/djvu.so': > version 0.2.3 > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/pdf.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/pdf.so': > version 0.2.6 > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/ps.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/ps.so': > version 0.2.2 > debug: (zathura_plugin_manager_load:195) successfully loaded plugin > /usr/lib/zathura/cb.so > debug: (zathura_plugin_manager_load:207) plugin '/usr/lib/zathura/cb.so': > version 0.1.2 > > ** (zathura:12942): CRITICAL **: zathura_jumplist_trim: assertion 'zathura > != NULL && zathura->jumplist.list != NULL && zathura->jumplist.size != 0' > failed > debug: (zathura_init:202) Using plain database backend. > debug: (bus_acquired:88) Bus acquired at 'org.pwmt.zathura.PID-12942'. > debug: (name_acquired:111) Acquired 'org.pwmt.zathura.PID-12942' on session > bus. > debug: (guess_type_magic:57) magic detected filetype: application/pdf > debug: (zathura_jumplist_load:1364) Loaded the jumplist from the database > debug: (page_cache_is_cached:820) Page 1 is a cache miss > debug: (zathura_renderer_page_cache_add:920) Page 1 is cached at cache > index 0 > debug: (render_job:749) Rendering page 1 ... > debug: (emit_completed_signal:505) Emitting signal for page 1 > > . > It would seem that it is due to the zathura_jumplist_trim() call generated > by setting the jumplist-size in the rc file. More specifically, the > cb_jumplist_change() callback seems to call zathura_jumplist_trim() before > the document jumplist is loaded in document_open_idle(). I'll look at that. > 2. Since I changed to the develop branch (zathura-git in Arch AUR), the > index mode seems to have changed a bit. > The default colors seem to have changed (white foreground in black > background) and the currently selected object is not visible anymore as it > was before (where is was grey on white background). That seems to not be > configurable at the moment. > 3. Also, I might be mistaken, but was the scrollbar always present in index > mode when guioptions did not contain v? If I remember correctly (and please correct me if I am wrong, I'm not an Arch user), zathura-git pulls girara-git so you get all the new theming code from girara. We are currently changing the way we theme girara from gtk_widget_* calls to CSS. So if anything is broken theming wise, this might just be a consequence of that. Please let us know of any such unexpected difference so we can fix them before releasing the next version of girara. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Confusing keybinding: search forward instead of search next
On 2014-02-22 22:01:30, Sebastian Ramacher wrote: > On 2014-02-18 16:17:03, Dan Rosén wrote: > > Dear developers of Zathura, > > > > It took me some digging into the source code to understand that I should > > bind `search forward' instead of `search next' in zathurarc, to, well, > > search to the next match. > > > > I do think that this is a problem: In the man page for zathurarc, there is > > just a long list of possible arguments to all shortcut functions, but only > > a few of them actually work to each specific function. It would be very > > helpful to know which arguments can be passed to which function. > > > > This would help in situations like this, when it is not obvious if `search' > > should take `forward' and `backward' as arguments, rather than `previous' > > and `next'. > > Yes, indeed. We should document arguments to shortcut functions better. > I will start working on this. Done in ab9f551 for some shortcut functions. There are many more taking arguments, but I don't feel like documenting them right now. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Confusing keybinding: search forward instead of search next
On 2014-02-18 16:17:03, Dan Rosén wrote: > Dear developers of Zathura, > > It took me some digging into the source code to understand that I should > bind `search forward' instead of `search next' in zathurarc, to, well, > search to the next match. > > I do think that this is a problem: In the man page for zathurarc, there is > just a long list of possible arguments to all shortcut functions, but only > a few of them actually work to each specific function. It would be very > helpful to know which arguments can be passed to which function. > > This would help in situations like this, when it is not obvious if `search' > should take `forward' and `backward' as arguments, rather than `previous' > and `next'. Yes, indeed. We should document arguments to shortcut functions better. I will start working on this. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] zathura and the mupdf plugin
On 2014-01-24 10:09:01, henry wrote: > Some time ago I've build zathura with zathura-pdf-mupdf plugin, so I > know it works. > > This time pdfs are not displayed, the according error message is: > > error: could not load plugin /usr/lib/zathura/pdf.so > (/usr/lib/zathura/pdf.so: undefined symbol: fz_new_context_imp) > error: unknown file type > > What I did: > I built mupdf with -fPIC > Linked /usr/local/lib/libopenjp2.so.6 to /usr/lib > Built zathura-pdf-mupdf from git > Built zathura from git Which version of mupdf is this? zathura-pdf-mupdf should be compatible with mupdf 1.3. If you are using anything newer (i.e. mupdf git), it might not work and needs to be ported first. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Center pages
On 2014-01-19 20:29:40, akbjker wrote: > >From a first look at it, this leaks all old GtkAlignment instances on every > >page_widget_set_mode call. > > Whoops, you're right. I misunderstood the purpose of gtk_widget_reparent. > > Here's the patch v2. Thank you. I've pushed it for now. We probably need to check if the layouting code in adjustment.c, etc. is okay with this change. But pretty much everything gets centered, if I remember the correctly. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Center pages
On 2014-01-18 02:08:04, akbjker wrote:
> diff --git a/zathura.c b/zathura.c
> index 1f5f4fd..5335def 100644
> --- a/zathura.c
> +++ b/zathura.c
> @@ -943,10 +943,6 @@ document_close(zathura_t* zathura, bool keep_monitor)
>
>/* remove widgets */
>gtk_container_foreach(GTK_CONTAINER(zathura->ui.page_widget),
> remove_page_from_table, (gpointer) 1);
> - for (unsigned int i = 0; i <
> zathura_document_get_number_of_pages(zathura->document); i++) {
> -g_object_unref(zathura->pages[i]);
> -g_object_unref(zathura->pages[i]); // FIXME
> - }
>free(zathura->pages);
>zathura->pages = NULL;
>
> @@ -1062,9 +1058,15 @@ page_widget_set_mode(zathura_t* zathura, unsigned int
> page_padding,
> int x = (i + first_page_column - 1) % pages_per_row;
> int y = (i + first_page_column - 1) / pages_per_row;
>
> -zathura_page_t* page = zathura_document_get_page(zathura->document, i);
> -GtkWidget* page_widget = zathura_page_get_widget(zathura, page);
> -gtk_grid_attach(GTK_GRID(zathura->ui.page_widget), page_widget, x, y, 1,
> 1);
> +GtkWidget* page_widget = zathura->pages[i];
> +
> +GtkWidget* align = gtk_alignment_new(0.5, 0.5, 0, 0);
> +if (gtk_widget_get_parent(page_widget))
> + gtk_widget_reparent(page_widget, align);
> +else
> + gtk_container_add(GTK_CONTAINER(align), page_widget);
> +
> +gtk_grid_attach(GTK_GRID(zathura->ui.page_widget), align, x, y, 1, 1);
>From a first look at it, this leaks all old GtkAlignment instances on
every page_widget_set_mode call.
Regards
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Center pages
On 2014-01-19 17:12:09, akbjker wrote: > Basically, all of the ZathuraPages get resized to the largest one, and > GtkDrawingArea's default background color gets drawn in the leftover > space of the smaller pages. > It's more noticeable when pages are grossly different sizes, like in > this attached PDF. Oh, I see. I had a PDF open where I thought the first page had a different size, but in fact that wasn't true. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Center pages
On 2014-01-18 02:08:04, akbjker wrote: > Quick patch to center-align pages that have different sizes. > Also fixes a bug that forces all the ZathuraPages to the size of the > largest one, therefore causing GTK's default background color to be > drawn instead of the one set in zathurarc. > > This feels kind of hacky, though. In the long term, it might be better > to manually draw the whole content area, rather than relying on Gtk's > layout containers. hmm, the background color still does not seem to be correct. I get the same background color as before. Maybe there is some color setting missing for a widget? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] An other fix for synctex forward-search
Hi On 2014-01-18 18:18:10, Abdó Roig-Maranges wrote: > Commit 5a992d2d460c0 introduced a type mismatch that breaks synctex forward > search, failing with a DBus.Error.InvalidArgs. > > I attach a fix. Oh crap. Thanks for the fix. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] some fixes for the new synctex forward search
On 2014-01-17 15:55:42, Sebastian Ramacher wrote: > On 2014-01-17 13:48:05, Abdó Roig-Maranges wrote: > > I attach some small fixes for the new synctex forward search functionality. > > Thanks for the patches. Unfortunately, they do not apply (starting with > patch 2). I've rebased and applied them. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] some fixes for the new synctex forward search
On 2014-01-17 13:48:05, Abdó Roig-Maranges wrote:
> From 922361bab36aef469766806cca12974e442ce99a Mon Sep 17 00:00:00 2001
> From: Abdo Roig-Maranges
> Date: Fri, 17 Jan 2014 12:52:05 +0100
> Subject: [PATCH 1/4] fix page range check
>
> In those cases, page is in the range [1...N], both ends included.
> ---
> dbus-interface.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dbus-interface.c b/dbus-interface.c
> index 569d83a..d145106 100644
> --- a/dbus-interface.c
> +++ b/dbus-interface.c
> @@ -255,7 +255,7 @@ handle_method_call(GDBusConnection* UNUSED(connection),
> g_variant_get(parameters, "(i)", &page);
>
> bool ret = true;
> -if (page < 1 || (unsigned int)page >= number_of_pages) {
> +if (page < 1 || (unsigned int)page > number_of_pages) {
>ret = false;
> } else {
>page_set(priv->zathura, page - 1);
> @@ -270,7 +270,7 @@ handle_method_call(GDBusConnection* UNUSED(connection),
> g_variant_get(parameters, "(ia()a(i))", &page, &iter,
> &secondary_iter);
>
> -if (page < 1 || (unsigned int)page >= number_of_pages) {
> +if (page < 1 || (unsigned int)page > number_of_pages) {
>GVariant* result = g_variant_new("(b)", false);
>g_variant_iter_free(iter);
>g_variant_iter_free(secondary_iter);
> --
> 1.8.5.3
Merged and pushed this one.
Regards
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] some fixes for the new synctex forward search
g_object_set(page_widget, "search-current", target_idx, NULL);
> g_object_get(page_widget, "search-results", &results, NULL);
>
> +/* Need to adjust rectangle to page scale and orientation */
> zathura_rectangle_t* rect = girara_list_nth(results, target_idx);
> zathura_rectangle_t rectangle = recalc_rectangle(target_page, *rect);
>
> --
> 1.8.5.3
>
>
> From d3926da7fd7d3eb6b9742e7b23c238d99151dcf6 Mon Sep 17 00:00:00 2001
> From: Abdo Roig-Maranges
> Date: Fri, 17 Jan 2014 13:40:51 +0100
> Subject: [PATCH 4/4] align highlighted rectangles correctly
>
> Align center of the rectangle with the center of the viewport, vor both
> keyword searches and synctex forward search.
> ---
> dbus-interface.c | 9 +++--
> shortcuts.c | 8 ++--
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/dbus-interface.c b/dbus-interface.c
> index 1f780dd..c22b2f2 100644
> --- a/dbus-interface.c
> +++ b/dbus-interface.c
> @@ -197,9 +197,14 @@ highlight_rects(zathura_t* zathura, unsigned int page,
>zathura_rectangle_t* rect = girara_list_nth(rectangles[page], 0);
>zathura_rectangle_t rectangle = recalc_rectangle(doc_page, *rect);
>
> - pos_y += (rectangle.y1 - (double)cell_height/2) / (double)doc_height;
> + /* compute the center of the rectangle, which will be aligned to the center
> + of the viewport */
> + double center_x = (rectangle.x1 + rectangle.x2) / 2;
> + double center_y = (rectangle.y1 + rectangle.y2) / 2;
> +
> + pos_y += (center_y - (double)cell_height/2) / (double)doc_height;
>if (search_hadjust == true) {
> -pos_x += (rectangle.x1 - (double)cell_width/2) / (double)doc_width;
> +pos_x += (center_x - (double)cell_width/2) / (double)doc_width;
>}
See above
>
>/* move to position */
> diff --git a/shortcuts.c b/shortcuts.c
> index a067dac..0f5c807 100644
> --- a/shortcuts.c
> +++ b/shortcuts.c
> @@ -940,10 +940,14 @@ sc_search(girara_session_t* session, girara_argument_t*
> argument,
> unsigned int doc_width = 0;
> zathura_document_get_document_size(zathura->document, &doc_height,
> &doc_width);
>
> -pos_y += (rectangle.y1 - (double)cell_height/2) / (double)doc_height;
> +/* compute the center of the rectangle, which will be aligned to the
> center
> + of the viewport */
> +double center_x = (rectangle.x1 + rectangle.x2) / 2;
> +double center_y = (rectangle.y1 + rectangle.y2) / 2;
>
> +pos_y += (center_y - (double)cell_height/2) / (double)doc_height;
> if (search_hadjust == true) {
> - pos_x += (rectangle.x1 - (double)cell_width/2) / (double)doc_width;
> + pos_x += (center_x - (double)cell_width/2) / (double)doc_width;
> }
>
> /* move to position */
> --
> 1.8.5.3
>
Regards
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Zathura launches five deamons?
On 2014-01-05 15:24:41, zathura-pwmt@stefan-klinger.de wrote: > On 2014-Jan-05, Sebastian Ramacher wrote with possible deletions: > > > Recently, however, I've realised that running `zathura` for the first time > > > also launches the following *five* processes (observed via `top`): > [...] > > Note this will happen with any GTK+ 3 application, not only zathura. > > Now I'll have to find out why GTK+3 is doing this... At some point the GTK+ developers decided that accessability by default is a good thing. I don't remember the bug number, but this should have happened some time around the release of GTK+ 3.6. > [...] > > > 2. Can I avoid them being started? > > > > Setting NO_AT_BRIDGE=1 in your environment should stop GTK+ 3 from > > starting the AT bridge. > > Yes, that solved my problem! I wonder what other issues I've earned that > way... It should also be possible to rebuild GTK+ 3 with --without-atk-bridge if you want to get rid of it (at least according to the changelog entry for GTK+ 3.5.6). Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Zathura launches five deamons?
Hi On 2014-01-05 13:46:11, zathura-pwmt@stefan-klinger.de wrote: > Recently, however, I've realised that running `zathura` for the first time > also launches the following *five* processes (observed via `top`): > > dbus-launch --autolaunch 0389ea1a1cc648c096dbf2ebed9276de --binary-syntax > --close-stderr > > /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session > > /usr/lib/at-spi2-core/at-spi-bus-launcher > > /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf > --nofork --print-address 3 > > /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session > > These processes continue after zathura terminates. The do not go away until > the end of my session. For a lightweight tool, I find this quite surprising, > and frankly, I don't like unnecessary processes running in the background. So > here are my questions: > > 1. Why are these deamons started? Because GTK+ 3 starts the AT bridge automatically. Since you do not appear to have a D-Bus session running, this will also cause a D-Bus session to be started. Note this will happen with any GTK+ 3 application, not only zathura. > 2. Can I avoid them being started? > > - If so, how? Setting NO_AT_BRIDGE=1 in your environment should stop GTK+ 3 from starting the AT bridge. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] synctex forward synchronization
On 2012-08-14 13:05:06, Roland Schatz wrote: > I have attached the patch for forward synchronization. Finally it's happening. The major part of the patch has already been applied for some time but was not usable at all. I've started to implement the remaining bits. The current progress can be seen in the branch feature/synctex. zathura has gained a new command line argument --syntex-forward. If zathura is called as 'zathura --syntex-forward ', zathura will search for a running instance having the file open and it will send to the that instance. is of the same format as the argument passed to syntex view -i. (Note that currently needs to be an absolut path. I'll fix that in the feature.) I've also commited a first ftplugin for vim (tex_zathurasynctex.vim). With this plugin enabled f will perform a forward sync. The detection of the correct probably needs some love (it currently tries a function provided by latex-suite and some heuristic to determine by checking the available syntex data). Any comments are very welcome (expecially regarding the vim plugin). Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Zathura is slow when searching the first time
On 2013-11-01 22:33:02, Ignas Anikevičius wrote: > - Memory usage goes up from about 180MB to about 320MB during the first > search, but subsequent searches do not cause an increase in memory. In fact there was a memory leak in poppler's implenentation of the search function. At least that bit should be better now. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] State of GTK+3 support
I've switched the default version now. Please report any issues that this may have caused. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] State of GTK+3 support
On 2013-11-02 15:04:43, Sebastian Ramacher wrote: > - Somewhere in girara we don't set all the colors correctly. The >statusbar and the completion results have all the wrong colors for >me: I wanted to include a screenshot for that but apparently I forgot to do that. I think all of these color issues are fixed by the latest commits in girara. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
[zathura] State of GTK+3 support
Hi, since the GTK+3 support is getting better and better and I really like to switch to GTK+3 as default GTK+ version, I think it's time to recap what's missing to do the switch: - There is http://bugs.pwmt.org/issue350 which looks like another timing issue to me, i.e. we need to open the document somewhat later. - Somewhere in girara we don't set all the colors correctly. The statusbar and the completion results have all the wrong colors for me: Is there anything else that people running the GTK+3 version noticed and needs to be fixed before switching? If we consider the GTK+3 support good enough at the time we do the next release, it might be worth changing the default version for 0.2.5. If that's not possible, then we should do it in 0.2.6. I think we should support GTK+2 for one release after we've switched and then start dropping all the GTK+2 support and clean up the code base. I'd like to hear opinions on this plan and please let me know of any bugs that need to be fixed before the switch. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Zathura is slow when searching the first time
Hi Ignas On 2013-11-01 22:33:02, Ignas Anikevičius wrote: > I was wondering if anybody could explain me why zathura is quite slow during > the first search? Try the following file as an example: > > http://www.komascript.de/files/scrguien.pdf > > What I observe: > > - During the first search zathura becomes unresponsive and when it has > "finished searching, then it becomes responsive again and everything is > fine. Searching is currently done in the main thread, which causes the UI to freeze if the search needs some time to finish. > - Memory usage goes up from about 180MB to about 320MB during the first > search, but subsequent searches do not cause an increase in memory. That's probably caused by the backend libraries loading the file into memory. > - Subsequent searches are also much much faster, almost instant. I guess that's because most of the interesting stuff is now cached. > The above things make me wonder if we create another copy of all zathura pages > and then use them for searching or what? Where does the memory go? I'd really > love to use zathura full time, but sometimes search functionality is just too > resource intensive. We don't copy any pages. The only thing we do while searching is calling the respective seach function from the plugin which forwards to the search function provided by the backend. (Note that the mupdf plugins keeps the extracted text in memory. This could explain the groth in memory usage you see. But without knowing which plugins you are using, I'll state what zathura itself does.) There is one thing we need to do with the search code and that is to run in its on thread. There is a bug for the search performance issue at http://bugs.pwmt.org/issue330. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] remembering vertical position on PgDn
On 2013-10-29 11:53:27, Andrei Mikhailov wrote: > Hi! > > I have recently discovered Zathura, it looks very nice! > However, I have a very basic quesion. When I go to the next page or previous > page, > is it possible to land on the same vertical position? Generally speaking, is > it > possible to make Zathura remember the vertical position within the page > while jumping? This issue might be related to http://bugs.pwmt.org/issue328. Does remapping as described in the bug fix it for you? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Making page refreshes less prone to breaking
Applied this one and I've also gone ahead and merge the branch back into develop. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Making page refreshes less prone to breaking
On 2013-10-30 08:39:59, Abdó Roig-Maranges wrote: > > Hi, > > > Maybe that's a bug that I haven't noticed so far or is introduced by > > these changes: using the index to jump to some page, I always see the > > first page. Moving around a little bit or zooming in/out displays the > > correct page again. > > hmm... I can't reproduce this on the redo-page-refresh branch, neither on GTK2 > nor GTK3. > > It did happen with current develop quite a lot. I think it started happening > after the upgrade to GTK 3.10, but I wouldn't bet on it. > > The problem there was that when setting the vertical position coming out of > the > index mode, the adjustment still was thinking it was "adjusting the index", it > had the wrong bounds. In fact, this is one of the racy things that made me > finish these patches! If I missed something, I'd like very much to fix it! > > I'm using the redo-page-refresh branch for my work related pdf reading, so it > is > having some testing. So far I didn't find any issues, except for the one I > reported on the bug tracker regarding scale on the first page for a new > document > on gtk3. Maybe I was on the wrong branch. I can't reproduce it at the moment. I'll let you know if it happens again. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Making page refreshes less prone to breaking
On 2013-10-27 02:48:26, Sebastian Ramacher wrote: > On 2013-10-26 18:45:21, Abdó Roig-Maranges wrote: > > https://github.com/aroig/zathura > > I've played a bit with the new code and enjoy it so far. I'll push it as > feature/redo-page-refresh to the git repository at pwmt.org until I've > had more time to look at the code in more detail. Maybe that's a bug that I haven't noticed so far or is introduced by these changes: using the index to jump to some page, I always see the first page. Moving around a little bit or zooming in/out displays the correct page again. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Making page refreshes less prone to breaking
On 2013-10-26 18:45:21, Abdó Roig-Maranges wrote: > https://github.com/aroig/zathura I've played a bit with the new code and enjoy it so far. I'll push it as feature/redo-page-refresh to the git repository at pwmt.org until I've had more time to look at the code in more detail. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Making page refreshes less prone to breaking
Hi, sorry that I haven't yet found the time to reply to your mail. On 2013-10-26 18:45:21, Abdó Roig-Maranges wrote: > I got this in a stable state. I tried to attach the patches on a previous > mail, > but it was too big and got held up for moderation. So I've uploaded it on > github. > > https://github.com/aroig/zathura Thank you, I'll check it out. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] pkg-config is not happy with --atleast-version
On 2013-10-26 18:11:55, Abdó Roig-Maranges wrote: > > Hi, > > It seems that pkg-config complains when using --atleast-version together with > --cflags or --libs. I attach a patch. > > Abdó. > > From d01e128e7b4c2decb4d3a05e23b9b12cfda62879 Mon Sep 17 00:00:00 2001 > From: Abdo Roig-Maranges > Date: Sat, 26 Oct 2013 16:51:39 +0200 > Subject: [PATCH] pkg-config complains about --atleast-version > > pkg-config spits out > > Ignoring incompatible output option "--atleast-version" > > when using --atleast-version together with --cflags or --libs. What version of pkg-config gives that message? But yes, it's broken. It just get nothing at all. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Don't let links chose the zoom for you
Thank you, applied! -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] Fix issue 345 (http://bugs.pwmt.org/issue345)
Thank you, applied! -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] If the page is not cached, then this implies that it doesn't have a surface
On 2013-08-30 13:37:00, Sebastian Ramacher wrote: > On 2013-08-08 20:43:12, Sebastian Ramacher wrote: > > There are of course other ways to fix this. One of them would be to > > abort the rendering of the page if it becomes invisible and leaves the > > cache. However, implementing the necessary message passing for this is > > less trivial than just exposing this one function to check if a page is > > cached or not. > > I'm currently working on a different render infrastructure in the > features/renderer-take-2 branch. The setup is currently the following: > > - There is a ZathuraRenderer object that renders a page in a separate >thread. > - Every page widget holds a ZathuraRenderRequest object to manage >render requests. Widgets use this object to request a page to be >renderer and can also abort an request. > - ZathuraRenderRequest emits a signal as soon as the page is ready. > > There are somethings that are not done yet. The sorting of the render > requests is currently broken. > > In the end I hope it's enough to cancel pending requests in the caching > code and remove the workaround again. I've worked on this a bit the last few days and finally merged into develop. The caching logic is now in ZathuraRenderer and pages are notified via their associated ZathuraRenderRequest if they are cached or got removed from the cache. Pages will now release the surface themselves once they are not cached and not visible. There are still some workarounds that I'm not fully happy with and I'll probably end up implementing some signals for the visibility stuff to make things easier. Feedback is very welcome. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Re-mapping index navigation
On 2013-09-01 18:07:20, Keegan Carmichael wrote: > Thanks Sebastian. Collapse and Expand were the correct > options. > > I was using man zathurarc as a resource which did not list > those options. Thanks. I've added those to the manpage. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Re-mapping index navigation
On 2013-08-29 10:40:28, Keegan Carmichael wrote: > By default h,j,k,l move out,down,up,in, respectively, inside > the index. I'm trying to map these one step over to > j,k,l,;. > > I have found the function navigate_index with the option > up and down to work properly. So > > map [index] k navigate_index down > map [index] l navigate_index up > > work as expected. > > However, i have not found the option that allows me expand > and contract entries in the index. I have tried every > option possible for the navigate_index and none of them > work. What is the correct function-option pair for > contracting and expanding entries in the index? expand and collapse should work: map [index] j navigate_index collapse and so on. (Haven't actually tried it, just guessing the values from the source) Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH v2] Make the X clipboard buffer configurable
On 2013-08-31 06:18:31, Marwan Tanager wrote: > This patch adds a new configuration setting, selection-clipboard, which allows > us to choose between the PRIMARY selection, and the CLIPBOARD selection, for > determining which X clipboard to use for storing mouse-selected data. It has > only two valid values: "primary" and "clipboard", with "clipboard" being set > as > the it's default value. Thanks. Pushed with two changes: primary is still the default and the page widget now emits signals for text/image selection. zathura itself now has callbacks to handle this events. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] If the page is not cached, then this implies that it doesn't have a surface
On 2013-08-30 22:02:03, Marwan Tanager wrote: > On Fri, Aug 30, 2013 at 01:37:00PM +0200, Sebastian Ramacher wrote: > > On 2013-08-08 20:43:12, Sebastian Ramacher wrote: > > > There are of course other ways to fix this. One of them would be to > > > abort the rendering of the page if it becomes invisible and leaves the > > > cache. However, implementing the necessary message passing for this is > > > less trivial than just exposing this one function to check if a page is > > > cached or not. > > > > I'm currently working on a different render infrastructure in the > > features/renderer-take-2 branch. The setup is currently the following: > > > > - There is a ZathuraRenderer object that renders a page in a separate > >thread. > > - Every page widget holds a ZathuraRenderRequest object to manage > >render requests. Widgets use this object to request a page to be > >renderer and can also abort an request. > > - ZathuraRenderRequest emits a signal as soon as the page is ready. > > This sounds very cool! Nice work, Sebastian. > > > There are somethings that are not done yet. The sorting of the render > > requests is currently broken. > > I'm going to have a look at those rough edges at the nearest opportunity > (unless, of course, you reached there first!). The sorting should work again. > > In the end I hope it's enough to cancel pending requests in the caching > > code and remove the workaround again. > > Yes, once the infrastructure is in place, this is going to be a matter of a > trivial check. Great work, man. > > > -- > Marwan > ___ > zathura mailing list > zathura@lists.pwmt.org > http://lists.pwmt.org/mailman/listinfo/zathura -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] If the page is not cached, then this implies that it doesn't have a surface
On 2013-08-08 20:43:12, Sebastian Ramacher wrote: > There are of course other ways to fix this. One of them would be to > abort the rendering of the page if it becomes invisible and leaves the > cache. However, implementing the necessary message passing for this is > less trivial than just exposing this one function to check if a page is > cached or not. I'm currently working on a different render infrastructure in the features/renderer-take-2 branch. The setup is currently the following: - There is a ZathuraRenderer object that renders a page in a separate thread. - Every page widget holds a ZathuraRenderRequest object to manage render requests. Widgets use this object to request a page to be renderer and can also abort an request. - ZathuraRenderRequest emits a signal as soon as the page is ready. There are somethings that are not done yet. The sorting of the render requests is currently broken. In the end I hope it's enough to cancel pending requests in the caching code and remove the workaround again. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Can I "Go back to the last position of the document"?
On 2013-08-29 16:14:17, Marwan Tanager wrote: > Same problem. Shift + Insert just pastes the last clipboard contents before > selecting the text, ignoring the selected text which Zathura says that it > has been added to the clipboard Do you have anything running that messes with your clipboards? The PRIMARY selection is for middle mouse button / shift+insert, the CLIPBOARD slection for Ctrl+C/Ctrl-V. And we're using PRIMARY here. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Can I "Go back to the last position of the document"?
On 2013-08-29 15:53:31, Marwan Tanager wrote: > On Thu, Aug 29, 2013 at 3:36 PM, Sebastian Ramacher > wrote: > > > On 2013-08-28 22:07:42, Marwan Tanager wrote: > > > On Wed, Aug 28, 2013 at 11:30:48AM +0200, Moritz Lipp wrote: > > > > > > Hi. > > > > > > > > Personally, I have the same problem, and I don't know why it > > happens, so I > > > > > can't be very helpful on this one. > > > > > > > > This works just fine for me under Arch Linux. In zathura we use the > > PRIMARY > > > > selection which is conventionally used for copying and pasting. > > > > > > I use Zathura under Ubuntu, not Arch, but I don't know if this implies > > > anything. > > > > So I just tried it on Ubuntu (running Xfce), selected some text, used > > the middle mouse button to insert into a text editor and everything > > worked. > > > > Maybe we should make the buffer configurable? > > > > > I don't use the mouse. I paste using Ctrl-v after selecting the text (which > just pastes the last clipboard contents that don't belong to Zathura). > Actually, I don't have a mouse; only a touchpad, and I hate using it, and > don't know what the equivalent of the middle mouse botton would be on the > touchpad. Using Shift + Insert should have the same effect as using the middle mouse button (provided I'm not confusing the dfiffernt clipboards). > In Zathura, I expect everything to be doable by the keyboard, which, I > think, is what it is good at, and the reason why I love using it. > ___ > zathura mailing list > zathura@lists.pwmt.org > http://lists.pwmt.org/mailman/listinfo/zathura -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Can I "Go back to the last position of the document"?
On 2013-08-28 22:07:42, Marwan Tanager wrote: > On Wed, Aug 28, 2013 at 11:30:48AM +0200, Moritz Lipp wrote: > > Hi. > > > > Personally, I have the same problem, and I don't know why it happens, so I > > > can't be very helpful on this one. > > > > This works just fine for me under Arch Linux. In zathura we use the PRIMARY > > selection which is conventionally used for copying and pasting. > > I use Zathura under Ubuntu, not Arch, but I don't know if this implies > anything. So I just tried it on Ubuntu (running Xfce), selected some text, used the middle mouse button to insert into a text editor and everything worked. Maybe we should make the buffer configurable? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Girara statusbar and inputbar fixes for GTK3
Hi, On 2013-08-23 14:29:39, Abdó Roig-Maranges wrote: > > I've attached two screenshots of zathura 0.2.4 running with girara 0.1.6 > > and girara 0.1.7 plus the patch. With girara 0.1.6 there is a lot more > > padding around the text in the statusbar and it's readable (maybe the > > status bar is just too small in 0.1.7 and it's not the padding after > > all, I don't know). > > Ok, I don't see the same thing on my end. It may be due to the fact that I > use a > larger font, I don't know... For me the statusbar has a reasonable padding, > and > exactly the same height as the inputbar in both, GTK3 and GTK2. > > Anyway, I attach another patch that does two things: > > 1. Adds config settings statusbar-h-padding and statusbar-v-padding to set the >padding for status, input and notification bars. Defaults are > >statusbar-h-padding 8 >statusbar-v-padding 2 > >The value means total padding, for instance, 8 = 4 (left) + 4 (right). If > you >don't like those defaults, they can be adjusted in config.c, of course. > > > 2. Remove a hack for setting the statusbar height, that I suspect was the > source >of trouble. Now instead of set_size_request on the statusbar_entries GtkBox >object, we set the padding on the individual statusbar items, as it was > done >before my GTK3 commits. > > After this patch, the padding on status, notification and input bars should be > adjustable via config, and all 3 bars should be rendered exactly with the same > height. Thanks for the quick fix! That's very much appreciated. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Girara statusbar and inputbar fixes for GTK3
On 2013-08-22 14:15:55, Abdó Roig-Maranges wrote: > > Oops, sorry about that... > > > > One of the bugs caused by the changes is http://bugs.pwmt.org/issue338. > > I attach a patch fixing the :info thing. A bit of a hack remains to set the > statusbar height the same as the inputbar (session.c lines 284-291). Do you > know > of a better solution? The notification box should be fine now. Thank you. That's fixed, yes. > > > Also, the padding doesn't look right. > > I have changed a few lines regarding horizontal padding (add the same amount > of > padding left and right). I don't think this is what you meant though. Could > you > elaborate? It looks fine to me. I've attached two screenshots of zathura 0.2.4 running with girara 0.1.6 and girara 0.1.7 plus the patch. With girara 0.1.6 there is a lot more padding around the text in the statusbar and it's readable (maybe the status bar is just too small in 0.1.7 and it's not the padding after all, I don't know). I hope the images are large enough. Regards -- Sebastian Ramacher <><>___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Girara statusbar and inputbar fixes for GTK3
Hi, maybe it was a bit to early to merge this changes. The statusbar now doesn't work correctly anymore in GTK2. One of the bugs caused by the changes is http://bugs.pwmt.org/issue338. Also, the padding doesn't look right. Could you maybe take a look at that? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Fix zathura's bisect
Separating the bisection code a little bit more from the jump list is
properly a code idea. I took the opportunity to rewrite it a little bit
and came up with the attached patch. What do you think of it?
* It moves some state to zathura_t: start and end denote the range that
is bisected. last_jump is used to determine if this is a new
bisection or if one is continued.
* sc_bisect now determines first if we continue or start a bisection.
If it's a new bisection, it gets the previous two jump list entries
to determine the bounds.
* Then it calculates the new position based on the current page and the
bisection range.
I have tried a few bisection sequences and probably broke some cases
that I didn't think of, so I appreciate feedback. Also, the code to
detect the start of a new bisect run is a bit hacky and could use some
improvement.
Cheers
--
Sebastian Ramacher
diff --git a/shortcuts.c b/shortcuts.c
index bfb4cf3..44295a3 100644
--- a/shortcuts.c
+++ b/shortcuts.c
@@ -19,6 +19,14 @@
#include "page-widget.h"
#include "adjustment.h"
+#ifndef MIN
+#define MIN(a,b) (((a)<(b))?(a):(b))
+#endif
+
+#ifndef MAX
+#define MAX(a,b) (((a)>(b))?(a):(b))
+#endif
+
/* Helper function; see sc_display_link and sc_follow. */
static bool
draw_links(zathura_t* zathura)
@@ -786,123 +794,146 @@ sc_bisect(girara_session_t* session, girara_argument_t* argument,
g_return_val_if_fail(argument != NULL, false);
g_return_val_if_fail(zathura->document != NULL, false);
- unsigned int number_of_pages, cur_page, prev_page, prev2_page;
- bool have_prev, have_prev2;
-
- zathura_jump_t* prev_jump = NULL;
- zathura_jump_t* prev2_jump = NULL;
-
- number_of_pages= zathura_document_get_number_of_pages(zathura->document);
- cur_page = zathura_document_get_current_page_number(zathura->document);
-
- prev_page = prev2_page = 0;
- have_prev = have_prev2 = false;
+ const unsigned int num_pages = zathura_document_get_number_of_pages(zathura->document);
+ const unsigned int cur_page = zathura_document_get_current_page_number(zathura->document);
/* process arguments */
int direction;
- if (t > 0 && t <= number_of_pages) {
-/* jump to page t, and bisect between cur_page and t */
-zathura_jumplist_add(zathura);
-page_set(zathura, t-1);
-zathura_jumplist_add(zathura);
-if (t-1 > cur_page) {
+ if (t > 0 && t <= num_pages) {
+/* bisect between cur_page and t */
+t -= 1;
+if (t == cur_page) {
+ /* nothing to do */
+ return false;
+}
+else if (t > cur_page) {
+ zathura->bisect.start = cur_page;
+ zathura->bisect.end = t;
direction = BACKWARD;
} else {
+ zathura->bisect.start = t;
+ zathura->bisect.end = cur_page;
direction = FORWARD;
}
-
} else if (argument != NULL) {
direction = argument->n;
- } else {
-return false;
- }
+zathura_jump_t* jump = zathura_jumplist_current(zathura);
+if (jump == NULL) {
+ girara_debug("bisecting between first and last page because there are no jumps");
+ zathura->bisect.start = 0;
+ zathura->bisect.end = num_pages - 1;
+} else {
+ if (jump->page != cur_page || jump->page != zathura->bisect.last_jump) {
+girara_debug("last jump doesn't match up, starting new bisecting");
+zathura->bisect.start = 0;
+zathura->bisect.end = num_pages - 1;
- cur_page = zathura_document_get_current_page_number(zathura->document);
+/* check if we have previous jumps */
+if (zathura_jumplist_has_previous(zathura) == true) {
+ zathura_jumplist_backward(zathura);
+ jump = zathura_jumplist_current(zathura);
- if (zathura_jumplist_has_previous(zathura)) {
-/* If there is a previous jump, get its page */
-zathura_jumplist_backward(zathura);
-prev_jump = zathura_jumplist_current(zathura);
-if (prev_jump) {
- prev_page = prev_jump->page;
- have_prev = true;
-}
+ unsigned int prev_page = 0;
+ unsigned int prev_page2 = num_pages - 1;
+ if (jump != NULL) {
+prev_page = jump->page;
+ }
-if (zathura_jumplist_has_previous(zathura)) {
- /* If there is a second previous jump, get its page. */
- zathura_jumplist_backward(zathura);
- prev2_jump = zathura_jumplist_current(zathura);
- if (prev2_jump) {
-prev2_page = prev2_jump->page;
-have_prev2 = true;
+ prev_page2 = prev_page;
+ if (zathura_jumplist_has_previous(zathura) == true) {
+zathura_jumplist_backward(zathura);
+jump = zathura_jumplist_current(zathura);
+if (jump != NULL) {
+ prev_page2 = jump->page;
+}
+zathura_jumplist_forward(zathura);
+ }
+ zathura_jumplist_forward(z
Re: [zathura] [Zathura PATCH 1/2] Use show-v-scrollbar instead of show-scrollbars
Thanks, applied. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] unable to save a pdf
Hi, On 2013-05-16 10:04:03, rudolf.syk...@gmail.com wrote: > I just tried to use zathura for the 1st time. > > What I need is to be able to save a viewed document. > When I issue > :write /home/ruda/a.pdf > zathura says the document has been saved, but it really has not. Which PDF plugin are you using? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Correctly handle archive_read_data_block() returning a size of 0
On 2013-05-15 21:47:02, akbjker # wrote: > Which subsequently causes g_malloc0 to fail and return NULL. Can size be 0 at all? Anyway, applied. Thanks. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] The bug tracker mail interface.
On 2013-04-17 22:13:30, Marwan Tanager wrote: > I was curious to know if it is possible to add comments on bugs at > bugs.pwmt.org by replying to messages received as a result of adding myself > to > the nosy list of a particular bug. Is this possible? > > I've just did that on the bug at http://bugs.pwmt.org/issue274, but the reply > didn't seem to end up as a comment on the web page. If I remember correctly, roundup has a mail interface but I don't know if it has been set up for this instance. Maybe try to contact Moritz, he'll know the details. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Change zathuras display mode to single page only
On 2013-04-22 16:21:13, Manuel wrote: > I recently switched from Debian to Arch. Now I have a newer version > of zathura, which displays the pages continuously. For poppler as > well as mupdf. I need the discrete display mode. Is there a way to > edit the configs to change this behaviour? At the moment not. There is a open feature request [1] about that but nobody hat the time to implement it in the post 0.1.x interface. Regards [1] I always forget the bug number but it should be easy to find. If you're interested, patches are very welcome. -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Color of notification about selected/to-be-clipboard-copied text
On 2013-04-08 13:52:28, Sebastian Ramacher wrote: > Hi, > > On 2013-04-04 22:08:37, daspostl...@googlemail.com wrote: > > after having had to re-install my entire system, I now probably > > have a much newer version of zathura and the following new problem: > > > > When selecting text to be copied to the clipboard, the notification > > line (or whatever you call it) which used to show me the selected > > text seems to have black text on black background, or some other > > problem; in any case I cannot see the text, and perhaps am missing > > other notifications. No config option I tried seemed to fix this. My > > zathurarc is pasted below. Selecting and pasting in itself works, > > just not the information on what I selected. > > I get black text on a white background with your config. Probably we're > just not setting the color of the statusbar if it's an info > message. I'll look into that. The settings are just undocumented: notification-fg and notification-bg are used for info messages. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Color of notification about selected/to-be-clipboard-copied text
Hi, On 2013-04-04 22:08:37, daspostl...@googlemail.com wrote: > after having had to re-install my entire system, I now probably > have a much newer version of zathura and the following new problem: > > When selecting text to be copied to the clipboard, the notification > line (or whatever you call it) which used to show me the selected > text seems to have black text on black background, or some other > problem; in any case I cannot see the text, and perhaps am missing > other notifications. No config option I tried seemed to fix this. My > zathurarc is pasted below. Selecting and pasting in itself works, > just not the information on what I selected. I get black text on a white background with your config. Probably we're just not setting the color of the statusbar if it's an info message. I'll look into that. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] RFC
On 2013-04-02 21:45:44, Sebastian Ramacher wrote: > > > Also, I thought a while ago, that zathura's rendering experience could > > > be even further enhanced by caching the pages, which have not been seen > > > yet. For example at one moment we see a row of pages and zathura caches > > > the row above and below the one we currently view. Then if we scroll in > > > either direction, the page is already rendered, which might be visually > > > more pleasing than waiting for a large page to come up. Of course, this > > > should be implemented in such a way, that we do not recache the pages, > > > which are already among the ones which have been looked at recently. > > > > That's exactly what I've just been thinking about, simply a sliding window > > of a > > configurable number of rows centered at the current visible one and moving > > with > > us as we scroll around. > > > > Combined with the above caching, then pages outside of this window > > shouldn't be > > freed unless they 1) aren't in the cache, or 2) are in the cache, but need > > to > > be invalidated in order to make room for the currently visible ones if they > > aren't already in the cache. > > That'd be nice to have. Instead of a configurable number of rows we'd need > something that also loads pages left and right of the current page if > pages-per-row is larger than 1. JFTR: that's http://bugs.pwmt.org/issue267. -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] RFC
On 2013-03-25 04:14:25, Marwan Tanager wrote: > > Also, I remember, that I hit a mem-leak recently when working on a > > poster made with LaTeX. I was recompiling the same page over and over > > again with LaTeX and I the memory consumption went very high. I was > > wondering if this is because zathura was remembering the pages from the > > previous versions of the recompiled document. Maybe zathura should free > > memory on document reloads? > > Yes, this is an actual bug that is reported at http://bugs.pwmt.org/issue274 > and it should be fixed. Maybe you're the one who reported it! Everything except the file monitor and the zathura_t instance should be released and re-created (if I remember that correctly), i.e. the document gets closed and re-opened again. zathura is just a PITA to run with valgrind. There are so many GTK related errors, that we can't fix, that valgrind's output is pretty much useless. We might have missed a free, g_object_unref, etc. somewhere of course. So ideas to find memory leaks without valgrind or a use-able suppression file for valgrind are very welcome. > > Also, I thought a while ago, that zathura's rendering experience could > > be even further enhanced by caching the pages, which have not been seen > > yet. For example at one moment we see a row of pages and zathura caches > > the row above and below the one we currently view. Then if we scroll in > > either direction, the page is already rendered, which might be visually > > more pleasing than waiting for a large page to come up. Of course, this > > should be implemented in such a way, that we do not recache the pages, > > which are already among the ones which have been looked at recently. > > That's exactly what I've just been thinking about, simply a sliding window of > a > configurable number of rows centered at the current visible one and moving > with > us as we scroll around. > > Combined with the above caching, then pages outside of this window shouldn't > be > freed unless they 1) aren't in the cache, or 2) are in the cache, but need to > be invalidated in order to make room for the currently visible ones if they > aren't already in the cache. That'd be nice to have. Instead of a configurable number of rows we'd need something that also loads pages left and right of the current page if pages-per-row is larger than 1. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] g_param_spec_int64 commit segfaults on my machine
Hi, On 2013-04-01 21:28:51, Abdó Roig-Maranges wrote: > The last commit in zathura's develop branch (1a145c5166cd834, "Use the > 64-bit variants of g_param_spec_int ...) segfaults on my machine. I'm > running Arch with gcc 4.7.2 and gtk 2.24.17. that should be fixed. > By the way, I posted some new issues (patches) on your bug tracker. Only > after posting there I realized you may prefer the mailing list :) They are on my TODO list for today. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH v2] Replace the periodic page reclaiming code with a LRU caching algorithm.
> > Thanks. I've applied it with an additional check if the user-specified page > > size is positive. (Just in case someone thinks -1 is a good cache size > > and the code would allocate an array of INT_MAX integers). > > Great! > > I think you meant the user-specified cache size, not page size. Of course, I did. -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH v2] Replace the periodic page reclaiming code with a LRU caching algorithm.
On 2013-03-26 05:50:22, Marwan Tanager wrote: > This patch implements a page cache that is invalidated in a LRU fashion. > > Pages are added to the cache as soon as they become visible. When the cache > is > full and a new page that isn't in the cache becomes visible, the least > recently > viewed page in the cache is evicted from memory and the new one takes it's > place. > > The cache size is configurable using the page-cache-size configuration > variable, with a default value of 15 pages. Very large values for the cache > size are not recommended, though, as it will stress the system memory out. > > The old periodic page reclaiming code is no longer necessary with this patch, > so I removed it. Thanks. I've applied it with an additional check if the user-specified page size is positive. (Just in case someone thinks -1 is a good cache size and the code would allocate an array of INT_MAX integers). Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Mappings with numeric counts
On 2013-03-24 19:15:02, gi1242+zath...@gmail.com wrote: > Hi All, > > I'd like to map a "H" to "scroll left 20 times" (i.e. pressing "H" > should be the equivalent of pressing "20h" after the numeric count patch > has been applied). > > Do you know if this is possible? What syntax should I use to pass a > count. Doing > > map H scroll left 20 I don't know if it's possible to do that without feedkeys, but that should do the trick: map H feedkeys 20h Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
