Re: [zathura] [PATCH] ps: fix 'make uninstall' command
On 10/06/2011 03:09 PM, Pavel Borzenkov wrote: > 'make uninstall' should remove the 'plugin' directory only if it's > empty. > > Also, this patch adds .gitignore file. Thanks, applied. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Fix warnings reported by Clang Analyzer
On 10/19/2011 08:24 AM, Pavel Borzenkov wrote:
> Clang Analyzer reports:
>
> shortcuts.c:238:11: warning: Value stored to 'new_value' during its
> initialization is never read
> gdouble new_value = value;
> ^ ~
>
> completion.c:163:50: warning: Null pointer passed as an argument to a
> 'nonnull' parameter
> if (input_length <= strlen(bookmark->id) && !strncmp(input, bookmark->id,
> input_length)) {
Thank you, applied.
Regards
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Get file info earlier
On 10/20/2011 03:55 PM, Pavel Borzenkov wrote: > We need to know the document's 'scale' value earlier (before cairo > surfaces are created). Otherwise, cairo surfaces will be re-created and > wrong page will be rendered (since zoom doesn't preserve page number). > > Signed-off-by: Pavel Borzenkov Thank you for the patches. I will have a look at them tomorrow. Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Get file info earlier
On 10/20/2011 05:33 PM, Sebastian Ramacher wrote: > On 10/20/2011 03:55 PM, Pavel Borzenkov wrote: >> We need to know the document's 'scale' value earlier (before cairo >> surfaces are created). Otherwise, cairo surfaces will be re-created and >> wrong page will be rendered (since zoom doesn't preserve page number). >> >> Signed-off-by: Pavel Borzenkov > > Thank you for the patches. I will have a look at them tomorrow. Applied. Thanks again. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Fix build warning
On 10/24/2011 08:38 AM, Pavel Borzenkov wrote: > The patch fixes the following warning: > > document.c: In function ‘guess_type’: > document.c:174: warning: implicit declaration of function ‘read’ Thank you, applied. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Synctex support
Hi Roland, since 0.1.0 is out now, I'd like to get things going again and start working on synctex support. On 22/08/11 14:22, Roland Schatz wrote: > If you're interested, integrating it back into mainline should be easy, > since it's based on a recent GIT snapshot. I have no clue about the > legal stuff, so just in case, you have my permission to do with my > patches whatever you want :). As zathura has undergone major changes we can't just merge it. Are you interested in porting synctex support to 0.1.0? If you need any help I'm available to guide you through the new code. Cheers ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] zathura 1.1
On 13/03/12 09:22, Swiatoslaw Gal wrote: > Do you have any idea what do I do wrong? Here is the pdf: > > http://deferentialgeometry.org/papers/Semi-Simple%20Lie%20Algebras%20and%20Their%20Representation.pdf I can view this document with out problems. Could you please post zathura's output? ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] autoreload doesn't save page position
On 03/04/12 15:59, Spencer Liang wrote: > The autoreload feature (ie, when working with latex) does not save the > current page position. When zathura loads the new pdf, it remembers what > page it was on before, but not the position within that page; instead, it > moves the view back to the top of the page. Yes, that's a known issue. We just save the page number and not the position relative to the page. Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] page-width/height does not stay in place
On 13/03/12 11:42, Swiatoslaw Gal wrote: > I am browsing >700 page dvju file. > > I go to the page 505 (505G) > and then I switch to page-width (s) > and I find myself around page 163. > (Although the statusbar shows it only > when I hit something, eg. an arrow). > I go again to 505 (505G) and > switch to page-height (a) and > I am at the end of the book. > > Is it meant to be this way? No, it isn't. Please create a bug report for this issue (assuming it still exists). Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] page-width/height does not stay in place
On 07/04/12 17:13, Swiatoslaw Gal wrote: >> No, it isn't. Please create a bug report for this issue (assuming it still >> exists). > > It does not. Fixed since 1.2. Fine. > For the future, it would be easier if you would point for a reference how to > create bug reports. Well, there is a "BUG TRACKER" link on the web site. But anyway, the bug tracker is located at http://bt.pwmt.org. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] gzipped files
On 07/04/12 22:03, Swiatoslaw Gal wrote: > Is there another way to view gzipped postscript files > with zathura then unpacking them first? You can do somethinkg like that: $ zcat $file | zathura - But zathura then saves the uncompressed file somewhere. At the moment zathura is not able to open compressed files by itself. Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] zathura does not render background
On 24/04/12 19:43, henry atting wrote: > I realize a strange behaviour when opening this file[1] with > zathura. I takes about 15 sec. to load it in the first place, finally the > background is not displayed. This happens with 0.1.2.2 from the debian > repository and with zathura built from git as well. It looks the same to me in any poppler-glib based PDF viewer. So maybe this is a poppler-glib bug. Okular seems to display it correctly. > Using the mupdf plugin makes it worse - zathura fails to render the > text color (red = red). This should by fixed by [1]. Regards [1] http://git.pwmt.org/?p=zathura-pdf-mupdf.git;a=commit;h=3c6462172aa3ad9f5a3ab788d59ae7efe6fc28a4 ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Memory usage
On 13/05/12 13:29, Quoc-Viet Nguyen wrote: > I have just upgraded from zathura 0.0.8.5 to 0.1.2 (from Debian Wheezy > repository) and I noticed that the using memory is significantly > increased. Yes, that's expected. There are more widgets and pages displayed at once so that takes up more memory. zathura holds pages in memory that have been recently displayed so that faster scrolling is possible. Pages that haven't been displayed for some time are purged from the memory. > A 9-page pdf of text now takes more than 200MB (VSZ in `ps u`) Please take a look at RSS and SZ. This should give you a better idea how much memory is used. VSZ is 200 MiB even with no document open so isn't useful here at all. VSZ stays the same here even if I open a 100 page document here. > Is it normal in the new version? I see another bug report [1] about > the excessive memory but it is closed. I'll soon test the development > version. Please do so. If you find any memory leaks please report them at http://bt.pwmt.org. Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Czech localization
On 19/06/12 14:58, Martin Pelikan wrote: > I'll try to attach UTF-8-encoded first attempt on translating Zathura > into Czech. Some stuff is omitted simply because I have no clue what > is it for... Thank you. Commited. Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Localization
On 24/06/12 19:41, artur wrote: > My update an existing Polish translation file pl.po zathura . Thanks, applied. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Options for consistent horizontal adjustments.
On 29/05/12 15:09, Julian Orth wrote: > I propose three new options for > 1) horizontal scrolling, > 2) zooming > 3) searching when zoomed in. > See the attachment for the details. Sorry for the long delay. Applied with the changes needed to work with current develop. Kind regards. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] synctex backwards syncronization
Hi Roland, thanks for you work. The patch looks good so far. Just two minor remarks in synctex_edit: * Could you please use g_strdup_printf instead of a fix sized buffer? * For consistency with all the other parts in girara and zathura that spawn process please use something like g_spawn_sync to execute synctex. Cheers ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] synctex backwards syncronization
On 13/07/12 15:30, Roland Schatz wrote: > New patch is attached. Thanks. Commited and pushed. Regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] synctex backwards syncronization
One more think that just came to my mind: could you document -s and -x in zathura.1.rst? A section on how to use synctex would be nice there as well. Cheers ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] synctex backwards syncronization
On 13/07/12 15:58, Roland Schatz wrote: > That reminds me: I forgot to mention that the two new strings in the the > --help output should probably be added to the intltool files and > translated. I have to make myself familiar with intltool before I can do > that, and I'd need a bit of help with any language that isn't German :P Just run make update-po. This will update all the translation files and you can then update the German one. Cheers ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Link appearance
On 28/07/12 13:37, Pierre-Jean wrote: > If zathura adds this blue border, could it be possible to > add an option to configure this (disable it, or change the > color)? Have a look at the options named highlight-foo. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Link appearance
On 28/07/12 15:21, Pierre-Jean wrote: > Are you sure that zathura draw this blue box? Oh, I think I misunderstood you. Those are drawn by poppler. > Last but not least, I tried to change highlight-color and > highlight-active-color, but with no result. My config file > is as follow: > > set default-bg #AD3DA1 > set highlight-color #AD3DA1 > > After a speed test, it seems that none of the color options > are working, neither highlight-transparency (which seems to > not understand floating points). Strings starting with # need to be enclosed in " or # needs to be escaped. # start a comment. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Link appearance
On 29/07/12 12:43, Pierre-Jean wrote: > Obviously... Maybe that a line about that could be added in > zathurarc(5). That's already mentioned in the description. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH]: Fix resizing when page-per-row is anything but 1.
On 16/07/12 22:58, Ignas Anikevicius wrote: > This is my first patch being sent here. I found a bug, which manifests > itself when one presses 'a'. The bugtracker has a bug (#226) on > related issue, but it's not exactly the same. Thanks for the patch, applied. ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] synctex forward synchronization
First of all thanks for the patch and I'm sorry that I didn't have the time to look at the patch yet. On 14/08/12 13:05, Roland Schatz wrote: > The big open question: > How do you connect that feature to a text editor? > > My personal solution to this is a vim-script that uses xdotool to > simulate keypresses that issue the :synctex command. But that seems like > a big ugly hack. A better solution would be to somehow make it possible > to send remote commands to zathura, similar to "vim --remote". But I > have no idea how "vim --remote" is implemented, I have to do more > research. I'm not sure whether it is possible to implement that in a > platform independent way... What about a dbus interface? Apparently there is a Glib binding for dbus. The editor could send the messages to zathura via dbus-send. Another possibility would be an XML-RPC interface but I didn't check if there are any good and easy-to-use libraries for that. Kind regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] copy to clipboard
Hi, On 28/08/12 16:38, philomath wrote: > When selecting text in a PDF, it is copied to the "primary selection", not to > the clipboard (I can't just Ctrl-V it into a text editor, I end up using > xsel...). is there a way to change that? It's not possible to change that right now. If you're familiar with GTK+ you can have a look at page-widget.c:638 and change the gtk_clipboard_get call there. Patches to make that configurable are very welcome. Kind regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] sample/default config
On 05/09/12 17:46, Ramana Kumar wrote: > Would it be possible to move all or most of config.c into an rc file? > > Any reasons not to do that? Speed might be an issue, but maybe not: would > need to measure. config.c does a lot of things that aren't possible in the rc file. And for the rest I don't want them in an rc file and not in config.c. zathura should provide a usable default user experience even without a rc file. > Doing so would be great for documentation purposes, at least: it makes it > easy to see what the default settings are, and also to tweak things. > > A halfway option would be to generate some documentation of the "default > settings" and put it on the webpage and/or in a manpage. There is zathurarc(5) and [1,2] with all options, their type and default value. Kind regards [1] http://pwmt.org/projects/zathura/options/ [2] http://pwmt.org/projects/girara/options/ ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] sample/default config
On 05/09/12 18:17, Ramana Kumar wrote: > Do any of those tell me the default key for the "best-fit" function, for > example? > Or indeed any of the default key mappings. That's in zathura(1). ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 1/2] Add full page scroll overlap setting
Hi Jonas, thanks for the patch. I've applied it. Could you please provide a patch for zathurarc.5.rst describing the new setting? Kind regards ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 2/2] Introduce page aware scrolling
Hi Jonas, On 2012-09-15 18:56:59, Jonas Hörsch wrote: > feels a lot better to me, the idea came from the default pagewise > scrolling in djview4 (on and ). It feels good to me as well. A patch for zathurarc.5.rst would be great. Cheers ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] documentation for new scroll options (was: [PATCH 2/2] Introduce page aware scrolling)
On 2012-09-17 23:36:13, Jonas Hörsch wrote: > > A patch for zathurarc.5.rst would be great. > attached for both Thanks. Applied except for the following part: > window-width > > -Defines the window width on startup > +Defines the window width on steeartup > > * Value type: Integer > * Default value: 800 ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] add shortcut mappings for jumplist to make it configurable
Thanks for the patch. Applied. -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 1/2] Add full page scroll overlap setting
Hi Jonas, On 2012-09-15 18:56:54, Jonas Hörsch wrote: > just mail me if you require me to adapt/change anything. Moritz noticed that the patch breaks full page scrolling with . Therefore the default value is now set to 0. It'd be great if you could have a look at it. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 1/2] Add full page scroll overlap setting
Hi Jonas, On 2012-09-19 23:42:19, Jonas Hörsch wrote: > is there a bug report or more info, what doesn't behave as expected > anymore? No, there is no bug report. > the only interpretation, i could come up with, is: given that in "best > fit"-adjust mode the page height matches the view height exactly, > previously pressing space just replaced the page, now it doesn't do so > anymore. using page up/down though provides exactly the old > functionality in this border case. Exactly. Would it be possible to cover that case somehow? So that if the page fits exactly, a full page is scrolled. In fullscreen mode this is really annoying as I won't reach for page up/down during a presentation and just want to hit space to go to the next slide. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Spanish translation
On 2012-10-05 10:36:18, Alvaro Ramiro wrote: > Hi. My name is Alvaro Ramiro. I completeed the translation into Spanish. > The es.po file is attached. Thanks, applied. -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Updating page number on internal link jump
Hi Attila, On 2012-10-27 14:10:01, Attila Sztupák wrote: > I've found a similar issue like http://bugs.pwmt.org/issue43: the page > number wasn't updated when jumping using the index, so the next J/K > key navigates to the next/prev page relative to the page before index > was loaded. which version of zathura are you using? I can't reproduce the issue with the version from the develop branch so maybe this issue is already fixed. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [issue273] [PATCH] Fix the "n=" shortcut to zoom to size n
Hi Benoît, On 2012-12-06 09:46:24, Benoît Knecht wrote: > No matter what the value of n was, the "n=" shortcut would set the zoom > value to 100%. It is now set to n% instead. Thanks for the patch. Applied Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [issue273] [PATCH] Fix the "n=" shortcut to zoom to size n
On 2012-12-06 20:32:21, Sebastian Ramacher wrote: > Thanks for the patch. Applied Also thanks for the other patches. I've applied them too. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Add new shortcut function to display links
On 2012-12-08 00:30:55, Benoît Knecht wrote: > It's the same patch as the one I submitted to the bug tracker [1] (but > rebased on the latest develop branch, not sure it makes any difference > here). I'm submitting it to the mailing list because I feel it's more > convenient that way, but please let me know if the bug tracker is the > preferred way of submitting patches. Both ways are fine. If it should happen that we miss a patch on bug tracker, a ping on the mailing list is appreciated of course. Thanks again for all the patches. I've just pushed the this one. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Update the shortcut functions list in documentation
On 2012-12-08 17:00:26, Benoît Knecht wrote: > Also alphabetize the shortcut functions declarations in code, to make it > easier to keep the documentation and code in sync. > --- > config.c|4 ++-- > zathurarc.5.rst |6 +++--- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/config.c b/config.c > index 73327ed..8ba4f71 100644 > --- a/config.c > +++ b/config.c > @@ -384,11 +384,11 @@ config_load_default(zathura_t* zathura) >girara_shortcut_mapping_add(gsession, "adjust_window", > sc_adjust_window); >girara_shortcut_mapping_add(gsession, "change_mode", sc_change_mode); >girara_shortcut_mapping_add(gsession, "display_link", > sc_display_link); > - girara_shortcut_mapping_add(gsession, "jumplist", sc_jumplist); >girara_shortcut_mapping_add(gsession, "follow",sc_follow); >girara_shortcut_mapping_add(gsession, "goto", sc_goto); > - girara_shortcut_mapping_add(gsession, "navigate_index", > sc_navigate_index); > + girara_shortcut_mapping_add(gsession, "jumplist", sc_jumplist); >girara_shortcut_mapping_add(gsession, "navigate", sc_navigate); > + girara_shortcut_mapping_add(gsession, "navigate_index", > sc_navigate_index); >girara_shortcut_mapping_add(gsession, "print", sc_print); >girara_shortcut_mapping_add(gsession, "quit", sc_quit); >girara_shortcut_mapping_add(gsession, "recolor", sc_recolor); > diff --git a/zathurarc.5.rst b/zathurarc.5.rst > index ff54c8f..756874f 100644 > --- a/zathurarc.5.rst > +++ b/zathurarc.5.rst > @@ -207,17 +207,17 @@ The following shortcut functions can be mapped: > change_mode Change current mode > display_link Display link target > followFollow a link > -focus_inputbarFocus inputbar > goto Go to a certain page > -index_navigateNavigate through the index > +jumplist Move forwards/backwards in the jumplist > navigate Navigate to the next/previous page > +navigate_indexNavigate through the index > +print Show the print dialog > quit Quit zathura > recolor Recolor the pages > reloadReload the document > rotateRotate the page > scrollScroll > search Search next/previous item > -set Set an option The mappings for set and focus_inputbar are definied in girara. But it's probably better to overwrite the mapping for focus_inputbar with the shortcut from zathura anyway. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Declare missing shortcut functions and document them
Thank you again for all the patches. I've applied them and re-added set to the list of shortcut functions. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Fixed reverse searching behaviour to be more like less/vi
Looks good to me now. Thanks for the patch. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
Hi Diego, On 2013-01-29 12:41:13, Diego Joss wrote: > I have had issues with with g_content_type_guess guessing wrong on > some pdfs (it would return "text/plain" or > "application/octet-stream"). Thus here is a patch against 0.2.2 wich > replaces the use of g_content_type_guess with libmagic in guess_type > (document.c:518). thanks for the patch. Could you please change it in a way such that if libmagic is not available, the existing code is used? It could be done the same way as with sqlite3. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
On 2013-01-29 21:11:02, Benoît Knecht wrote:
> Hi Diego,
>
> Diego Joss wrote:
> > I have had issues with with g_content_type_guess guessing wrong on
> > some pdfs (it would return "text/plain" or
> > "application/octet-stream"). Thus here is a patch against 0.2.2 wich
> > replaces the use of g_content_type_guess with libmagic in guess_type
> > (document.c:518).
>
> It would also be great if you could do localization on the message
> strings (using "_()"). It doesn't look like any of the girara_warning
> strings in zathura are localized, but I don't see any reason why not.
I think we decided to keep all the girara_{info,debug,warning,error}
messages unlocalized since they are only meant to be additional info.
Proper error messages should be displayed with girara_notify. There are
enough places where that's not the case, though.
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
On 2013-01-30 00:28:51, Diego Joss wrote: > regarding the fallback solution (as is done for the database), I will > be glad to implement it, however I won't have time before this > weekend. Sure, no problem. Thanks for your work on this! Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
On 2013-01-29 22:21:48, Benoît Knecht wrote: > Do you think it would be worth localizing all those strings, or do you > prefer to stick with the way things are now? I'd rather stick with the way things are now and improve the user visisble error messages in the GUI. Maybe Moritz has a different opinion on that. Maybe there are some messages that would be useful to the user, though. Someone would need to go through the code and decide which are and which are not. Those which not useful to the user should be demoted to girara_debug and then we can talk about the remaining strings. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
Hi Diego, On 2013-01-30 00:28:51, Diego Joss wrote: > regarding the fallback solution (as is done for the database), I will > be glad to implement it, however I won't have time before this > weekend. I just wanted to check if you already had time to implement the new patch. Just let me know if I should just apply your first patch and add the fallback myself. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
On 2013-01-29 12:41:13, Diego Joss wrote: > + int flags = > +MAGIC_MIME_TYPE | > +MAGIC_SYMLINK | > +MAGIC_NO_CHECK_APPTYPE | > +MAGIC_NO_CHECK_CDF | > +MAGIC_NO_CHECK_ELF | > +MAGIC_NO_CHECK_ENCODING; > + magic_t magic = > magic_open(MAGIC_MIME_TYPE|MAGIC_SYMLINK|MAGIC_NO_CHECK_APPTYPE|MAGIC_NO_CHECK_CDF); While applying your patch I noticed that the flags are unused. I think you wanted to pass them to magic_open. Is that correct? Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
Hi On 2013-02-07 23:55:50, Diego Joss wrote: > On Thu, Feb 7, 2013 at 1:30 AM, Sebastian Ramacher > wrote: > > Hi Diego, > > > > On 2013-01-30 00:28:51, Diego Joss wrote: > >> regarding the fallback solution (as is done for the database), I will > >> be glad to implement it, however I won't have time before this > >> weekend. > > > > I just wanted to check if you already had time to implement the new patch. > > Just > > let me know if I should just apply your first patch and add the fallback > > myself. > > Sorry for the delay, I still haven't had time to. I was hoping to > implement the fallback this weekend, however if you prefer to already > apply the patch it may be faster :-). No problem. I've applied it and done that other modifications myself. Thanks! Cheers -- 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] Pass hadjustment to set_adjustment() instead of vadjustment.
Thanks, applied. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 0/4] Some assorted stuff
Hi Ignas, first of all, thanks for the patches. On 2013-02-08 16:34:03, Ignas Anikevičius wrote: > Subject: [PATCH 1/4] Set the horizontal scroll step > > Previously it was set to -1, which was essentially disabling the > horizontal scrolling. This enables the scrolling by default by setting > it to be the same as the vertical scrolling. > > Signed-off-by: Ignas Anikevicius (gns_ank) Looks good to me. > From 834d5d41aa7c36462348a293a28c5a7d02071e67 Mon Sep 17 00:00:00 2001 > From: "Ignas Anikevicius (gns_ank)" > Date: Fri, 8 Feb 2013 14:05:06 + > Subject: [PATCH 2/4] Fix some mutex deprecation warnings in page-widget > > According to my compiler output and the page on glib deprecated APIs > [1], some of the stuff needed to be removed or changed. > > [1] - http://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html > > Signed-off-by: Ignas Anikevicius (gns_ank) This one too. > From a99e05179420ad27c0dce54b3661602615e530de Mon Sep 17 00:00:00 2001 > From: "Ignas Anikevicius (gns_ank)" > Date: Fri, 8 Feb 2013 14:17:38 + > Subject: [PATCH 3/4] Remove g_thread_init from main.c > > g_thread_init is no longer needed as glib is taking care of it automatically. For which versions of glib is this the case? If that's not true for all versions, an #if block around the g_thread_init call with a version check would be more appropriate. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 0/4] Some assorted stuff
On 2013-02-08 18:02:27, Sebastian Ramacher wrote: > > From a99e05179420ad27c0dce54b3661602615e530de Mon Sep 17 00:00:00 2001 > > From: "Ignas Anikevicius (gns_ank)" > > Date: Fri, 8 Feb 2013 14:17:38 + > > Subject: [PATCH 3/4] Remove g_thread_init from main.c > > > > g_thread_init is no longer needed as glib is taking care of it > > automatically. > > For which versions of glib is this the case? If that's not true for all > versions, an #if block around the g_thread_init call with a version check > would be more appropriate. Okay, so that's only 2.31 and newer. I'll add the version checks around it. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 0/4] Some assorted stuff
On 2013-02-08 19:04:41, Ignas Anikevičius wrote: > On 8 February 2013 18:04, Sebastian Ramacher wrote: > > On 2013-02-08 18:02:27, Sebastian Ramacher wrote: > >> > From a99e05179420ad27c0dce54b3661602615e530de Mon Sep 17 00:00:00 2001 > >> > From: "Ignas Anikevicius (gns_ank)" > >> > Date: Fri, 8 Feb 2013 14:17:38 + > >> > Subject: [PATCH 3/4] Remove g_thread_init from main.c > >> > > >> > g_thread_init is no longer needed as glib is taking care of it > >> > automatically. > >> > >> For which versions of glib is this the case? If that's not true for all > >> versions, an #if block around the g_thread_init call with a version check > >> would be more appropriate. > > > > Okay, so that's only 2.31 and newer. I'll add the version checks around > > it. > > Just checked it, only glib 2.32 onwards is supported according to the > README [1]. So is the if block really necessary? The same is for > master. [2] Neither the code nor the build system enforce glib >= 2.32. I'm not going to break compatibility with older glib versions just because of a call to a deprecated function that's a no-op in newer versions of glib. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 0/4] Some assorted stuff
On 2013-02-09 11:44:04, Ignas Anikevičius wrote: > On 08/02/13 08:14:55 +0100, Sebastian Ramacher wrote: > > On 2013-02-08 19:04:41, Ignas Anikevičius wrote: > > > Just checked it, only glib 2.32 onwards is supported according to the > > > README [1]. So is the if block really necessary? The same is for > > > master. [2] > > > > Neither the code nor the build system enforce glib >= 2.32. I'm not > > going to break compatibility with older glib versions just because of a > > call to a deprecated function that's a no-op in newer versions of glib. > > > > Regards > > -- > > Sebastian Ramacher > > Don't get me wrong, I also think, that it would be silly to break it > because of only one call, but maybe the README file should be updated, > so that people know what is the _lowest_ supported version. > > Also, as you can see on the glib docs [1], the muttex changes, which I > have done also are for glib >=2.32. I do not know though if zathura > breaks with earlier versions of glib, but, for example, g_mutex_init() > function is not present in glib versions prior to 2.32. > > Also, there were some changes to render.c file previously by Moritz [2], > which also change the mutex stuff in a similar way. There would be less > confusion if there is no check for glib 2.31 and people with old glib > versions (2.32 was tagged about 11 months ago [3]) shouldn't use zathura > development version either way. > > However, I will respect any decision you take, but as far as I can see, > having a check for glib 2.31 together with some other code in render.c > and page-widget.c is rather strange. Great, so we broke support for FreeBSD (which has glib 2.28 if my google-foo is correct). I'll add workarounds later. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 0/4] Some assorted stuff
On 2013-02-09 14:35:08, Sebastian Ramacher wrote: > On 2013-02-09 11:44:04, Ignas Anikevičius wrote: > > On 08/02/13 08:14:55 +0100, Sebastian Ramacher wrote: > > > On 2013-02-08 19:04:41, Ignas Anikevičius wrote: > > > > Just checked it, only glib 2.32 onwards is supported according to the > > > > README [1]. So is the if block really necessary? The same is for > > > > master. [2] > > > > > > Neither the code nor the build system enforce glib >= 2.32. I'm not > > > going to break compatibility with older glib versions just because of a > > > call to a deprecated function that's a no-op in newer versions of glib. > > > > > > Regards > > > -- > > > Sebastian Ramacher > > > > Don't get me wrong, I also think, that it would be silly to break it > > because of only one call, but maybe the README file should be updated, > > so that people know what is the _lowest_ supported version. > > > > Also, as you can see on the glib docs [1], the muttex changes, which I > > have done also are for glib >=2.32. I do not know though if zathura > > breaks with earlier versions of glib, but, for example, g_mutex_init() > > function is not present in glib versions prior to 2.32. > > > > Also, there were some changes to render.c file previously by Moritz [2], > > which also change the mutex stuff in a similar way. There would be less > > confusion if there is no check for glib 2.31 and people with old glib > > versions (2.32 was tagged about 11 months ago [3]) shouldn't use zathura > > development version either way. > > > > However, I will respect any decision you take, but as far as I can see, > > having a check for glib 2.31 together with some other code in render.c > > and page-widget.c is rather strange. > > Great, so we broke support for FreeBSD (which has glib 2.28 if my > google-foo is correct). I'll add workarounds later. Compatibility code is in place and the note from README removed. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH 0/4] Some assorted stuff
On 2013-02-09 18:08:30, Ignas Anikevičius wrote: > On 09/02/13 03:43:44 +0100, Sebastian Ramacher wrote: > > On 2013-02-09 14:35:08, Sebastian Ramacher wrote: > > > Great, so we broke support for FreeBSD (which has glib 2.28 if my > > > google-foo is correct). I'll add workarounds later. > > > > Compatibility code is in place and the note from README removed. > > > > Regards > > -- > > Sebastian Ramacher > > Thanks a lot for such a quick fix. Not to make things even more > complicated, but I found out that glib 2.34.2 has FreeBSD support. > http://ftp.acc.umu.se/pub/GNOME/sources/glib/2.34/glib-2.34.2.news > > If the changelog really indicates FreeBSD support, then potentially, in > the future we might not need these compatibility layers. It's not only FreeBSD. It's also Debian squeezy, some versions of Ubuntu and probably many more. Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
Hi Diego, On 2013-02-11 14:11:15, Diego Joss wrote: > finally! here is the patch to add conditional compilation of the > libmagic detection (with old method fallback). Actually the fallback > is both at compilation time, and runtime: if the libmagic method does > not work, it fallsback to the old method. great, thanks. Since most of the code is already in develop, I'll merge the bits that allow the fallback to the old method during runtime. > There are 3 patches attached: the first 2; > - (0001-...) implement the patch previously sent (with the *flags* bug > corrected) > - (0002-...) implements conditional compilation on top of (0001-...) > - (libmagic-detection-...) is a fusion of the 2 above (thus can be > applied on top of origin/master) > > The conditional compilation of the libmagic feature is activated by > default in config.mk; is this a good idea? it would mean that we > expect libmagic to be installed in most cases. I'd love to do it the same way as for sqlite, i.e use pkg-config to check if libmagic is available. However, libmagic doesn't have a pkg-config file. I have only some numbers for Debian available, but libmagic is installed on 99.27% of all popcon-participating machines [1]. So yes, I expect it to be installed in most cases. (We build with sqlite support by default, so I don't see why we shouldn't build with magic support by default. There is still a README telling you what to do if you don't want it.) Regards [1] http://qa.debian.org/popcon.php?package=file -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] replace g_content_type_guess with libmagic
On 2013-02-13 15:23:14, Sebastian Ramacher wrote: > I have only some numbers for Debian available, but libmagic is > installed on 99.27% of all popcon-participating machines [1]. So yes, > I expect it to be installed in most cases. > > (We build with sqlite support by default, so I don't see why we > shouldn't build with magic support by default. There is still a README > telling you what to do if you don't want it.) -dev(el) packages are another story, but meh. One can disable it … -- Sebastian Ramacher signature.asc Description: Digital signature ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Any hope for cygwin users?
Hi, On 2013-02-20 14:41:12, Vasileios Anagnostopoulos wrote: > is it possible for zathura/girara/jumanji to be included in > > http://sourceware.org/cygwinports/ > > for windows users? I'm unfamiliar with Cygwin and how their ports work. Maybe there is someone on the list that could help. Have you tried contacting the guys running Cygwin ports? They should know what has to be done to get girara, zathura and jumanji packaged. Cheers -- 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] Scale vertical/horizontal scrolling by the contents of the numeric buffer.
Thanks, applied. -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] Synctex support
On 2013-03-02 13:14:16, gi1242+zath...@gmail.com wrote: > Hi All, > > Thanks a lot for zathura! I love it, and use it as my primary PDF > viewer. I had two questions though: > > 1. The changelog says that version 0.2.2 (2013/1/20) implements >synctex forward synchronization. I've been gleefully waiting for >this so I can rid myself of xdvi completely. However I couldn't >find any documentation detailing the forward synchronization. Is >it implemented? If yes, how do I get it running. (I'm happy to >use an xdotool hack if needed.) No, it's not fully implemented yet. Backwards synchronization should work, but forward synchronization is still work-in-progress. > 2. Can I use counts with scroll bindings. (I.e. 10j should go 10 > lines down.) Now you can, thanks to Marwan. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Add 'q' and 'BackSpace' shortcuts in fullscreen mode
On 2013-03-17 12:26:33, Benoît Knecht wrote: > Incidentally, the default fullscreen shortcut doesn't seem to work > on > my system (it does the same as alone). If this behavior can be > confirmed by others, it should probably be removed. It definitely works for me and does the opposite of . Which keyboard layout are you using? We had some problems with some of them in the past. Might be another bug in the key handling code. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Don't scroll the document when focusing the inputbar
On 2013-03-23 10:07:17, Benoît Knecht wrote: > Add a new adjust mode that is set when focusing the inputbar and > disables adjusting the vertical scrollbar. As a result, focusing the > inputbar doesn't scroll the document, leading to better results when > changing pages from the inputbar (e.g. using bookmarks). So what happens after the inputbar is closed again? Shouldn't it be reset to the old mode? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH] Revert commit ce6e735
Maybe I'm missing something from the thread, but what is the conclusion? Should I consider the patch for applying or do you want to solve the remaining issues first? Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH v2] Use signals to readjust_view_after_zooming()
On 2013-03-23 09:59:59, Benoît Knecht wrote: > The previous adjustment values are tracked in zathura->ui.hadjustment > and zathura->ui.vadjustment (and updated by signal handlers as well), so > that the view's position can be maintained while zooming. I guess there are g_object_unref calls missing in zathura_free. They are never cleaned up. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [PATCH v3] Use signals to readjust_view_after_zooming()
Thanks, applied. These patches really improve the zathura experience. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] RFC
On 2013-03-24 07:28:03, Marwan Tanager wrote: > This patch tries to solve a serious problem with zathura leaking a horrendous > amount of memory during scrolling through a document. > > The problem is that the current way of periodically reclaiming the cairo > surfaces of the pages widgets is not working at all. The only case in which > it > seems to work is the first time (and "only" the first time) the timeout > function purge_pages is triggered, and even this first time sometimes doesn't > free the memory if it happened while scrolling through the document. > > To see it in action, try opening a large document (e.g. 500+ pages), and > scroll through it by dragging the scrollbar or continuously pressing > , > or . Meanwhile, watch the output of 'top $(pidof zathura)' until you > end up with a throttled system riddled with continuous swapping. Zathura will > fiercely eat all the physical system memory while scrolling through a > relatively big document. > > I've spent a while trying to figure out why the memory isn't freed after the > first time the timeout function is triggered, but quite frankly, I couldn't > manage to get to any reasonable conclusion. Injecting debug messages in > zathura_page_widget_update_surface shows that all the pages, but the current > visible one, are eventually reclaimed. This means that cairo_surface_destroy > must have been called on every surface of a page that exceeded it's > end-of-life > threshold, but without actually doing it's job of freeing the surface memory. > > So, this patch bypasses this mechanism by freeing a surface as soon as it's > associated page becomes invisible. Try repeating the same experiment as above > with this patch, and watch the rate of memory consumption drops dramatically. > I > scrolled the entire length of a 1300-pages document and the end result was > 500 > MB. And I don't think this is leaking memory due to cairo surfaces pixel > buffers, because it never increases after reaching this limit. Maybe it's > some > internal allocations done by GTK or GDK. This doesn't seem very far-fetched > for > an application with 1300+ GTK widgets in this case. No, please don't. There is reason why we decided to keep the pages in memory: consider a document with same pages, but one of them takes ages to render ([1] has an extreme example of such a file, but any document with larger images should do). In 0.0.8.x scrolling was a PITA with such documents: you had to wait until the page was fully rendered to do anything else. Keeping the pages in memory for some time is our attempt to improve the scrolling experience in that case. Scrolling back and forth between two pages becomes a much better experience since you don't have to wait until the page is re-rendered to see it. So it's a compromise between memory usage and time spent to re-render pages. The code to destroy the cairo surfaces periodically is not optimal, but if it all, we should fix this portion of the code. Maybe a timing-based solution is not a good idea and there are better ways to approach this, but I really don't want to ruin the above use case again. Ideas and patches to improve the page reclaiming code are very welcome. Cheers -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] RFC
On 2013-03-24 07:28:03, Marwan Tanager wrote:
> While browsing the bug tracker for related issues, I found the one at
> http://bugs.pwmt.org/issue95 which points out the 0.0.8.5 version as not
> suffering from this problem. I built it and experimented. The result was that
> the total amount of memory consumed by scrolling through the length of the
> 1300-pages document was comparable to the one with this patch. So, there must
> be something messy happening with cairo_surface_destroy when it's get called
> from the timeout function while scrolling. Maybe it's non-reentrant and some
> mess happens when it's called concurrently from both the timeout function and
> the render thread. But if that's the case, then why doesn't it free the
> memory
> after the first time, even when there is no scrolling? Also, I tried to
> experiment with mutexes around the cairo_surface_destroy calls on the render
> thread and zathura_page_widget_update_surface but nothing surprising has
> happened.
I played a bit with the code tonight. What puzzles me is that it works
for the first time but not for any subsequent purge operations. As far
as I can tell, the ref counters of the surface are 1 and thus
cairo_surface_destroy should free the image. cairo_surface_destroy is
definitely called, but I really don't know why nothing happens [1].
I played with some gdk_threads_{enter,leave} calls around the destroy to
no avail.
I will follow up to the other mails in this thread later this week.
[1] Nothing in the sense of that the first call gives a huge decrease in
RES usage and subsequent calls only a small decrease.
--
Sebastian Ramacher
___
zathura mailing list
zathura@lists.pwmt.org
http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] RFC
On 2013-03-25 04:59:58, Marwan Tanager wrote: > On Mon, Mar 25, 2013 at 03:53:06AM +0100, Sebastian Ramacher wrote: > > On 2013-03-24 07:28:03, Marwan Tanager wrote: > > > While browsing the bug tracker for related issues, I found the one at > > > http://bugs.pwmt.org/issue95 which points out the 0.0.8.5 version as not > > > suffering from this problem. I built it and experimented. The result was > > > that > > > the total amount of memory consumed by scrolling through the length of > > > the > > > 1300-pages document was comparable to the one with this patch. So, there > > > must > > > be something messy happening with cairo_surface_destroy when it's get > > > called > > > from the timeout function while scrolling. Maybe it's non-reentrant and > > > some > > > mess happens when it's called concurrently from both the timeout function > > > and > > > the render thread. But if that's the case, then why doesn't it free the > > > memory > > > after the first time, even when there is no scrolling? Also, I tried to > > > experiment with mutexes around the cairo_surface_destroy calls on the > > > render > > > thread and zathura_page_widget_update_surface but nothing surprising has > > > happened. > > > > I played a bit with the code tonight. What puzzles me is that it works > > for the first time but not for any subsequent purge operations. As far > > as I can tell, the ref counters of the surface are 1 and thus > > cairo_surface_destroy should free the image. cairo_surface_destroy is > > definitely called, but I really don't know why nothing happens [1]. > > I've done exactly the same test and made sure the ref count is always 1 > before > the call. That's exactly what drove me nuts! Yes, it's totally weird. One further note: With the ps plugin the behavior is totally different as far as I can tell. Regards -- Sebastian Ramacher ___ zathura mailing list zathura@lists.pwmt.org http://lists.pwmt.org/mailman/listinfo/zathura
Re: [zathura] [Zathura PATCH] Replace the periodic page reclaiming code with a LRU caching algorithm.
args=0x7dd296a8, n_params=0,
param_types=0x0) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gclosure.c:840
#42 0x2c0a0006 in g_signal_emit_valist (instance=0x2abcf930,
signal_id=, detail=0, var_args=var_args@entry=0x7dd296a8) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3211
#43 0x2c0a0852 in g_signal_emit (instance=,
signal_id=, detail=) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3356
#44 0x2b1d7a20 in gtk_container_idle_sizer (data=) at
/tmp/buildd/gtk+2.0-2.24.10/gtk/gtkcontainer.c:1357
#45 0x2b775327 in gdk_threads_dispatch (data=0x2aaab6402e60) at
/tmp/buildd/gtk+2.0-2.24.10/gdk/gdk.c:512
#46 0x2c310355 in g_main_dispatch (context=0x2abc0890) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:2539
#47 g_main_context_dispatch (context=context@entry=0x2abc0890) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3075
#48 0x2c310688 in g_main_context_iterate (context=0x2abc0890,
block=block@entry=1, dispatch=dispatch@entry=1, self=) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3146
#49 0x2c310a82 in g_main_loop_run (loop=0x2adaf9e0) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3340
#50 0x2b252797 in IA__gtk_main () at
/tmp/buildd/gtk+2.0-2.24.10/gtk/gtkmain.c:1256
#51 0x2aab8e1a in main (argc=1, argv=0x7dd29cc8) at main.c:151
> +
> +void
> +zathura_page_cache_add(zathura_t* zathura, zathura_page_t* page)
> +{
> + g_return_if_fail(zathura != NULL);
> +
> + static unsigned int num_cached_pages = 0;
Could you move this to the struct for the cache in zathura_t?
Cheers
--
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
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] [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] 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] 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] [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] 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] 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] 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] 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] [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] 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] [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] [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] [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] 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, 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] 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] 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-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] 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] 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] [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] 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] 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] 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] [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] 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] [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] 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
