Re: okular active
On Saturday 21 July 2012, Sascha Manns wrote: Hello mates, just a question. Is there any special CMake Opts for building okular-active? not any particular cmake options. it's needed the mart/okularactive git branch, plus plasma-mobile is a build dependency -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Okular active
On Friday, May 18, 2012 21:47:01 Marco Martin wrote: seems some unnecessary painting is still happening, especially when zoomed in (may require yet another level of pixmap caching) this *should* be improved as of today (so whenever new images are built). the view was getting repainted numerous times during rendering and there was an additional off-screen pixmap being used. please check when you can to see if it is rendering smoother for you now. -- Aaron Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Okular active
On Thursday 17 May 2012 17:47:15 Marco Martin wrote: packaging is fixed, unfortunately at the moment it still have to be launched from the shell with active-documentviewer pdfpath I have installed 2012-04-23-16-57-basyskom-plasma-active-testing-meego-usb- live.iso, but even after repository refresh I am unable to find okular-active. Which repo should I add ? -- Bogdan ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Okular active
On Friday 18 May 2012, Thomas Pfeiffer wrote: Hi Marco, On Thursday 17 May 2012 17:47:15 Marco Martin wrote: packaging is fixed, unfortunately at the moment it still have to be launched from the shell with active-documentviewer pdfpath Just tried it out. Although it might be a bit early for feedback at this stage, here's my first impression anyways: - The search function with highlighting within the grid is awesome! Although being able to step through results may still be necessary at some point, this is great for an overview of which page might most likely be the one you were looking for. Great feature! :) unfortunately seems a bit slow, we'll see if usable enough ;) (There is a bug when navigating to page from the search results, though, I'll file it on BKO). - Rendering the pages for the first time seems to take longer than in desktop Okular. I already thought Okular Active was pretty slow overall, but then I realized that it is actually quite smooth after the pages are fully rendered. However I'm sure this will still get optimized anyway :) seems some unnecessary painting is still happening, especially when zoomed in (may require yet another level of pixmap caching) - Unless the document is wider than the screen, it should not pan horizontally, as this is very irritating while scrolling (you usually don't move your finger _exactly_ vertically while scrolling) but in that case the problem would be that is not possible to switch page by horizontal swipe.. - The swiping distance required to trigger a page flip should be reduced (I noticed this recently in Images as well). Finding a good value there is very difficult. I found that e.g. in tabletReader the distance was too short, which frequently caused accidental page flips. However currently in Okular Active and Images, you have to swipe really long to flip a page / change switch to another picture, which feels a bit cumbersome Generally a very good start. I think that especially with your and Bogdan's efforts combined, we will have a really good PDF viewer in the end. Now if only we could get Xrandr working... On a general note: I like how the right drawer works in both the Resource Browser and Okular Active. I will write an HIG about it soon and suggest it to be used anywhere it makes sense. It allows for very nice interaction flows as well as consistency across applications. that's the idea that was behind it: apps should have a correct 3d-ish appearance, the blueish background be the deeepest background, while the paper-like one (and the various theme elements) should live over it. for applications that need a control area (either a sidebar or an almost entire screen as okular) one side of the screen should be draggable to uncover this control area, here we have 2 use cases: a) if the control area is ephemerous, chose an action and it closes again: case of okular and the side panels of the shell itself (recommendations, activities) it should look as a panel pulled over the app content, that never gets resized, and automatically closes b) if this area is something more long lived, something that will stay open until the user closes it because it can be useful after being used for the first ime, this is the case of the file browser. it looks like pulling the app content away and uncovering the control area, so has an higher z order (and the blueish background) and the app content area gets resized. that is the general idea, still has to be refined and put in a rigurous understandable form of course ;) Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Okular active
On Friday 18 May 2012 21:47:01 Marco Martin wrote: - Unless the document is wider than the screen, it should not pan horizontally, as this is very irritating while scrolling (you usually don't move your finger _exactly_ vertically while scrolling) but in that case the problem would be that is not possible to switch page by horizontal swipe.. These two are not mutually exclusive. See tabletReader as an example: It does not pan the page on horizontal movement, yet it still recognizes a swipe gesture to flip the page. So if the swipe is only very short, nothing happens. If it's long enough to trigger the swipe gesture, the page flips. Although it doesn't give feedback until it actually flips the page, I still immediately understood how to flip the page. Btw, this is also how several other touch-UIs do it: Not move the the element until the actual swipe gesture is recognised. It also feels less jumpy than always moving imo. that's the idea that was behind it: apps should have a correct 3d-ish appearance, the blueish background be the deeepest background, while the paper-like one (and the various theme elements) should live over it. for applications that need a control area (either a sidebar or an almost entire screen as okular) one side of the screen should be draggable to uncover this control area, here we have 2 use cases: a) if the control area is ephemerous, chose an action and it closes again: case of okular and the side panels of the shell itself (recommendations, activities) it should look as a panel pulled over the app content, that never gets resized, and automatically closes b) if this area is something more long lived, something that will stay open until the user closes it because it can be useful after being used for the first ime, this is the case of the file browser. it looks like pulling the app content away and uncovering the control area, so has an higher z order (and the blueish background) and the app content area gets resized. that is the general idea, still has to be refined and put in a rigurous understandable form of course ;) This is going to be quite hard to put in an understandable HIG, but I'll try my best :) ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Okular active
Hi On Tuesday 15 May 2012 22:08:14 Thomas Pfeiffer wrote: So is this based on Bogdan's work to integrate the Okular libraries into tabletReader or did he abandon this work or was it wasted because the result is just being discarded? tabletReader is not abandoned. I have been able to integrate okular core library into tabletReader, but there are some compilation problems due to separation issues between okular core library and its front-end. I am about to submit a patch to okular in order to try to fix some of these issues. This is why I am not yet able to provide an rpm, because I use a customized okular core library. And is there already a package in the OBS for testing it? If so, what's its name? The screenshot looks nice, but I'd like to see it in action so I can give feedback. I will give a try to okular active, maybe we will find a way to coordonate our efforts. regards -- Bogdan ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Okular active
On Tuesday 15 May 2012, Bogdan Cristea wrote: Hi On Tuesday 15 May 2012 22:08:14 Thomas Pfeiffer wrote: So is this based on Bogdan's work to integrate the Okular libraries into tabletReader or did he abandon this work or was it wasted because the result is just being discarded? tabletReader is not abandoned. I have been able to integrate okular core library into tabletReader, but there are some compilation problems due to separation issues between okular core library and its front-end. I am about to submit a patch to okular in order to try to fix some of these issues. This is why I am not yet able to provide an rpm, because I use a customized okular core library. atm i worked around the issues by duplicating pagepainter and having everything directly in the okular repo (mart/okularactive branch). okular developers wants to help getting the library in shape and being fully usable from outside the repo. And is there already a package in the OBS for testing it? If so, what's its name? The screenshot looks nice, but I'd like to see it in action so I can give feedback. I will give a try to okular active, maybe we will find a way to coordonate our efforts. totally, the most important thing i want to have is a series of components that just paint pages and provide metadata, no ui, so any app can be wrote with it (take a look at the components folder) -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
