MobileRead Forums - View Single Post - "Could not load Pojy SDK" error on Anjuta

rfog · 01-21-2010, 06:02 AM

Thank you for your offering, Mackx.

I did it as a compulsive job, a head to head fight, a classroom exercise, because I tried to do at least 3 times before and I couldn't do it. BTW my Linux development knowings are little but I do not want to lose them.

My original idea was to take advantage of DR1000 making a true ergonomic software design, for example screen is too wide to read one column comfortably. Add multicolumn to Mobipocket reader and/or FBReader.

But those are own fantasies. I'm a seasoned Windows and Embedded C/C++ developer (BTW I'm Microsoft C++ MVP), and sometimes my work does not have enough challenges (most work goes in supporting our products instead of developing them) and I need to think in other stuff. As a hardcore reader I think my best will be to do some in ebook technologies, and that's why I'm here.

My current idea is to do a local client/server architecture based in plugins. Concept is to have a server that will accept ebook opening requirements and then offer it as a sequence of ready bitmaps to be printed on screen (or printer).

This way we have 3 components: a core server with no GUI, independent from screen technologies and other dependencies. One plugin for each ebook format (independent from screen and other dependencies) that will be controlled by the server, and some thin clients gui based on the ebook reader technology (GTK, QT, Framebuffer, X, ...).

Then thin client will pass server device characteristics like usable screen size, color or grey depth and so. Client will ask server to open an ebook. Server will run all plugins try to find a parser for the desired ebook. If found, it will start at the stored position to decode and prepare bitmaps of ready pages based in client information passed to server, that will serve to the thin client to be presented on screen (or printer). Stored position is controlled by the server annotating what is the last image served to client.

More advance stuff is that client will revert a modified/annotated page to server...

But as I said, its only a theoretical job. I do no have time to implement it and surely I will lose interest...

01-21-2010, 06:02 AM	#9
rfog Guru Posts: 696 Karma: 2383012 Join Date: Aug 2007 Location: Schiedam (The Netherlands) Device: Lots of eInk devices and iOS stuff	Thank you for your offering, Mackx. I did it as a compulsive job, a head to head fight, a classroom exercise, because I tried to do at least 3 times before and I couldn't do it. BTW my Linux development knowings are little but I do not want to lose them. My original idea was to take advantage of DR1000 making a true ergonomic software design, for example screen is too wide to read one column comfortably. Add multicolumn to Mobipocket reader and/or FBReader. But those are own fantasies. I'm a seasoned Windows and Embedded C/C++ developer (BTW I'm Microsoft C++ MVP), and sometimes my work does not have enough challenges (most work goes in supporting our products instead of developing them) and I need to think in other stuff. As a hardcore reader I think my best will be to do some in ebook technologies, and that's why I'm here. My current idea is to do a local client/server architecture based in plugins. Concept is to have a server that will accept ebook opening requirements and then offer it as a sequence of ready bitmaps to be printed on screen (or printer). This way we have 3 components: a core server with no GUI, independent from screen technologies and other dependencies. One plugin for each ebook format (independent from screen and other dependencies) that will be controlled by the server, and some thin clients gui based on the ebook reader technology (GTK, QT, Framebuffer, X, ...). Then thin client will pass server device characteristics like usable screen size, color or grey depth and so. Client will ask server to open an ebook. Server will run all plugins try to find a parser for the desired ebook. If found, it will start at the stored position to decode and prepare bitmaps of ready pages based in client information passed to server, that will serve to the thin client to be presented on screen (or printer). Stored position is controlled by the server annotating what is the last image served to client. More advance stuff is that client will revert a modified/annotated page to server... But as I said, its only a theoretical job. I do no have time to implement it and surely I will lose interest...