Feature requests etc.

[repods]

just to be more clear
it's not a criticism to people that works for free for the community
it's more like a kind of sadness for this device being abandoned..
I personally don't like very much to use custom made firmware ( being a programmer myself) cause I usually see a lot of thing that I don't like if I read the code.. on the other hand I have not the time or the will to write something myself (well honestly I wrote something for my dr..); usually the user made enahncements lacks always in something, even simply by the design side..
so I like to use the official upgrades, that usually should really fix problems being done by people that have a full knowledge of the device. And consider that full knowledge is different from public knowledge.. a lot of things could be not public
in the case of the dr those nice guys at irex not only stopped the support after a couple of months from the market release.. but they did not even gave the source code of the uds that is what is really needed to fix the main problems of the reader..
so essentialy I don't want to waste even more time following their unlucky and unfair business and I'm going to buy another device..
but I will not sell the dr.. maybe in 10 or 20 years it will get a value.. being a so rare and misterious device..

[Mackx]

Originally Posted by repods

just to be more clear
it's not a criticism to people that works for free for the community
it's more like a kind of sadness for this device being abandoned..

Thanks for clarifying.

Originally Posted by repods

I personally don't like very much to use custom made firmware ( being a programmer myself) cause I usually see a lot of thing that I don't like if I read the code.. on the other hand I have not the time or the will to write something myself (well honestly I wrote something for my dr..); usually the user made enahncements lacks always in something, even simply by the design side..

You can join me and improve the code quality all modifications are in a public repository

Originally Posted by repods

so I like to use the official upgrades, that usually should really fix problems being done by people that have a full knowledge of the device. And consider that full knowledge is different from public knowledge.. a lot of things could be not public

Yes, this is true, not knowing every detail sometimes makes it hard to solve specific problems.

Originally Posted by repods

in the case of the dr those nice guys at irex not only stopped the support after a couple of months from the market release.. but they did not even gave the source code of the uds that is what is really needed to fix the main problems of the reader..

Yes that is unfortunately. I guess it has a legal reason. They probably signed an NDA with Adobe not to reveal any details of the used adobe-libraries (the DRM and the pdf parts). Publishing the UDS code would probably violate this.

Originally Posted by repods

so essentialy I don't want to waste even more time following their unlucky and unfair business and I'm going to buy another device..
but I will not sell the dr.. maybe in 10 or 20 years it will get a value.. being a so rare and misterious device..

So you will still be using it the coming 10 to 20 years? (to keep the battery into shape)

[Mackx]

Originally Posted by Iñigo

Sorry, can't understand.
As I understand, tags are extracted before selecting which documents will be shown, not the other way.

The current code first selects information from the database, based on tags.
The sql statement is something like: SELECT name, size, author, etc WHERE tag LIKE %book%. So the tags are not extracted, but used to select a subset of the documents.

Originally Posted by Iñigo

What about a list of ("operation", "tag") dropboxes inside a scrolled vbox:
<cut>
Problems with this design:
- disambiguation "(tag1 & tag2) | tag3" or "tag1 & (tag2 | tag3)"?
- list (and dialog) could grow too much => use a scrolledwindow for the verticalbox

Why would you want such complex selections of tags? I was thinking of adding '(A&B)|(C&D)' and '(A|B)&(C|D)' where D can be unused. The 4 functions would then be enough.
I will have an extra look at your proposal, but my gtk programming skills are limited...
I will experiment a little more with this interface to see if it is usefull for me. The biggest problem then is adding tags to documents. The current interface only support modifying one document at a time. Maybe I need to create something like the Delete functionality for Properties/Tags?
An alternative is to make a tool for the DR with export functionality that allows extraction of all current tags into a file that can be modified on a PC. The import functionality of the tool would update all tags from the file in the DR.

Thanks for the feedback.
Marcel.

[Iñigo]

Hi,

repods, your comments sound as excuses.

yes, we don't have access to UDS sources, but we can improve many things to make the DR a better device.

I'm not a programmer myself, it's only a hobby for me. And with my second child now I don't have much time nowdays... but I really thank IREX for providing the sources and SDK to allow anyone to improve their products (and that's in fact one of the reasons why I bought an iLiad and then a DR800).

Originally Posted by repods

I personally don't like very much to use custom made firmware ( being a programmer myself) cause I usually see a lot of thing that I don't like if I read the code.. on the other hand I have not the time or the will to write something myself (well honestly I wrote something for my dr..); usually the user made enahncements lacks always in something, even simply by the design side..

In my experience, sometimes external code is better than official one.
I'm talking in general, not about DR here, look at RockBox for example, but there are lots of examples.

Originally Posted by repods

so I like to use the official upgrades, that usually should really fix problems being done by people that have a full knowledge of the device. And consider that full knowledge is different from public knowledge.. a lot of things could be not public

... and sometimes external people, *the real users* know more about how a feature could be used... and if this people can write code, they develop those features... creating a better device.
Perhaphs the code is not brilliant, but the "new version" of the product is.
(and as I've said before, sometimes, the new code is better).

Originally Posted by repods

so essentialy I don't want to waste even more time following their unlucky and unfair business and I'm going to buy another device..

This is your decision, not ours.


But, think that if you have the knowledgement, you can do lot of things...
you can contribute: code, design, ideas, suggestions... there are many places to help, as Mackx has already mentioned.

That's the difference between consumers and *real* users.


Ok, don't want to do more cheap philosophy.
Finally, I recommend this book if you want to understand this feeling:

http://www.amazon.co.uk/Hackers-Hero...0193269&sr=1-1

Iñigo

[Iñigo]

Originally Posted by Mackx

The current code first selects information from the database, based on tags.
The sql statement is something like: SELECT name, size, author, etc WHERE tag LIKE %book%. So the tags are not extracted, but used to select a subset of the documents.

ok, I understand

Originally Posted by Mackx

Why would you want such complex selections of tags? I was thinking of adding '(A&B)|(C&D)' and '(A|B)&(C|D)' where D can be unused. The 4 functions would then be enough.
I will have an extra look at your proposal, but my gtk programming skills are limited...
I will experiment a little more with this interface to see if it is usefull for me. The biggest problem then is adding tags to documents. The current interface only support modifying one document at a time. Maybe I need to create something like the Delete functionality for Properties/Tags?
An alternative is to make a tool for the DR with export functionality that allows extraction of all current tags into a file that can be modified on a PC. The import functionality of the tool would update all tags from the file in the DR.

It was an idea, I didn't think too deeply in the matter.

Anyway, do you know glade [1]? is a GUI builder for gtk+/GNOME.
It comes with any gtk+-based linux distributions, and there are also packages for win32.
You can use glade to build GUI drafts/prototypes or even final UIs (as it generates .xml files that can be downloaded at runtime) [2].

Iñigo

[1] http://glade.gnome.org/

[2] glade can generate UI definitions in 2 different (XML based) formats:
- .glade: the old one. Needs libglade library for runtime loading of UIs.
It's obsolete in current GNOME desktops
- .ui: the new format. It requires gtk.Builder (since gtk+ v2.12, but improved in next versions)
http://library.gnome.org/devel/gtk/u...tkBuilder.html

I guess DR comes with gtk+ v2.12 so you could use gtk.Builder API and so not to depend on libglade dependancy.

[Mackx]

I already know about glade, but never looked deeper into it.
Thanks for the info and links!!

[repods]

about some new features..
I was thinking that it would be very useful a fixed zoom option (ie. you can zoom 105,115 % etc..) just like the pocketbook or asus.. in order to don't be forced to use the pen to zoom..
it should be not difficult to do even without the sorce of uds, because the zoom level should be a value set in that sqlite file..

let me know

[Mackx]

Hi repods,

I did not look at the uds_zoom_factor and how it is used so far. If I look quickly to its value, it seems to be -1 or -3 for most of my documents. So it seems to be more like a mode then a value or maybe negative values are modes (e.g. fit complete page, fit page width, ...) and positive values fixed zoom?
Do you have time to experiment and find out which values the uds_zoom_factor can have?
Do you have tooling to view sqlite3-files? Sqlite-manager seems a useful tool.

Regards,
Marcel.

[repods]

Originally Posted by Mackx

Do you have tooling to view sqlite3-files? Sqlite-manager seems a useful tool.

Regards,
Marcel.

well I was using "sqlite database browser" from standard ubuntu repositories..
in any case if I remember well the reader remebers the zoom level after the book is closed.. so the value must be stored somewhere
well I should simply copy the sqlite database on pc, zoom a book and see what value has changed in the database..

[repods]

some updates on the topic..
the reader remembers the zoom level if you close the book, or read another book or do a soft power off..
but if you do a full reset .. where the "indicizing files" shows up it loose the zoom level while instead still remembers the last page..
this make me think that is not stored in the global.db..
what exactly happens with "indicizing files" ?

[Mackx]

The 'zoom-data' is stored in the local databases that are in each folder. They are called metadata.db. See the 'application_data' table, which contains a list of file_id/key/value entries. The 'file_metadata'-table can be used to link the file_id to a filename.
The zooming factor is stored in keys named: 'uds_zoom_factor'.

When 'Indexing files' is shown on the display, a program called mdbindex is executed. The sources are in iRex\Sources\4.0\iRex\ctb\src together with the source code of ctb. See the makefile to see which files are used.
The main functionality is in a function called index_full() in the file index.c. Which first reads all data from global.db, then all data form the SD-card and then updates global.db with all changes (added files/removed files). It does not touch the local metadata.db files, so zooming factors are not modified.

I hope this information is usefull.

So next steps is to try to figure out how the uds_zoom_factor is used by UDS.

[Iñigo]

Originally Posted by Mackx

The 'zoom-data' is stored in the local databases that are in each folder. They are called metadata.db. See the 'application_data' table, which contains a list of file_id/key/value entries. The 'file_metadata'-table can be used to link the file_id to a filename.
The zooming factor is stored in keys named: 'uds_zoom_factor'.

When 'Indexing files' is shown on the display, a program called mdbindex is executed. The sources are in iRex\Sources\4.0\iRex\ctb\src together with the source code of ctb. See the makefile to see which files are used.
The main functionality is in a function called index_full() in the file index.c. Which first reads all data from global.db, then all data form the SD-card and then updates global.db with all changes (added files/removed files). It does not touch the local metadata.db files, so zooming factors are not modified.

I hope this information is usefull.

So next steps is to try to figure out how the uds_zoom_factor is used by UDS.

Take a look at this thread: https://www.mobileread.com/forums/showthread.php?t=93466
Specially post #4: run "dbus-monitor" on the emulator shell, zoom on the emulator screen and see if the zoom factor is passed.

Hope it helps,
Iñigo

[Mackx]

@Iñigo: Thank for pointing to that useful tool, I somehow forgot about it.

@repods: I looked quickly at the values stored in metadata.db (on the emulator) and it seems indeed that values > 0 are used to indicate a zoom level, numbers smaller then 0 probably indicate a predefined zoom-mode (full document, page wide, etc).
Maybe you can tell more about what you need. Is the problem that the zoom values are lost after a reset of the device? I cannot find a clear explanation for that.

[repods]

Originally Posted by Mackx

@repods: I looked quickly at the values stored in metadata.db (on the emulator) and it seems indeed that values > 0 are used to indicate a zoom level, numbers smaller then 0 probably indicate a predefined zoom-mode (full document, page wide, etc).
Maybe you can tell more about what you need. Is the problem that the zoom values are lost after a reset of the device? I cannot find a clear explanation for that.

damn you are absolutely right.. the positive values are the zoom levels..
I didn't noticed that, I just saw only negative values in my files
so the fixed zoom level hack can be done..

at this point what in your opinion is uds_view_port ?
something related with panning mode ?
I think so .. they are 1 or 2 values positive or negative.. for sure the offsets from the center on x and y axis

[Mackx]

Originally Posted by repods

at this point what in your opinion is uds_view_port ?
something related with panning mode ?
I think so .. they are 1 or 2 values positive or negative.. for sure the offsets from the center on x and y axis

I also think it has to do with the offset of the part that needs to be shown. But I am not sure to what they are the offset, centre or left-upper corner.