GNOME Bugzilla – Bug 311024
[RFE] Some gconf configuration options
Last modified: 2007-04-26 00:00:29 UTC
Not a bug, I'm a whiner who wants more features ;-) It would be nice if some of the evince configuration options could be made persistent (e.g. via gconf), e.g.: View -> Toolbar, Statusbar, Continuous, Dual, Fit Page width etc.
Setting severity to enhancement, then.
I think we already discussed it in another bug and we got to the conclusion that we want to persist such settings per document rather than globally.
Can that behavior then at least be made configurable? It is severely annoying to change 4 or 5 settings every time I open a document. Or at least make the defaults for the settings used accessible by the ever so user-friendly gconf-editor ;-)
Hi, part of the beauty of Evince is the complete lack of configuration options. Everything is supposed to work, hopefully as expected. Bug 168450 talks about "smart" sizing of windows, which what I think is the best method for Evince to use for many of these optons. I agree toolbars should be configured in one window and that becomes the default for all windows. It's just nonsensical to have per document toolbars. The status bar needs to be removed in future releases see bug 311616 The toolbar should appear if it has anything interesting like thumbnails or index information. Otherwise it doesn't need to appear, but this doesn't mean it's the default. If you close the toolbar on a document, it should remain hidden for that document until you bring it back. Continuous should be the default, this is a per document setting like the toolbar. Fit Page This should be replaced by a Fit Text see bug 169676 and should be the default, per document setting like above. Dual View and Window size are items that I think the "smart" sizing need to handle, see the first mentioned bug.
OK, so if I read this right, I could turn e.g. Continuous off, and when I open a new document that setting will be remembered? Or do I have to turn off Continuous for every new document I load?
The settings we are remembering globally are the window chromes (toolbar, statusbar...). Document sizing (and maybe continous mode, I dont remember) is saved per document.
So in order to change the default of e.g. Continuous, I'd have to download, patch and compile a new version? Now that's what I call user friendly ;-)
>Bug 168450 talks about "smart" sizing of windows, which what I think is the best >method for Evince to use for many of these optons. Ok so this part of the bug is dup >I agree toolbars should be configured in one window and that becomes the default >for all windows. It's just nonsensical to have per document toolbars. We are doing this already and it seem to work here. No bug here I guess >The status bar needs to be removed in future releases see bug 311616 Same as above >The toolbar should appear if it has anything interesting like thumbnails or >index information. Otherwise it doesn't need to appear, but this doesn't mean >it's the default. If you close the toolbar on a document, it should remain >hidden for that document until you bring it back. Not quite clear on this. Do you mean the sidebar? Should this be persisted per document? I think we are persisting globally right now. >Continuous should be the default, this is a per document setting like the >toolbar. s/toolbar/sidebar? These should be already working >Fit Page This should be replaced by a Fit Text see bug 169676 and should be the >default, per document setting like above. Same as above >Dual View and Window size are items that I think the "smart" sizing need to >handle, see the first mentioned bug. Ok so dup. So summarizing it looks like we are doing everything as by design except the sidebar which should be per document.
marco, looks like you got it all right Conrad, is there a reason why you don't want to use continuous scroll?
Filed bug 311632 about the sidebar issue. Marking this as a dup of the window sizing bug, everything else is WONTFIX. *** This bug has been marked as a duplicate of 168450 ***
Hi Bryan Thanks for asking :-) I think I can summarize it by saying that I'd like the Page Up/Down keys to work as labeled ;-) One thing I do regularly is to scan through a document by paging through it quickly. If you do that with continuous, you'll notice that the top of the page moves lower or higher on the screen every time you press Page Down. I know this is related to the fact that Page Down doesn't actually do a "page down". If I had a choice I would rather make it so that pressing Page Up/Down does exactly that by default, which is what turning off continuous partly does. Perhaps the use of a modifier key might help: e.g. pressing Ctrl-PgDown will do a real Page down? Thanks for your replies btw!
It may be a bug, then.
> Conrad, is there a reason why you don't want to use continuous scroll? Most of my documents have two-column pages, and I feel more comfortable reading them with discrete pages. I believe continuous is best for most, but not for me; and the per-document config won't help much, since I'm generally reading new documents.
I'm not fond of continuous scrolling, either -- most of the documents I'm viewing are page-based (mostly generated by TeX), and I like to be able to see the whole page. I definitely think that there should be a number of globally settable configuration options, or at least some way to specify them on the command line. At this very moment I'm using Evince to look through about a dozen theses to verify that they look okay, pagination is correct, and so forth. Ideally, I would have liked them to open full screen, noncontinuous, and in ``dual-page'' mode, although for most documents I would probably prefer ``roughly full size'', noncontinuous, single-page mode. I like Evince so far -- it looks nice, it does a good job rendering documents, and it's pretty zippy -- but I would like to be able to control it a bit more, even if I have to set up an alias with various command-line options or set some things in Gconf.
Count me with the others wanting to ditch continuous scrolling as a mandatory default. That and the lack of configurability are all that appears wanting in what is otherwise an outstanding PDF viewer. The big question I have about allowing the user to configure the application's behavior is "why the heck not?"