Re: eBook reader proposal
On Thursday 05 April 2012 15:55:44 Bogdan Cristea wrote: > This reminds me that the file browser used to open files is not very well > designed, so it might be an ideea to load an external QML component which > already allows to browse files (it would be great to be able to install some > filters into that component in order to see only supported formats) Definitely. We are going to create a general "Open Resource" (note: a Resource does not necessarily have to be a file) component available to all applications which uses Nepomuk instead of the folder structure to retrieve resources. We need that anyway and the reader should of course use this. And of course we will need resource type filters there as well. The only open question is when somebody will have the time to design and implement it. But we will have to find the time, so be assured that for our next release that component will be there (maybe with your help? ;) ). ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Thursday 05 April 2012, Bogdan Cristea wrote: > > so what may make sense is to take advantage of QML being able to show > > pixmaps natively and expose just some QObject based classes which provide > > the interface for fetching those pixmaps. this is what the current > > QWidget basically does already, so the work to make this happen should > > not be very big at all. > > Actually I think that we need to find a way to animate pages using QML, > something similar already exists for viewing images. > depending on will end up being implemented it could be done in 3 distinct ways: * every page is a separate qml Item: they would be animated just like the image viewer (inefficient?) * the viewer is a single component (either a qml item or a qwidget that exports properties to qml) dummy qml items would get the input and be animated, then they would set something like a transition property to the component, that would be how much to display of a page how much of the new page, this property would be easy to animate * the widget manages by itself completely both flicking, pinching and page switch Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Thursday 05 April 2012 15:17:15 Aaron J. Seigo wrote: > On Wednesday, April 4, 2012 18:24:43 Marco Martin wrote: > > from a technical point of view, a good way to proceed i think would be this: > 100% agreed. (no surprise :) > > good news is that the viewer area is already nicely separated from the rest > of the application. in fact, it is a QWidget that basically just paints > pixmaps delivered from the renderers. That QWidget (SlidingStackedWidget) is slightly more complicated than that because it allows to animate the pages on switch (horizontal flicks). So actually the pixmaps are put on QWigets (QLabels) contained in SlidingStackedWidget. Using pixmaps for rendering pages has some limitations: for chm documents following links is impossible, same for pdf files (not sure how poppler handles this). > > so what may make sense is to take advantage of QML being able to show > pixmaps natively and expose just some QObject based classes which provide > the interface for fetching those pixmaps. this is what the current QWidget > basically does already, so the work to make this happen should not be very > big at all. Actually I think that we need to find a way to animate pages using QML, something similar already exists for viewing images. > > while having this as a separately loadable QML component should be the end > goal, i think that to make that more achievable it would make sense to make > the current app work in the manner described above and then once it is > working within the app to make it a separate, externally-loaded QML > component. This reminds me that the file browser used to open files is not very well designed, so it might be an ideea to load an external QML component which already allows to browse files (it would be great to be able to install some filters into that component in order to see only supported formats) > > .. and that will be VERY cool as it will open up viewer capabilities to any > other app as long as this one is installed. To resume, I would see the application structure like this: 1. main window: in QML (partially implemented) 2. document loader (separate thread alowing to manage document types and a buffer with several pages) in C++ (already implemented) 3. okular core library in C++ (to be adapted) -- Bogdan ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Wednesday, April 4, 2012 18:24:43 Marco Martin wrote: > from a technical point of view, a good way to proceed i think would be this: 100% agreed. (no surprise :) good news is that the viewer area is already nicely separated from the rest of the application. in fact, it is a QWidget that basically just paints pixmaps delivered from the renderers. so what may make sense is to take advantage of QML being able to show pixmaps natively and expose just some QObject based classes which provide the interface for fetching those pixmaps. this is what the current QWidget basically does already, so the work to make this happen should not be very big at all. while having this as a separately loadable QML component should be the end goal, i think that to make that more achievable it would make sense to make the current app work in the manner described above and then once it is working within the app to make it a separate, externally-loaded QML component. .. and that will be VERY cool as it will open up viewer capabilities to any other app as long as this one is installed. -- Aaron J. 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: eBook reader proposal
On Wednesday 04 April 2012 18:44:52 Bogdan Cristea wrote: > Hi Thomas > > I am working on a package for OBS, but you have to wait one or two days till > I figure out everything. If you want to compile yourself, this is quite > straightforward: > * clone the project > git clone git://anongit.kde.org/scratch/cristea/tabletReader.git > * install dependecies as specified in the readme file (for qt-mobility make > sure that you install the version 1.2, for other packages the version is > less important). As root type: > zypper in libqt4-devel > zypper in qt-mobility qt-mobility-devel > zypper in libpoppler-qt4-3 libpoppler-qt4-devel > zypper in chmlib chmlib-devel > zypper in libdjvulibre-devel libdjvulibre21 > * compile and install the app > qmake && make && make install Thanks! I'll see what comes first: You completing the package for OBS or me finding the time to compile it myself ;) Regards, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Wednesday 04 April 2012 18:19:53 Thomas Pfeiffer wrote: > I will give feedback as soon as I get to try it out (which will probably > require getting it into the OBS, or giving me a binary to put on my device. > Detailed instructions for compiling it myself would work, too, of course). Hi Thomas I am working on a package for OBS, but you have to wait one or two days till I figure out everything. If you want to compile yourself, this is quite straightforward: * clone the project git clone git://anongit.kde.org/scratch/cristea/tabletReader.git * install dependecies as specified in the readme file (for qt-mobility make sure that you install the version 1.2, for other packages the version is less important). As root type: zypper in libqt4-devel zypper in qt-mobility qt-mobility-devel zypper in libpoppler-qt4-3 libpoppler-qt4-devel zypper in chmlib chmlib-devel zypper in libdjvulibre-devel libdjvulibre21 * compile and install the app qmake && make && make install regards -- Bogdan ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Wednesday 04 April 2012, Bogdan Cristea wrote: > > > > thoughts? > > Agree, there is room for improvements. I can do this myself, though more > feedback from UX experts would be useful (Thomas Pfeiffer ?). I'll also > have a look at how to integrate this in OBS. from a technical point of view, a good way to proceed i think would be this: * the part that actually loads and views the files would be a c++ qml import and ideally depend from the least amount of stuff as possible, so is possible to just import it and use it elsewhere * there should be just one window and one declarative view for the whole app in this way would be quite simple to develop an app that integrates perfectly and would be still simple to make another one that doesn't depend from much stuff if needed, while minimizing duplication -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Wednesday 04 April 2012 13:09:16 Bogdan Cristea wrote: > Agree, there is room for improvements. I can do this myself, though more > feedback from UX experts would be useful (Thomas Pfeiffer ?). I'll also have > a look at how to integrate this in OBS. I will give feedback as soon as I get to try it out (which will probably require getting it into the OBS, or giving me a binary to put on my device. Detailed instructions for compiling it myself would work, too, of course). ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
Hi > cool; i cloned it locally, made a few small modifications in a local > branch > (which git.kde.org is refusing to let me push; i might end up doing a > personal clone and pushing my changes there for now?) to things like the > animaton speed, the animation shape, spacing and margins in the top level > layout .. > > nothing major, just little tweaks here and there. > > some things that occured to me while doing this include: > > * it would be very nice to move from qmake to cmake; main benefit is that > cmake makes it easy to get rid of the hard coded values like "/usr/bin" > for installation. bonus point: it's the tool we use everywhere else so we > have lots of expertise available on this. i'd be happy to make the switch > with your blessing. I was thinking at the same think to have an uniform approach for application installing as for the other AP apps. Once I set a public repository, I'll let you do this. > > * right now there is a top level QWidget based layout and things like the > toolbar, while done in QML, are in QDeclarativeViews inside that QWidget > layout. this really limits what is possible, such as being able to place > the toolbar on top of the content. what would be much nicer is to have a > single QDeclarativeView with all the QML in there and put the C++ > document widget inside that (which is pretty easy to do with QML's > QObject support). then we can do things like place the toolbar and other > elements more freely. it should also improve performance by avoiding the > overhead of multiple QML engines and, at least with QML2, will allow > painting and updates to be handled all in one render tree. > > thoughts? Agree, there is room for improvements. I can do this myself, though more feedback from UX experts would be useful (Thomas Pfeiffer ?). I'll also have a look at how to integrate this in OBS. > > (btw, noticed the blue border is already gone around the document area and > some of the other changes you've been making behind the scenes as well ... > generally nice stuff In MeeGo I have not seen this behavior, but in openSUSE 12.1, notebook plasma, this was indeed an issue (now corrected). Also, the touch screen was not handled properly, so I needed to set window hints flags. regards -- Bogdan ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: eBook reader proposal
On Tuesday, April 3, 2012 13:01:29 Bogdan Cristea wrote: > tabletReader, which I would like to expand to became an eBook reader for AP. cool; i cloned it locally, made a few small modifications in a local branch (which git.kde.org is refusing to let me push; i might end up doing a personal clone and pushing my changes there for now?) to things like the animaton speed, the animation shape, spacing and margins in the top level layout .. nothing major, just little tweaks here and there. some things that occured to me while doing this include: * it would be very nice to move from qmake to cmake; main benefit is that cmake makes it easy to get rid of the hard coded values like "/usr/bin" for installation. bonus point: it's the tool we use everywhere else so we have lots of expertise available on this. i'd be happy to make the switch with your blessing. * right now there is a top level QWidget based layout and things like the toolbar, while done in QML, are in QDeclarativeViews inside that QWidget layout. this really limits what is possible, such as being able to place the toolbar on top of the content. what would be much nicer is to have a single QDeclarativeView with all the QML in there and put the C++ document widget inside that (which is pretty easy to do with QML's QObject support). then we can do things like place the toolbar and other elements more freely. it should also improve performance by avoiding the overhead of multiple QML engines and, at least with QML2, will allow painting and updates to be handled all in one render tree. thoughts? (btw, noticed the blue border is already gone around the document area and some of the other changes you've been making behind the scenes as well ... generally nice stuff :) -- Aaron J. 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: eBook reader proposal
On 03.04.2012 13:01, Bogdan Cristea wrote: Hi I have just created a repository on git.kde.org with my application, tabletReader, which I would like to expand to became an eBook reader for AP. http://quickgit.kde.org/index.php?p=scratch%2Fcristea%2FtabletReader.git&a=summary The app is not yet tested on AP, but it is tested on ExoPC running Plasma notebook with openSUSE 12.1. My intention is to attract more attention on this project in order to get more feedback and contributions. Could we integrate it in the OBS soon so everyone can try it out on his or her own device? That would be very nice and helpful ;) ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
