Version: svn r771286 (using Devel) Installed from: Compiled sources The page flip bar, at the bottom of the viewing area wastes a lot of previous space, even though it has very little content (two numbers and two bottons). Moreover, it's redundant when the Thumbnails pane is open. Please provide an option to hide the page flip bar or to dock it (as a normal toolbar) in the unused space to the right of the menubar.
Well, that solution was done because people did not have (in KPDF) the page numbers and quick page navigation buttons when the side pane was hidden. Hiding the bar? Sure, just to have bug reports asking for having the page number visible when its container is hidden? Better not. Docking into the toolbar? I'm not a fan of putting into the toolbar what really is not a tool, but more an information widget.
I see why it's good to have the page number always visible by default, but currently it really takes an enormous amount of precious space for just a couple of numbers. Especially in full-page mode on medium-resolution screens, the loss of vertical space makes a big difference in text legibility. There's so much empty space in the toolbar just begging to carry this information... Please reconsider.
Created attachment 23451 [details] Patch to add a "Show Bottom Bar" option to the Settings menu. Attached is a patch to add a "Show Bottom Bar" (Shift-F7) option to the Settings menu, with setting persistence. I still think it's better to just use a standard toolbar, but that would be more work.
I would like to add my support for adding an option to hide this bar. Every other visual component of Okular can be hidden, except this bottom bar. I have an EeePC, where the vertical resolution is only 480 pixels. I hide the menu bar, toolbar, and sidebar to maximize the space for viewing documents, but the page bar takes a lot of space away (30 pixels is a lot when you only have 480 total!) Adding an option to hide it would be consistent, as everything else can be hidden (even the scrollbars, which I can't imagine anyone wanting to do). Please, putting it into the settings dialog under appearance would be great, then it wouldn't clutter the menus.
I have to say that first i thought "bah, why would anyone want to hide the page bar", but 480 pixels seems a good reason. Pino?
Believe, its already annoying for 1280x800 on a 13 inch screen. It can decide whether, if you want view an entire page at once, you are at a zoom-factor where the letters are still readable or not. Otherwise one could likewise ask "why would anyone want to hide the menubar/ scrollbars / toolbar etc". Or "why do we need a fullscreen mode at all, if the screens have enough space anyway ...
*** This bug has been confirmed by popular vote. ***
> Docking into the toolbar? I'm not a fan of putting into the toolbar > what really is not a tool, but more an information widget. What about the zoom field? Is is also an information widget. What about an information bar for this?
I would also like to have show/hide option or docking into panel option (may be the last is better). I agree that on small screens it consumes to much space just to display page number.
being able to hide it and/or dock it back like in kpdf would work for me ... but having it always sit there like a big old fatty sucks ;)
*** Bug 176119 has been marked as a duplicate of this bug. ***
Konqueror also has in "information" widget in the toolbar: the search entry and the URL entry. The latter also has an information element, when I select links in the text, it get's updated. So it would be no usabability violation if okular puts the "next page", "prev page" and "page number" elements into a toolbar. The "page number" element could work like the URL element of Konqueror: allow entry of page-numbers, but also automatically update. kpdf from 3.5.x was WAY more screen estate for the page then okular from KDE SVN currently has.
*** Bug 179680 has been marked as a duplicate of this bug. ***
*** Bug 181198 has been marked as a duplicate of this bug. ***
Btw. why making such artificial design? With several toolbars (parts) user could freely decide where to put toolbar A (and if put it at all?) the same for toolbar B, C, D etc. Currently it is all harcoded, this is toolbar, that is sidebar, the other one is bottom-bar. With one uniform (yet flexible) approach user can turn all of them, turn some of them, all of them -- place them next to the other (saving space), or place them all on the right (example). Bottom line -- each user decides for him/herself depending on 4:3 vs. WS ratio, resolution, etc etc etc.
Did anyone take a look a the attached patch?
*** Bug 194352 has been marked as a duplicate of this bug. ***
for the patch, the function argument for slotFileDirty is not "filename" but "path" now, and the lines should be 987 995 now for the patch to apply against 1.2.88 I don't see the menu option, but the shortcut works great and is customizable. Thank you!
I'd just like to add that space wasted by the bottom bar is the reaseon why many people rather use xpdf because as it supports the real fullscreen. Please include the patch!
Still not included? On my EeePC, I want all the screen devoted to content, not to a useless bottom bar that takes a good percentage of screen estate... Fullscreen content should be, well, fullscreen. An option to disable it anytime would be usefull too. I prefer seeing my document then seing a widget telling me the page number.
*** Bug 211199 has been marked as a duplicate of this bug. ***
> @Pino (In reply to comment #1) > Hiding the bar? Sure, just to have bug reports asking for having the page > number visible when its container is hidden? Better not. Would it create more bug reports than when someone unused to any KDE program accidentally hides the menu bar and freaks out trying to get it back? I really appreciate all the work you've done on Okular, expanding it into an all-purpose pdf/djvu/chm/cbz/etc viewer, the development of the .okular archive format to preserve metadata, the right blend of straight-lacedness and customizablity with regard to DRM... But the big fat unused (yes, unused. I've literally never used it) page bar at the bottom is a wart. It's obviously the worst line in the poem, the character in the movie that doesn't fit and must be cut out, someone's personal political hobbyhorse that gets foisted onto relatives at Christmas. It does have an impact on the viewing experience, regardless of the user's screen size. I read a lot of scanned documents with a 1080 display and I still wish I had more vertical pixels. On my netbook? Let's not go there. I'm guessing from the discussion about patches that it would be trivial to give it a check under the view or settings menu, and/or a shortcut like Show Menubar. Folks obviously want it.
(In reply to comment #22) > But the big fat unused (yes, unused. I've literally never used it) page bar at > the bottom is a wart. It's obviously the worst line in the poem, the character > in the movie that doesn't fit and must be cut out, someone's personal political > hobbyhorse that gets foisted onto relatives at Christmas. For what it is worth for me, telling thanks and then as excuse go on with mean language is simply ... This ends my reading here. Have a good day.
Attitude towards the world + no distance + channel with stripped a lot of background information can (and does) lead to twisted reception. @Hilmera, if not lack of time, I would start writing down the best, funny and wit quotes from ML and BTS, just because of how much you cheered me up with those exactly lines.
I just would like to support hilmera. Of course it's not justified to use mean language towards programmers that spend their spare time to do this job, but I also don't understand why this bug, which I guess would be quite simple to remove, is so steadily ignored? Until recently I was using kdvi and kpdf as a way out, but in kde4 they are completely replaced by okular to my knowledge. But this replacement is unfortunately still is a regression in a few aspects, in particular because of this bug, that the fullscreen mode is not a fullscreen mode.
Is there the possibility to put the few widgets from the bottom bar to the main toolbar in the default settings? There are already (default?) entries for next and previous page in the main toolbar. So there are already duplicate button that also (may) confuse persons. Then the only missing information would be the current page and the total number of pages maybe as simple textedit fields? Other PDF viewers like Adobe Reader, Evince, epdfview do this. I only know bottom bars from vector image programs like Inkscape but Okular is mainly a viewer. What do you think? I (and maybe other supporters of this bug) may not have the historical background for the existence of this bottom bar. Looking at http://upload.wikimedia.org/wikipedia/commons/5/58/Okularkde4.png it seems that the button in the bottom bar have been much bigger. So the buttons already get smaller...
i think the cc/vote list speaks for itself. of all bugs ever filed for Okular, this is easily the 3rd highest voted. i.e. people want the ability to make this thing go away. whether it becomes a more mobile widget of sorts or we can simply turn it off is up for debate.
Opinions don't really count for much. Do you have any usability research that evaluates this issue? (there was a fair amount of usability work - I don't remember this coming up). Do you have a patch?
and you wonder why people get pissed off with attitudes like yours. changing vote counts globally doesnt affect the position. this is still the #3 desired bug by the *users* according to bugzilla. no one is asking for defaults to be changed. people are asking for *a config option* so that they can change an aspect *they personally* find annoying. in terms of simply making the thing go away, usability research is completely irrelevant. no, i havent written a patch, but if you read the bug report, you'd see someone posted a patch 2 years ago to do what most people here want: 4 files changed, 30 insertions(+), 5 deletions(-) a diffstat like that doesnt imply a long review time ...
(In reply to comment #29) > and you wonder why people get pissed off with attitudes like yours. Calm down, please. > no one is asking for defaults to be changed. people are asking for *a config > option* so that they can change an aspect *they personally* find annoying. Option over option is just not the way to make a desktop-oriented interface work in small factor devices. > in terms of simply making the thing go away, usability research is completely > irrelevant. Exactly the opposite. PS: screaming more won't bring you the feature sooner.
no one is screaming. that's what caps are for. i was merely stating facts -- you cant honestly expect people to be all happy when they're told their opinions "dont count". clearly this feature has user demand behind it. it's kind of funny how you quote "small factor devices" when this bug is about something that eats screen real estate and gets significantly worse on such devices. i'd wager that most end users who file wishlist items are hardly inclined to do any sort of "usability research" into how confused people get when they disable options without reading the text. i hadnt realized KDE was taking a page out of the retarded GNOME handbook.
(In reply to comment #31) > it's kind of funny how you quote "small factor devices" when this bug is about > something that eats screen real estate and gets significantly worse on such > devices. Thanks for having proved that you didn't read/understand what I said at all.
A menu entry "Settings-> Show Bottom Bar" (as in the patch) perfectly fits to the other options and is by no means more confusing than to have the option to show (or not to show) the menu-bar (I like this option also). KDE was known to allow more settings than gnome and that's why I like many KDE applications. Would be a pity if this philosophy has changed.
Pino: and everyone knows the best way to help other people understand your point is to mock them for being too stupid to "get it". cheers! the patch applies pretty much unchanged (tweak one unrelated context line to have to apply) to okular 0.9.3 (kde 4.3.3). maybe i did it wrong, but i dont get the item under the drop down menu. tweaking my okularpartrc manually allowed me to make it disappear though.
(In reply to comment #34) > Pino: and everyone knows the best way to help other people understand your > point is to mock them for being too stupid to "get it". I'm not mocking anybody; like you were merely stating facts before, and stated something, which you misunderstood.
>>> Option over option is just not the way to make a desktop-oriented interface >>> work in small factor devices. >> it's kind of funny how you quote "small factor devices" when this bug is about >> something that eats screen real estate and gets significantly worse on such >> devices. > Thanks for having proved that you didn't read/understand what I said at all. I'm not sure I understand both arguments, but I can say the reason I subscribed to this bug report was that I want my application to take as much screen space as possible on my small 10' screen, be it fullscreen or not. Personally I've never used that bar: there is a widget in the upper bar for everything (except total number of pages) and the keyboard shortcuts are more then enough for me. I just wish I had ~20 pixels more of the document I'm reading then an empty bar.
All the users I know agree that "Okular would be great without the crappy toolbar that is completely useless and can't be turned off." None of us understands why exactly it can't be turned off and some of them rather use xpdf because it can at least do fullscreen. I use KDE apps because I can set them up - get rid of space-wasting giant icons and useless toolbars I don't need. Every KDE app can be customised to make particular user happy. And then there is Okular with the toolbar noone wants that can't be turned off. Why not presume Okular users are not idiots who randomly click options and can't click on them again in case of undesired effect? I think there already is another DE built with exactly those users in mind. (note that Evince can do fullscreen) As of "usability research": Users tend to dislike changes and new things they are not used to, but this is definitely not the case so this bug and it's votes are THE real usability research which is ignored for very long. Why don't I hack the patch? Because I think a skilled Okular developer should do so as it's extremely important and influences entire Okular experience.
Seriously I can't believe what is going on here... There is a patch attached to this bug, which fixes the problem with as much as 30 lines of code... It is there for two years!!! Would it be really that hard to check if it works and commit it to the SVN? Or if it doesn't works, then update it maybe? I mean, if it took 30 lines of coding 2 years ago, would it take now 3000? I don't think so... But no... for two years, the patch is here at the bottom of this page, and no one cares about it. But on Planet KDE a developer of Okular points at this bug as one of the reasons to leave the Okular team... sorry, but I truly can't understand this. Every part of Okular's interface can be set to hidden... why the bottom bar MUST stay as an exception from this rule? Why is it so important? Why is it more special than the menu bar, the toolbar or the sidebar? What about consistency? It truly saddens me, that we have such debates around such a small feature... such a small feature that would only take checking and correcting an already existing patch. Sadly I am not yet a developer myself to do it... but honestly, such events really make me want to become one!
To me, the whole handling of this bug by the okular developers is probably *the* most elitist way of handling a bug report / feature request. Someone actually has taken the time to politely ask, include a patch, several people have voted for it and subscribed to it, and a very small group of people are sitting comfortably in their chair is telling users to go away and come back when they are less stupid. Developers talking to users as if they were idiots, and in general treating their users like stupid kids ...? This is not what I thought KDE was about. And then this: http://www.kdedevelopers.org/node/4131 . What a crowd (well apparently the okular team isn't a crowd according to the blog post) of whiners. Grow up. Oh, and I second the bug report and hope someone takes time off from sitting on their high horse of "UI/usability testing" to add a checkbox to a menu or window.
You never learn, eh? From a developer point of view i have no problem commiting this patch the request is acceptable, the problem is that last comments have been so bad mannered that i don't see why Okular developers should please bad mannered people. So calm down, be nice and maybe you'll get this for KDE 4.5. And don't say "i'll use xpdf instead!" and think it affects us. It's up to you to decide what program suits you better, we don't loose anything if you use xpdf instead of okular, on the contrary, we win having less bad mannered people around. And by the way we are grown ups, it's you that are not and think that screaming louder people makes you be right, which is, unfortunately for you, not true. All in all, let's make a deal, KDE 4.4 is already feature frozen so obviously this feature can not go in, and there is still six months until KDE 4.5, if noone posts an offensive comment here in three months i'll make the feature be in there for KDE 4.5
"if noone posts an offensive comment here in three months i'll make the feature" You are writing this in a public place and I just wonder what you will think of yourself in a year or two. Yes, about this "mature" deal -- behave, because otherwise daddy won't buy you a candy. Living proof of not treating other people as bunch of stupid, annoying kids. "Here you go monkey, good user, have banana". Would you tell the same in person to us? Face to face? ========================================================================== The word "mean" is repeated too many times here, so everyone who keeps repeating it please finally watch the Monthy Python parrot sketch. Any resemblance with Hilmera post? No? http://www.youtube.com/watch?v=npjOSLCR2hE
Ok this stops here and now! For the next inappropriate comment posted here I will ask for the person's bugzilla account to be closed. Please respect the Code of Conduct (http://kde.org/code-of-conduct/).
at Albert: Thanks for this answer. A statement that the report is taken seriously is all what I (can just speak for myself) was missing so far. It is a pitty that the discussion here has become so agressive. I can understand that the developers loose their motivation if the users become angry and insulting. However, you should also take into account that the first comment by Pino (at a stage were there was no agressive discussion at all) was a bit provoking. I could have understood arguments like "we have a lot to do and we simply have not found time yet to look at it", or "for this and that reason the problem is harder to solve than it seems", but instead there were arguments given why this option should not be included that simply non of us users understood. This is part of the reason why the discussion became so emotional and I hope both sides will do their best to avoid this in future. I would be really happy if the future would be implemented in KDE 4.5 ...
I'd like to chime in as well, as I think I understand the argument from both sides. Hiding the statusbar would save precious pixels on devices which have a small screen, yet it is a useful feature if screen estate is not a big issue. However, introducing an option for this would clutter the menu - yes, it's just one option, but have 10 of those and we're back at square 3.x ;-) So how about this: hide the status bar in full-screen mode and show it otherwise. No option required that way...
(In reply to comment #43) > However, you should also take into account that the first > comment by Pino (at a stage were there was no agressive discussion at all) was > a bit provoking. I simply exposed my idea in a polite way (believe me or not), also basing it on the existing KPDF experience. Did I say "It won't ever done this way"? No. Did I close the bug report as wontfix? No. Did I spit on the patch and/or insulted who proposed it? No. > I could have understood arguments like "we have a lot to do > and we simply have not found time yet to look at it", or "for this and that > reason the problem is harder to solve than it seems", but instead there were > arguments given why this option should not be included that simply non of us > users understood. Right, it was my opinion. Given it was expressed politely, I don't see why disagreeing with it means insulting. > This is part of the reason why the discussion became so emotional That happened because for some people there is only exactly what they want, refusing any other option.
Well, it is true that you did not close the bug, but your first answer looked simply like there is no interest in changing anything. Sorry if this impression was wrong. I should also admit that I was to some extent confused about the discussion, because for a long time I was thinking only about the fullscreen mode, where I really did not see any of the arguments apply. But also for the non-fullscreen mode I simply have never seen a justification why the bottom bar has a different priority than other bars. Anyway, I hope the discussion will come back to a rational one.
@Jos, You don't know in advance too much about documents users will read, but user can see it and decide if the page numbering (by okular) is required or not. Why not to leave this decision to him/her? I opt for consistency in UI -- keep the content view all the time and all additional elements switchable (by user, not hardcoded). All of them. And except for one this is already done. No need for introducing exceptions. > have 10 of those and we're... Do you see them on horizon or not (I mean, can you tell the name of those features/options)? If guess not, so it would mean optimizing unknown future.
Hmmm, from my review of the discussion of this bug report I get the impression that the tone of the discussion has not been very productive on *both* sides - users requesting the feature *and* developers responding to these requests. Its quite simple to see: Whenever communication turns into "It's your fault", "The problem is you" and I can see this in posts from users and developers as well, whenever communication turns into you-communication things easily go like this. One characteristic of such you-communication is that it goes into circles that easily escalate. First step to remedy then is, each communication party steps back and gets into I-communication. When everyone expresses his own position and feelings about the issue without stepping back into acusing you-communiation I think its quite easy to solve this issue. So I do a start: - I agree that in the default settings Okular wastes much more real screen estate than kpdf or xpdf. - Thus I also prefer an option to hide the toolbar with the page numbers at the bottom. - Currently there are three show/hide options in the settings menu and I don't think that a fourth one would overburden even the casual user. To me it does not make much sense than anything else could be hidden, but the status line in the bottom could not be hidden. - The option IMHO is not very dangerous in my eyes, at least not more dangerous than hiding the menu bar. I got stuck into such a hidden menu bar issues without knowing how to unhide it once - AFAIR with Amarok, but I am not completely sure about it. So this is my case for the option and I kindly ask for review of the patch and for implementing it. Now my oppinion on some other aspects on how users and developers communicate herein: - I think that no user has a *right* to have a particular feature implemented unless he makes a contract with one of the developers and pays or otherwise compensated for it. If a developer choose not to implement it, then so be it. The user has the chance to become a developer by itself and implement the feature. - Cause of this I think that a user should politely ask for implementation and then wait, maybe remind *friendly* from time to time or do it him/herself. So I ask every user to think whether an additional "Implement it!" does add to the solution. I think the case for the feature has been made. - On the other hand I think "I will implement it, when you behave like this or this" doesn't add to the solution. So I ask you, Albert Astals Cid, to reconsider. - I think asking for bugzilla accounts to be closed does not add to the solution either. Thus I ask you, Lydia, to reconsider. I perceive accusing you-communication on both sides. So as long as something - be it written by user *or* a developer - really clearly does not violate netiquette I wouldn't act like this. And in the end some examples of I-communication so that the difference becomes obvious: Comment #40 by Albert Astals Cid: "I feel hurt and accused by comments like ... Its not that I do not like to implement the feature but I do not feel motivation to implement the feature request anymore after having read those comments. Please stop using such comments and respect my and other developers work on Okular." Comment #41 by Maciej Pilichowski: "I feel being oppressed and treated like a child by your comment, Albert, that you will only implement this feature when there is no comment that you consider being offensive. I kindly ask you to implement the feature and I respect your work on Okular." (IMHO you shouldn't treat a child like this either.) Comment #42 by Lydia Pyntscher: "I am very angry about the tone of the discussion that I perceive as being unfriendly and rude. I got very upset about your comment, Maciej. I got the impression that you, Maciej, accused Albert, instead of directly expressing yours. I ask everyone to stay with theirs and stop accusing other people. Please stay with the code of conduct." Each comment seen in the history of comments above. But if comment #40 had been like above, following comments would easily have been different: Comment #41 by a user who wrote a comment that Albert feels being hurt for: "Oh, sorry, I see you are feeling hurt. I fully respect your work as a developer of Okular. I would really like to see this feature in okular for reason A, B and C. I kindly ask you to review the patch and implement it." Original comments #41 und #42 would have not been necessary then. I just started with your comment, Albert, as an example. I think is doesn't make much sense to see where it started and do accounting for misbehavior on each side. My case just is: When everyone looks clearly at what is his or hers and what is the other ones and just tries to stay with his or hers instead of wronging others, this issue can be put to rest very quickly. Every one entitled to his or hers feelings and oppinions about the feature request and the tone of the communication here. But no one can change any other one. Everyone can just start within him- or herself and hope that it will make difference. Endingly a disclaimer: I am not perfect at I-communication. Maybe one of my examples has hidden you-communincation inside. Look for yourself. Important is that everyone stays with him- or herself when expressing a oppinion, feature request, whatnot.
Martin you are misunderstanding. KDE's bugzilla is not the place where people can come and act like they want to. We have a few basic guidelines how we want to interact with each other, specifically the CoC. Anyway from now on it's time to discuss the actual bug again and act like grown ups. == end of this part of the discussion ==
I must admit that after reading all comments I can't fully understand the cons of adding the option to hide the bottom bar are so I would be grateful if a developer could shed some light on that particular point. In my understanding I belive the main concern is cramming too many options in the "settings" menu. While my personal opinion is that adding such option won't be excessive and would lead to consistency (as many pointed out, every other GUI element can be hidden), what do you think about a solution similar to the one adopted by Gwenview for its sidebar (the “Splitter Collapser”, http://agateau.wordpress.com/2009/05/17/gwenview-2-3-sidebar/)? I think these would be the consequences: * PROS: - People who want to hide the bottom bar could do it. - No need to add a new setting option. - Easily discoverable. - The bar could be easily restored if accidentally hidden, even by a novice user. - Already in use in other KDE software. * CONS - Inconsistency with the other "hidable bars". - Some clutter on the GUI (the collapser would probably be too visible). To mitigate the last concern, perhaps the option to hid the bar could be located on a context menu in that bar. The collapser would then only be shown when the bar is hidden. Anyways, I think this could be all a bit contrived.
Re Comment #49: Just one more note in public. I feel being misunderstood by you Lydia. I receive your message as if I had written KDE's bugzilla is place where anyone can act like they want to. I really do not think I did.
> what do you think about a > solution similar to the one adopted by Gwenview for its sidebar > (the “Splitter Collapser”, > http://agateau.wordpress.com/2009/05/17/gwenview-2-3-sidebar/)? I think it is cute but it is "does not work for everyone" solution in the first place. The problem is the remaining tab, well, remains on the screen all the time. For gwenview this issue is important, but for okular it is crucial. > * PROS: > - People who want to hide the bottom bar could do it. Actually on par -- with checkbox in the menu you could do this too. > - No need to add a new setting option. But need to add new tab which has to be shown if you use it or not. On par. > - The bar could be easily restored if accidentally hidden, even > by a novice user. Yes, but this would be real advantage for menubar, because showing it again is tricky. For pagebar it is advantage but minor. > - Already in use in other KDE software. Checkboxes are far more common. > * CONS > - Inconsistency with the other "hidable bars". Not only this. There is over decade of central UI design. You manage stuff from one place. If you shift UI to object-centric it means: * user has to re-learn * user has to either learn keyboard shortcut or do extensive mouse movements > - Some clutter on the GUI (the collapser would probably be too > visible). - The collapser is visible all the time, and there is no way to hide it. - The collapser conflicts with content, gwenview is primary images viewer, with okular I read documents, I would not like to be forced scrolling just to get text pass the collapser so I could read it -- and I guess I am not alone. Non regular obstacle would be more annoying that regular (like statusbar, toolbar or sidebar). - It is expensive. I mean adding checkbox is almost trivial, you either show the bar or not. With collapser you have to add the logic -- is mouse over collapser or not. Fade it out or not. The most important -- did we see single report about problems with toolbar checkbox? In any app. I mean -- that it caused clutter, it is not intuitive, it is not productive, and so on? If not, it means checkbox works (it does not mean that other approaches would not work).
Yes, I agree with you, Maciej. I think the best solution is the checkbox. What I'm trying to offer is an alternative in case the checkbox is unacceptable (I still think it would very helpful if a developer could summarize what are the problems of the current proposals...).
If someone would offer a patch for the check box, what would be the criteria for acceptance/rejection?
Speaking with a developer mindset, I think the frustrating thing is that "users" are going for the easiest solution (yet another option, simply hiding something you don't like) instead of making the actual feature better so that it doesn't distract anymore but still provides the same functionality. *That* is what KDE 4 is about: provide useful features without cluttering the user interface, by thinking smart instead of putting everything into an option. The Okular team (or what's left of it, thanks ever so much guys) is especially entrenched in this philosophy, and cares a lot about not making an option for every pixel and his dog. You can now wait 3 months for Albert to give in, or actively work on designing something that satisfies both camps. So, going forward: I'm surprised no one mentioned the obvious solution yet. As far as I can see, the problem is that a narrow widget is a) placed in the middle of the screen where it overlaps with the most central portion of the text on pages, and more importantly b) the narrow widget requires significantly more space than it actually does by being placed in a toolbar that extends its use of vertical space to the whole view width. So why not think of an approach that a) releases the widget from its toolbar and makes it use only the space that it actually needs, maybe even making its background translucent, and b) if possible in the given zoom level, putting it to the right of the page so it won't cover any text, or if the zoom level doesn't allow it, put it further to the right anyways (there tends to be less text there), maybe in the middle between center and right edge or so. I thought of something in the direction of Gwenview's crop widget, but placed differently and of course with different contents, and visible all of the time. You get the idea. Please think twice before you demand more options - they are not bad per se, but are often the product of taking the easiest way instead of the smartest. Please respect the Okular developers if they don't want to go down that route.
@jacob: > The Okular team (or what's left of it, thanks ever so much guys) be careful... Lydia might ban your bugzilla account ;) > by thinking smart instead of putting everything into an option The current bar is completely useless for nearly all of my use cases and wastes a lot of screen space. Other people have different use cases and might find the bar very useful. Customization is imo the only solution to satisfy both aspects. > So why not think of an approach that a) releases the widget from its > toolbar and makes it use only the space that it actually needs, > maybe even making its background translucent, and b) if possible in > the given zoom level, putting it to the right of the page I use okular very often to read electronic schematics which are zoomed very high. There, the important details might be exactly in the corner where the widget was placed. Removing the bar completely and adding a toolbar widget like this in evince (http://ensc.de/evince.png) would be the perfect solution for me.
@ Christoph It is already there, look below (in attachments section). @ Jakob Complex solutions have cost. I would much prefer to use the "ugly" checkbox for a year now and see the seriously improved UI in next year, instead of not having anything and waiting for this new improved UI. > So, going forward: I'm surprised no one mentioned the obvious solution yet. See #15. It solves all toolbar/statusbar/you-name-it problems in all KDE apps. The catch? Yes, one -- complexity, and it means time (of implementing it). > if possible in the given zoom level, putting it to the right Why not on the left? > it > won't cover any text, ? How will you guarantee this? > or if the zoom level doesn't allow it, put it further to > the right anyways a) monitor has its limit b) another animation issue -- in office (non-games) apps such things should not happen
FWIW As a daily (hourly?) very grateful user of Okular and as a recent owner of a netbook, I would just like to add that I would be *extremely* happy to see the bottom bar hidden (or hide-able) in full-screen mode. Don't really care about normal (non-fullscreen) mode. (As per other comments I keep xpdf installed for just this use-case, but it is a pain). Offtopic a bit, but since there is comparison to gwenview in this thread: why is the "fullscreen" option in Okular (and Konq) under the "Settings" menu and not under the "View" menu (as in Gwenview and as would make a lot more sense IMHO)? Cheers M. PS Talk about storms in teacups...
PPS As an extremely grateful, satisifed user of okular, how about this for an idea: In fullscreen-mode, have the page number bar and backwards and forwards arrows appear only when the mouse cursor is moved to the bottom of the screen? I'm thinking a cross between a plasma panel with auto-hide, and the way the next and previous arrows pop up on the Comics plasmoid). I'm not a coder and realise that his would likely be a *huge* amount of work, so it is just a suggestion about something that would be *way* cool...
> In fullscreen-mode, have the page number > bar and backwards and forwards arrows appear only It would be changing one hardcoded behaviour to another hardcoded behaviour. It is not that the behaviour X is wrong, it is about X does not fit the whole world. > when the mouse > cursor is moved to the bottom of the screen? Usability abuse (exploration effect) and accessibility as well (forced mouse movement). You are right about "fullscreen" placement, but this another issue, so please post a separate report for it. Thank you.
(In reply to comment #56) > Removing the bar completely and adding a toolbar widget like this in > evince (http://ensc.de/evince.png) would be the perfect solution for > me. That is the perfect solution for me too. (IMO) Useless and redundant UI element is removed, no checkbox/option is added and functionality is the same. Widgets in toolbar are customisable, consistent and natural solution used everywhere in KDE.
As the author of the attached patch implementing a show/hide menu item, I would like to say I too prefer the toolbar widget alternative (for the same reasons Jakub gave in commment 61). I just don't know how to implement it.
Screen space while reading documents is way too important. In fact what about the support for a *minimal-interface*.
> I'm not a fan of putting into the toolbar what really > is not a tool, but more an information widget. I think this is not quite consistent: the magnifying bar is very similar, but still resides in the toolbar. Apart from that: currently, if I undock the toolbar, it stays visible even if I have a different application maximised. Is there a way to change this? Martin
(In reply to comment #3) > Created an attachment (id=23451) [details] > Patch to add a "Show Bottom Bar" option to the Settings menu. > > Attached is a patch to add a "Show Bottom Bar" (Shift-F7) option to the > Settings menu, with setting persistence. > > I still think it's better to just use a standard toolbar, but that would be > more work. I'd be very grateful if somebody could indicate how to apply this patch... Many thanks, Martin
This is a regression from KPDF, which had the page selection widget (group) in the left (narrow) view. Now Okular has it in the right (wide) view. In my case it takes takes 1495×30 = 44850 pixel instead of 240×30 = 7200 pixel. So it wastes 37650 pixel of my display (it is now simply gray). Of course, this regression could be fixed in some other way than putting it back where it was in KPDF. Someone already suggested to make each part available as toolbar item (and said that the previous/next are already there).
kde2eran, thanks a lot for the patch! All worked (finally) fine. But, somewhy, when I tried to apply "path -p1 < show-bottom-bar.path" to just-got-from-svn directory, if failed on part.cpp, chunk 4. I checked the .patch file by hand, but all seems fine. Well, it's just 10 lines of code, so I copy-pasted them. Then all built fine. Shift+F7 works, thank you. And about the problem itself. The current proposed solution (to hide the bottom bar by Shift+F7) is not bad for fullscreen IMO. While reading fullscreen, we don't need to go to certain page (and to see current page number) very often. If we do, we always can press Shift+F7 (or other easier shortcut we may define). And for non-fullscreen mode, I think it's better to implement a usual toolbar widget (like one in Evince).
tsukanoffkirill, good to hear the hide-the-bar patch is working for you. Do you mind testing and posting a fresh patch that cleanly applied to svn? (I don't have my build setup at the moment.)
Created attachment 43085 [details] New version of kde2eran patch @kde2eran Sure! Here it is - the updated patch. Tested on current svn.
Thanks for the patch! I have an idea, may be it is worth to move page number information to the window title? It would stop wasting screen space, but it would be still behind your eyes, easily accessible even when you choose to which window to switch. For example I often have several instances of the same document open, each on the different page. It is quite useful when you read books which have a lot of references to different part of the book on each page. In that case it would be quite helpful to have current page number in the window title.
Hi guys! Just to say I really love Okular - it's one of the applications I use most on my netbook. Being able to remove the bottom bar in the fullscreen view would make it ever so much better on my 10" netbook - it has a fairly wide screen which is only about 10cm in height... Without the bar the fullscreen mode would be great for reading e-books etc. I think the ability to hide this would be a great addition to this essential application! Thanks, Rob
Hey fellow users, apparently in Okular 0.10.4 (shipped with KDE SC 4.4.4) there is no bottom bar in full-screen mode anymore, and instead an unobtrusive hidden top bar that only shows when the mouse is moved to the top screen edge. A big thanks to the Okular developers! Personally, I'd still vote for additionally including a menu item to show/hide the bottom bar even in non-fullscreen mode, just for consistency (because the menu, toolbar and navigation panel can also be hidden there), but in the meantime, I'd say users with small screens should just view their PDF's in fullscreen mode.
(In reply to comment #72) > Hey fellow users, apparently in Okular 0.10.4 (shipped with KDE SC 4.4.4) > there is no bottom bar in full-screen mode anymore, and instead an > unobtrusive hidden top bar that only shows when the mouse is moved to the > top screen edge. This is the "presentation mode", which has always been available, and not the "full-screen mode".
Oh, right, of course, stupid me... (Guess I was a little too tired.) (Btw, another "solution" to this bug report might be to make the Presentation mode more generic (optionally allow zooming, panning and continuous page scrolling). Then the "normal" fullscreen mode would be redundant...)
Please provide an item in the "Configure okular" -> General Options-> Appearance screen to hide the bottom bar in a way similar to the "Show scrollbars" check box.
Let me first say I appreciate the work being done on okular (and all of KDE). Thank you very much for that. That being said, there is another case where I find it useful to hide the bottom bar: in the okular plugin for firefox by J. Sanders. With all the toolbars/menubars of firefox, those of okular itself and the bottom bar, there isn't much space left for the pdf file itself, unfortunately. I am also in favor of putting the bottom bar elements in the toolbar (as in the evil acroread :-).
I remember when this bug was first reported some 2 years ago. I was hoping this would have been fixed in KDE 4.5 but it wasn't. Now I come to see the bug report with a huge discussion, flame wars, etc. That's sad. The issue is simple: allow us to hide the bottom bar. Allow us to do it in Full Screen mode too. Presentation mode doesn't work for me because Presentation Mode doesn't trim margins, even if it is selected. So that's it. It's very simple. Technically, it may not be so simple, but people have suggested way so doing it, and some have even posted patches. So what's the real hold-up? Is it technical? Is it political? Let's work over these problems and let's get this merged in 4.5.1!
@Alf It is not technical. This report developed into a rather nasty dispute between some developers and users. One (was it two?) developer actually stopped working on Okular because of it. As can be read from comment #40 by Albert, the community is on a hold. Please accept that is a sensitive issue. The Okular team is fully aware of it and will take action when they see it fit.
Obviously if we ever end up adding this feature it will never be part of KDE 4.5.x since no new features are allowed on stable releases.
To Albert Cid: This could make it into 4.5.x. It's a matter of semantics. It could be considered a missing option, or something that was ready for 4.5 but didn't make it, etc. If it is considered a feature, it is a very small feature indeed that would not break the spirit of the bug fix releases. If it can't make it to 4.5.1, then 4.6 will be out in six months. Let's have it then. But, let's not make it conditional on people behaving. From what I see in this long thread, I see both sides misbehaving. It is very rude to be so demanding (limosnero con garrote), but it is also unfair for those in control of the code to hold the users hostage. Both sides have been uncivil. So let's put grudges and differences aside, let's swallow our pride, and let's start getting work done again. Okular is great! It is flexible, it is light, it is attractive, it is easy to use, and it has most of the features power uses crave! You wouldn't get this type of reaction from the user community if we didn't like Okular! We care about it! We like it! We want it to be even better! That's why we, the users, are so passionate about improving it! If we didn't like it, we would have moved to something else.
+1
After reading Albert Astals Cid's latest blog post about Qt merge request process (http://tsdgeos.blogspot.com/2010/10/qt-gitorious-merge-requests-and-open.html) I just have to ask: what's the current status of this feature request? There are patches, there is a clear demand for this feature and KDE SC 4.6 release date is getting closer, where new features are allowed. Is there a definite answer about this? Is there something else we can do to make it happen? If not, I think stating that this feature won't ever be allowed is better than the current state of indeterminism.
It seems very likely that the feature won't go into KDE 4.6. We are past the soft feature freeze and Okular has no listed items in the feature plan, which means if the developers take these schedules seriously, then we won't have this added. Pity for Okular's usability on netbooks...
This feature is being ignored because of the misbehaviour of some of the users commenting on it. Unfair? Probably.
It is not the question if it is unfair or not. It is the problem of an engineering decision is being made based on emotions. Also, why _all_ (well, all those who would like to use a real fullscreen mode) Okular users are "punished" because of a few ones misbehaving? For me this is beyond any logic...
This is not about engineeering, this is about life. If your little kid hits you and cries because he doesn't get candy, you don't give him the candy, this gives the bad example for him and tells him that acting in a bad way will get him through. This is exactly the same, if we implement this feature it will show people that misbehave that they actually get the results they want when they misbehave.
Perhaps we should think of comment trolls as conducting a "denial of service" attack on the open source development process. We shouldn't let anyone prevent us from developing and using the best software we can, just by posting some nasty comment to an open website... Albert, implementing this feature will show the people that misbehave that they are *ignored*, and that it's the people who offer constructive comments and patches (e.g., comment #3 and comment #69) that have an impact.
Software development is a form of engineering. Deciding if you implement a feature or not is an enginnering decision therefore. What you explained now only reinforces what I have said above. In my opinion such decision should never be made like this... but well, we don't have to agree with each other. I guess you could as well close this bug with a WONTFIX if things stand like as you say.
Albert, do you really think misbehaving users still care about this feature? They probably carried on with their lives and went to troll elsewhere. Why weren't they banned from this site instead?
In fact, there are no "kids" to educate. You are dealing with lots of Okular users, most if which aren't even aware that this discussion exists.
(In reply to comment #86) > This is not about engineeering, this is about life. > > If your little kid hits you and cries because he doesn't get candy, you don't > give him the candy, this gives the bad example for him and tells him that > acting in a bad way will get him through. > > This is exactly the same, if we implement this feature it will show people that > misbehave that they actually get the results they want when they misbehave. Albert, what is more important to you, engineering software and make it the best you can or educating, punishing users that in your point of view are misbehaving? I think you have no mandate to educate users. Just as users don't have a mandate to dictate you to implement a feature. IMHO this is getting *really* ridiculous and is far beyond any professionality. So if there are hurt feelings its better to state them and to sort them out instead of recycling the "you have to implement it or accept a patch" - "I won't implement it or accept a patch" loop. In order to leave the loop one has to jump over his/her own shadow and has to do it.
Kelytha, Martin, you guys really need to learn how to convince people because hints about "bad engineer" and "not professional" are exactly how not to do it ;-)
Stating my opinion, and saying that we don't have to agree is not a hint about "bad engineer". It is only an opinion, nothing else. Please don't see something into my words which I never put there.
SVN commit 1191188 by aacid: Make 53 users happy by allowing to show or hide the bottom page bar Based on a patch by kde2eran@tromer.org BUGS: 157284 FIXED-IN: 4.6 M +3 -0 conf/okular.kcfg M +20 -5 part.cpp M +3 -0 part.h M +2 -1 part.rc WebSVN link: http://websvn.kde.org/?view=rev&revision=1191188
Thank you Albert. I hope I never hurt you in the past, but if I did, accept my apologies as it certainly was not intentional.
Thanks, Albert! And re your comment #92: I think you misunderstood me. I perceived lack of professionality on both sides and saw the only way to resolve it with one side doing the first step - it could also have been a "I am sorry" on some users side. Thanks you very much for doing this step. I appreciate it and never intended to hurt your feelings.
Thank you very much Albert! I'm really glad that you have put a happy end to this issue.
Thank you. I'd say much more than 53 users will be grateful.
Thank you, Albert for committing the patch! You have also fixed other issues, including some I have submitted, and I appreciate that.
As a user who has been quietly watching this frustrating discussion for over two years now, thank you Albert for finally taking the high ground and doing what is best for the users.
I hope something like this will never happen again in KDE. Please everybody, remember the costs of this wishlist-item that is finally resolved.
Thank you!
Albert, now that this issue have been happily resolved wouldn't it make sense to restore the limit of votes per bug to 20? In my opinion, a newcomer would have a hard time trying to understand why Okular is different to the rest of KDE SC modules in that respect and I fail to see any advantage of having a limit of 10 votes.
Alvaro i don't see this limit being linked to this discussion as far as i remember that's always been our limit and i see no reason to change it. Please if you disagree subscribe and write to okular-devel mailing list, there's no need to spam all the people subscribed to this bug about that since it has nothing to do about it.
I'm very sorry. I decided to publish my comment here because I was under the impression that the limit was set as a result of this particular issue (due to comments like https://bugs.kde.org/show_bug.cgi?id=157284#c29) and I intended to keep the message in context. Please, disregard my message. You're right that it's offtopic. I apologise to you and all subscribers and I'll try to be more careful next time.
for anyone perferring to keep it, but making it a standard toolbar; may i direct your awareness to bug 267790 sorry for posting this here, as this is resolved fixed; but bug 267790 is about a more flexible solution for this problem than simple hiding.