qPBReader v1.0 - epub reader for firmware 4 623/626

[m4mmon]

Hello,

I have developed an epub reader for pocketbook 623 and 626 with firmware 4.

Complete source code is here:
https://github.com/m4mmon/qPBReader

I also provide a ready-to-use version:
https://www112.zippyshare.com/v/Ic1nAoCu/file.html

I will not copy here the complete "README" you can find on github.
To sum up:

• qPBReader is a personal project, for my own use, and I thought it might interest other people, so here it is. I do not plan to really support it, I consider it as finished, and will probably not add new features.
• it is developed with Qt 4, and makes use of calibre javascript paged display stuff
• it supports only epub format
• it works basically like calibre ebook viewer, and suffers same pre-Qt 5 issues as it.
• it is integrated with pocketbook (page count, dictionary, etc.)
• it does not support notes, bookmarks
• it can be easily translated in other languages (currently supports english and french)
• manual true page counting, see readme on github to understand what "manual" means

I deliberately decided not to support touch actions for page changing, because I do not like that.


The following screenshots were made with qPBReader set to french. By default, it tries to load current system language and falls back to english. Translating the application is a matter of running Qt lupdate/linguist/lrelease and putting the generated file next to executable.


Dialog show when using menu button:


Text layout dialog. Features font size (in fact text zoom), book margins, hyphens:


Font options dialog. There is also an option to ignore embedded fonts:


Native pb dictionary dialog integration. Requires long tap on word:


Default parameters configuration (values used when opening a book the first time). Accessible from pb applications (qPBReaderConfig):


Since qPBReader is calibre-based, it also supports Mathjax (book sample from calibre):

[Dr. Drib]

Moderator Notice

M4mmon
Please take a few moments to read our Posting Guidelines, in particular the part about the maximum image size allowed (600x600 pixels). Images that violate those guidelines will be deleted.

It is every member's responsibility to read our Posting Guidelines and follow them.

Thanks.

[m4mmon]

I am in the process of building qPBReader for 626 + firmware 5.
Parts that were using QXmlQuery had to be rewritten since Qt is even more butchered with firmware 5 than it was with 4.
I am also struggling with some issues regarding the so-called SDK provided there.

1. libinkview.so is obviously incompatible with the one on the system image. I had to link with my system library to avoid nasty crashes. However, inkview.h seems more relevant than it was with previous SDK.
2. Why is there a Qt 5 delivered there since it is still Qt 4 on the system? I am really wondering what I am building against, and if the result is somehow working by pure luck.
3. There is no panel to display information (it is on top and does not seem to be accessible with API), DrawPanel2/4 etc. seem now irrelevant.

I am so pissed pb does not deliver something directly usable. And frankly, firmware 5 looks nice but is pure garbage.

[brucelee]

Originally Posted by m4mmon

libinkview.so is obviously incompatible with the one on the system image. I had to link with my system library to avoid nasty crashes. However, inkview.h seems more relevant than it was with previous SDK.

True. I did the same.

Originally Posted by m4mmon

Why is there a Qt 5 delivered there since it is still Qt 4 on the system? I am really wondering what I am building against, and if the result is somehow working by pure luck.

No idea. Didn't deal with QT in PB.

Originally Posted by m4mmon

There is no panel to display information (it is on top and does not seem to be accessible with API), DrawPanel2/4 etc. seem now irrelevant.

You can't do much with it. You can toggle show/hide and that's about it.

[m4mmon]

Thank you for sharing that.
I will try to hide/show it, and for displaying page number, add some Qt stuff. Optional would be nice, in order to occupy maximum available space on screen.

[brucelee]

Here's the code I used for that in CoolReader:

PHP Code:

bool systemPanelShown() {
    return GetPanelType()!=PANEL_DISABLED;
}
void hideSystemPanel(bool screenUpdate) {
    if( systemPanelShown() ) {
        CRLog::trace("hideSystemPanel(): PANEL_DISABLED");
        SetPanelType(PANEL_DISABLED);
        if( screenUpdate )
            CRPocketBookWindowManager::instance->update(true);
    }
}
void showSystemPanel(bool screenUpdate) {
    if( !systemPanelShown() ) {
        CRLog::trace("showSystemPanel(): PANEL_ENABLED");
        SetPanelType(PANEL_ENABLED);
        DrawPanel(NULL, "", "", 0);
        if( screenUpdate )
            PartialUpdate(0, 0, ScreenWidth(), ScreenHeight());
    }
}
void toggleSystemPanel(bool screenUpdate) {
    if( systemPanelShown() )
        hideSystemPanel(screenUpdate);
    else
        showSystemPanel(screenUpdate);
}
void toggleSystemPanel() {
    toggleSystemPanel(true);
} 


[m4mmon]

Thank you for the tip.
Unfortunately, even if I do it before initializing the main Qt dialog, it eats up space at the bottom of the screen, I think this has something to do with pb platform implementation. I have to find out what is going on there.
I can see pb Qt splash screen ("browser") moving up when the API is called, and space at the bottom is kind of lost.


Narrowed it... in Qt pb platform integration plugin. Qt system determines "desktop" size by substracting PanelHeight() to ScreenHeight(). It does not seem to care whether or not the panel is hidden afterwards.
I just verified that by LD_PRELOAD-ing this function and making it return 0. I have to find a proper way to notify Qt of "desktop" screen resolution change when toggling on/off the top panel, surely sending some signal or event to some object.

[brucelee]

I had issues with this too. For example, when showing the menu in CR (FW5), the entire display buffer offsets with PanelHeight() pixels.
So I did a dirty workaround for that (being the fact that while the menu is shown, no interaction is allowed with the rest of the app).
I activate the panel without drawing it, take an offset screenshot, redraw the screenshot, draw top & bottom parts of the menu and then update the screen.
If I wouldn't do the screenshot part I'd always get an annoying offset of the page text when toggling menu.
It's not an elegant way of solving things but I was too lazy to go deeper into the problem. )

PHP Code:

virtual void OpenTouchMenu() {

    [...]

    // Activate system panel
    CRLog::trace("CRPocketBookQuickMenuWindow::OpenTouchMenu(): Activate system panel");
    showSystemPanel(false);

    // Offset the background
    CRLog::trace("CRPocketBookQuickMenuWindow::OpenTouchMenu(): Offset the background");
    ibitmap * bkg = BitmapFromScreen(0, PanelHeight(), ScreenWidth(), ScreenHeight()-PanelHeight());
    DrawBitmap(0, 0, bkg);
    free(bkg);

    [...]

    // Draw
    CRLog::trace("CRPocketBookQuickMenuWindow::OpenTouchMenu(): Draw");
    DrawTop(false);
    DrawBottom(false, -1, -1);

    // Update screen
    CRLog::trace("CRPocketBookQuickMenuWindow::OpenTouchMenu(): PartialUpdate(0, 0, %d);",
        ScreenWidth(), ScreenHeight());
    PartialUpdate(0, 0, ScreenWidth(), ScreenHeight());
} 


[rkomar]

The new version 5 firmware seems to do some kind of trickery when it draws the toolbar panel at the top of the screen. To me, it looks like the panel is drawn at the bottom of the image (like in old firmware versions), and then the image is shifted down and the bottom part is offset to the top of the screen. When you disable the panel, everything is drawn normally.

When you don't want the panel to be shown: 1) SetPanelType(0), 2) draw to the full screen, and 3) don't call DrawPanel().

When you want the panel to be shown: 1) SetPanelType(1), 2) draw to the _top_ (ScreenHeight() - PanelHeight()) part of the screen, 3) call DrawPanel().

These steps are the same for all versions of the firmware. Version 5 will secretly move the bottom panel area to the top of the screen if SetPanelType(1) was last called, even if DrawPanel() was not called.

[m4mmon]

By playing with screen orientation spying for traces, signals etc. I found by changing orientation, everything was properly handled.
So Qt internal initialization stuff is properly triggered by doing this:

PHP Code:

SendEvent(GetEventHandler(), EVT_ORIENTATION, GetOrientation(), 0); 


I have no idea if this has any effect outside Qt context, but it might be worth trying.


edit: did not see your answer before rkomar, I will try to completely disable those DrawPanel functions.

edit2: avoiding DrawPanel calls does not make it my case. From what I understand, PB Qt platform integration makes use of inkview library. When starting Qt graphic stuff (which occurs at QApplication construction), InkViewMain is called, and internal window system is initialized with some defaults (i.e. Panel shown). When calling SetPanelType(0), QPlatformScreen is not notified of the change (QApplication::desktop()->screenGeometry() continues to return partial screen size). The simple call at the top of this message make stuff properly update.
Of course, this is speculation, but the result is here with Qt.
There are custom event types in PB platform integration. For now I have only discovered 1111 which simply wraps OpenRotateBox and perform SendEvent() stuff in handler, nothing more. So I guess EVT_ORIENTATION is properly processed in main event handler. And after that, QApplication::desktop()->screenGeometry() returns good value.
All I know it is valid only for Qt.

[rkomar]

Okay, but I was more replying to @brucelee's problem with the panel than to your problem.

[brucelee]

Originally Posted by rkomar

To me, it looks like the panel is drawn at the bottom of the image, and then the image is shifted down and the bottom part is offset to the top of the screen.

Talking about FW5:
That's something I don't really get. I accept shifting down because it kind of feels normal. It might be something that's meant to be that way or simply a huge bug. We'd have to ask a PocketBook developer for that.
From my point of view, it feels ok to automatically shift the view. But to wrap the drawing is really wrong. If you offset the buffer with 75px (assuming that's the case), well, when going over 949px things shouldn't wrap around. Like PanelHeight + ScreenHeight shouldn't overlap the top of the screen.

Originally Posted by rkomar

When you want the panel to be shown: 1) SetPanelType(1), 2) draw to the _top_ (ScreenHeight() - PanelHeight()) part of the screen, 3) call DrawPanel().

That doesn't work for me in CR3 because I draw the top panel, draw the top and bottom part of the menu and everything is fine.
But if something else updates the entire screen (like expanding the system panel menu and closing it) shit goes wrong.
I get the entire background page shifted downwards.
That's why I do the screenshot part I was talking about earlier. (And it's not the only possible way of messing around with the view.)

[m4mmon]

Just a small update about progress with firmware 5 on 626.
Everything is mostly working fine, but I have not spent much time these days on it. So no status bar yet (to display page count or so), and I made the mistake of updating to october 21st firmware (5.9_458), and something obviously changed inside Qt runtime, font combo box is somehow broken... pfff

[fedcod]

Excellent news for my Pb 623 ! Really great work, thanks