PRS+: Enhanced firmware for Sony Reader, Folders, Games & more

[TallMomof2]

What's the chance of porting PRS+ to the 600? I know that you have the 300 up next per the website. I bought a very cheap 600 and it's pretty nice as is but it would be much better with PRS+.

A different question. Is it possible to add a search function to prs+? I picked up a cheap 505 off of ebay and PRS+ really adds a lot of functionality but I miss searching.

kartu - Thanks for your huge contribution, PRS+ really adds core functionality to the 505.

[Billiam]

Are you looking for developers for the prs-300 port?

[omk3]

Originally Posted by kartu

Here is a very detailed guide on fonts and sony. It also applies to PRS+.
https://www.mobileread.com/forums/showthread.php?t=28447

Thanks. With a lot of reading and A LOT of trial and error (mostly error), in the end I used the universal flasher and successfully replaced the sans serif system font with Liberation Sans, which is gnu and has modern greek glyphs. However, whatever I do, whichever font I try, I can't get the sans serif font to change. I know it's less important because I can just use css to display any font I like in my books, but still, it's driving me crazy.

[Edit] So I read some more and it seems that this thing is normal. Font for lrf is probably changed (don't have greek lrf to test it), but epubs need their own hacking. Sigh. I'm hoping there is an easy way to do it through prs+. More reading to do, it seems.

[Edit2] And yes, it was actually a feature of prs+ and surprisingly easy. The only difficult part was reading through pages and pages to find the information I wanted.

So once again THANK YOU, my reader feels like a whole new device now!

[m-land]

Originally Posted by kartu

m-land
"Virtual Keyboard" is one of the planned PRS+ modules. I was going to do it myself, then kravitz came and expressed interest in implementing it (I'd be busy porting stuff to 600/300 in the near future so I anyway won't have time for this), currently he's working on message boxes so I think it won't harm if you give it a try. It will take several iterations to get it right anyway.

Requirements (sort of)

1. Preferred way to render the keyboard - setting label values/drawing. If not possible/feasible images could be used.

I'm trying I have some ideas, I make some 'proof of concept' work and I hit problem - rendering the keyboard. I've following questions:
-do anyone know how to create 'visual items' like label dynamicaly? (not hard-coded in xml)
-is there some not proportional font? I did some tests and all 3 fonts seems to be proportional
-do anyone know how to use grid element? based on fskin there is one, by during my tests I was never successfull

any help would be fine!

[kartu]

TallMomof2

What's the chance of porting PRS+ to the 600?

Very close to 100%.

A different question. Is it possible to add a search function to prs+?

Probably yes. However it would make sense only after we got virtual keyboard.

Billiam

Are you looking for developers for the prs-300 port?

I don't think it would help in case of porting to 300. But other than that, PRS+ is an open project, sources (along with entire history) build scripts are available. If you can contribute, you are welcome.

omk3
Glad you've figured it out.

m-land
It could be that some controls exist only on desktop version.
In kbook.so kbookAbout is using dynamically created TextEdit element.

[m-land]

Originally Posted by kartu

m-land
It could be that some controls exist only on desktop version.
In kbook.so kbookAbout is using dynamically created TextEdit element.

Hmm, I'm testing most of the time in Mark's testing enviro (FSK Test-Environment for Autorun Applications under MS-Windows) - grid hangs me there. (I know, even there it could be not implemented)
Regarding TextEdit - yes, I'm able to create this object dynamicaly, set text and attributes. Only detail I'm not able to do - display it

[kartu]

m-land
Well, dynamically positioning buttons is not absolutely necessary after all. I also suspect that TextEdit stuff consumes more resources than a simple label. You could try to do it with static labels grouped for each row, say up to 8 rows, with one group per row. (referencing them is also easy, if you use ids like row0,row1, bn1,bn2 etc). Keyboard selector could be on the bottom row. (like [Lat][123][Русский][ქართული], with current highlighted somehow)

[edbro]

I'm looking for clarification on the epub style.css switcher. I have read the caveat that said it only affects books opened after switching. Does that mean that once a book has been opened there is no way to change fonts without removing the book from the device and reloading? Is there any way to "close" the book on the device and reopen?

[kartu]

edbro

Does that mean that once a book has been opened there is no way to change fonts without removing the book from the device and reloading?

No, it's not like that. Simply open any other book, than open the book you were reading again.

[m-land]

I prepared pre-alfa release of virtual keyboard. It is rather 'proof of concept'. Should be placed in addon directory.
files:
xDictionaryCL.js - only slightly modified DictionaryCL - simply to allow my test be started, I was lazy to write my own or modify this one well.
kb.* - implementation of testing application
other files - keyboard implementation

All this info could be read from sources, just to see what to look for:
Keyboard implementation:
-one line (view tag) in kb.xml
-switching on/off in kb.xml
-keyboard output handling functions

keyboard definition is quite simple (I'll put sample here). My idea is, that in the future keyboard definitions could be in files in special directory (similar to addons). Digits definition keyboard (example):

kbdList.push(new kbdDefinition('Digits','123', [
    ['1', '2', '3', '4', '5', '6', '7', '8', '9', '0']
]));

Keyboard 'public' methods
kbdActivate - switch keyboard on/off

Handling functions:
doKbdInput - user enters his input. Normally keyboard will be deactivated in 'user code' after this (not in my sample)
doKbdProgress - writing progress (single letter callback). Usually will not be implemented in user code (rare usage)
doKbdCancel - keyboard was deactivated by user

keyboard buttons
digits - row/column letter selection. Row 0 is allways for keyboard switching
center - send input to user code (doKbdInput)
mark - backspace
markhold - clear input
menu - doKbdCancel (deactivates keyboard)

sample code buttons
left/right - deactivates/activates keyboard
menu - exit

What is missing
A lot Main things are:
-there is 'status line' in keyboard - just for my debugging now
-visual aspects (a little of graphics)
-selected row (first digit) visual feedback
-resizing of keyboard when switched
-keyboards config in PRS+ (not topic now)

I'd be glad if PRS+ developers could take a look to this and give me some feedback:
-if it is in direction they expected
-comments, requirements (if so)

Marek

[kartu]

m-land
Good start.

My feedback:

• Don't focus on how keyboards will be loaded, this is still tbd.
• Avoid having business logic in xml files (doMark).
• Try to avoid target.bla =, preferably define dummy function and expose only public stuff. (check existing prs+ code for examples)
• Don't expose vk internals, nobody should be able to directly push something into its arrays.
• Letters need to be bigger and a bit more squarish (vertical size closer to horizontal).
• Column indices are missing
• tab labels might have fixed size, but not the same as letters, switching between them should be by using some key (uhm, say "holding numeric button", tbd)
• A bit more comments in the code would be nice...
• I'd dream about dynamic column number. (sudoku has code that is resizing/moving stuff around)
• Would be nice to have colored stripes mildly highlighting rows/columns
• Keep in mind, that eventually VK group will land in main.xml

[m-land]

please see my comments underlined
Good start.
thx

My feedback:

• Don't focus on how keyboards will be loaded, this is still tbd. Sure. I was only keeping in mind to have easy way open.
• Avoid having business logic in xml files (doMark). there is not bussines logic in XML. File kb.xml is only my keyboard testin utility - it is not part of keyboard. Enyhow I'll keep it in mind.
• Try to avoid target.bla =, preferably define dummy function and expose only public stuff. (check existing prs+ code for examples) I'll try to take a look. I use this target.bla stuff only for keyboard code, it is not pushed into 'user' XML.
• Don't expose vk internals, nobody should be able to directly push something into its arrays. Not sure I know how to avoid this.
• Letters need to be bigger no problem. On the other hand - bigger letter=bigger keyboard and a bit more squarish (vertical size closer to horizontal). I have in my mind that it could be usefull to have several letters on key. eg SPC for space ect.
• Column indices are missing I know. It is of this visual sugar missing I'm going to improve this anyhow soon.
• tab labels what are tab labes? 'keyborad switchers? might have fixed size, but not the same as letters, switching between them should be by using some key (uhm, say "holding numeric button", tbd)
• A bit more comments in the code would be nice... it is only proof of concept, not public code. I'll put comments, do not worry
• I'd dream about dynamic column number. (sudoku has code that is resizing/moving stuff around) I'm going to implement resizing in means of vertical size anyway. Not sure what changing number of columns will give us. But why not - TBD
• Would be nice to have colored stripes mildly highlighting rows/columns do not understand
• Keep in mind, that eventually VK group will land in main.xml I'm not sure it could be done. Whole keyboard XML (vkbd.xml) is included using view element

Fine, at least I know it is not complet s..t and could be continued.

[kartu]

m-land
Regarding not exposing stuff, example1, a lot of stuff is visible:

var VirtualKeyboard = {};
var somethingNotForPublic...;
function somethingPrivate() {
...
}
VirtualKeyboard.publicFunc = function() {
....
}

example2, only VirtualKehyboard.somePublicFunction is exposed (functions have their own scope, not visible outside):

var VirtualKeyboard = {};
var publicFunc;
var tmp = function() {
	var somethingNotForPublic...;
	function somethingPrivate() {
	...
	}
	publicFunc = function() {
	....
	}
};
tmp();
VirtualKeyboard.publicFunc = publicFunc;

Regarding variable column size, it would allow to zoom. By the way, did you check if labels support re-sizable skins (uhm, or any skins at all actually )? TextEdit definitely does. One could also use panels.

Regarding row/column highlighting, I meant something like this:
http://www.resolverhacks.net/resolve...-html-html.jpg

By "tab labels" I meant keyboard switches, yes.

[m-land]

I've problem developing addon to PRS+. I do most probably something horribly wrong - but what?
I attach file VK.zip. When I copy it into addon directory than PRS+ does not start and there is single line in prsp.log saying Error initializing: Too big script!. Could anyone help me? (my code was much bigger, I strip it down)
PS: yes, it was attempt to integrate virtual keyboard to PRS+ utils because of my tests

[m-land]

Originally Posted by m-land

I've problem developing addon to PRS+. I do most probably something horribly wrong - but what?
I attach file VK.zip. When I copy it into addon directory than PRS+ does not start and there is single line in prsp.log saying Error initializing: Too big script!. Could anyone help me? (my code was much bigger, I strip it down)
PS: yes, it was attempt to integrate virtual keyboard to PRS+ utils because of my tests

Hmm, just now I take a look how addons are loaded and they are combined into one big script. Soto reproduce my problem you have to copy xDictionaryCL there as well). But as all files are combined together - really size could be a problem.
Is there any reason why they are not loaded one by one (load single script, run single script)..