Simplify keyboard shortcuts, use menu key for main operations

[dpavlin]

On several occasions I tried to explain how to use reader to new users, and concluded that current keyboard shortcuts are overly complex to explain in one go. Other developers seem to agree, since we just merged simpler user interface for zoom mode on M key.

My problem with current implementation is that it's key on main keyboard and I would love to have something similar under menu key.
It's nicely positioned near fiveway, which is where your finger are if you just opened document.

Everything you need to start using reader should be under menu.

Having said that, I'm against re-implementing everything, and my favourite task in development is reusing code, so I would suggest to add "rank" to all our keyboard shortcut and show reduced version of it under menu key, with ability to select options with fiveway if possible (so users don't have to move hands from fiveway to zoom page or something similar).

Same rank could be used used for grouping options together or hiding them from this quick menu.

In future I can envision multi-level menus, if possible reusing multi-level folding code for TOC.

Does this make sense?

[houqp]

Yes, complete agree with you. For non-geek users, having all operations moved to menu is the best choice. What's more, for K4, menu is the only choice...

As for multi-level menus, it is already supported in the new ui branch, and it is quite usable now. When I still have a K4 one month ago, I used this menus to managed all the operations.

So why not focus more on porting current features to the new UI branch so all kindle users can benefit from it. :)

[tigran123]

I understand the wisdom of the long-term approach of @houqp .
However, I personally consider K4 hardware (both touch and non-touch) a step backward, i.e. a degradation in comparison to Kindle 3 (aka "Kindle Keyboard"). I realize that we cannot influence Amazon's decisions, but still, to focus all efforts on K4 development just because Amazon happens to believe that that is where it can make money, is, imho, against the spirit of free software development, whereby we do things we feel are "right" and not because some big company thinks them to be "right".

So, I prefer to work on the old code base because it is ideally suited for Kindle 3, because I believe Kindle 3 to be the best electronic document (not just "ebook") viewer in the world at present. Hmmm, but so was Hanlin V3 at the time when I was working on the djvu viewer for it. And where it is now? Gone, obsoleted, because of having the old generation eInk screen which is rubbish in comparison to today's Kindle's Pearl eInk. Is this going to be the fate of Kindle 3 in 2-3 years? Perhaps. But even so, what I have learned in developing for Kindle 3 I would then try to port to whatever is the latest best hardware platform that will have appeared then. Anyway, these are just my thoughts :)

Having said that, of course I agree with @dpavlin that we need more menus as the number of keyboard shortcuts is growing too much, as long as this does not degrade any functionality pertinent to Kindle 3 in favour of supporting this new "K4" thing.

[houqp]

aha, I see your point :) After using my friends K4NT for a month, I also agree that it is a big step backward compared to K3.... Without keyboard, it just sucks... KTOUCH comes with screen keyboards, which might somehow solve this issue. I haven't tired with TOUCH yet, so can't comment on it.

OK, actually, the reason I prefer to work on the new ui code base is not mainly because I want to bring support for K4 series devices. I actually don't care too much about it since I am a K3 user. If I have to come up with a reason for supporting K4, then it will be "These users are already suffering from a crap hardware, so let's free them from the crap software".

Then why I prefer the new code base? Because it is simply more fun to code under the new code base:) It is better designed so I don't need to write that many duplicate codes. And of course it is less likely to write error code under the new code base (refer to #128). That means I can concentrate more on the feature I want to implement. The flexibility gives me power to write a very usable menu in far less code than I will need with the old code base. And I guess that will go the same for other features like scroll mode.

The coolest part for the new ui code base is the new ui framework can be easily used to write frontend for other programs! Just couple lines of code, we can have a clock widget that update its content in every second. It is not just a reader anymore, it is a light weight UI framework written from scratch. Yes, it is kind of re-inventing the wheel. But I just can't stop doing it ;P

Anyway, it is still great that you guys are hacking and improving the current code base. As a k3 user, I can still benefit a lot from it :)

[dpavlin]

To be honest, I had two days of soul searching before submitting this issue. I'm totally aware that we should move to new_ui branch (and to be honest, I consider current master as cleaning house for new_ui), but somehow, I always get drawn to master, just to add this simple feature or that.

[tigran123]

Does new_ui branch build easily and run in emulator? Or are there special instructions and extra pre-requisites on thirdparty software?

[houqp]

@dpavlin , feel exactly the same :) after all, we put so many efforts in it.

@tigran123, it should be easy to run in emulator, since we just re-write the lua code. No big changes in C code except for 8bpp framebuffer support, which have nothing to do with the emulator.

So if you want to play with it, just checkout the new-ui branch in HW's repo.

The biggest problem here is the lua code is completely rewritten, so it hard to simply merge current patches from master branch to the new ui branch. (At least I cannot find a proper way to do so in Git) So we have to manually pick or even write all these changes in the new ui branch. And now we are far behind the master branch :)

[houqp]

The good news and as well as bad news is today I accidentally dropped my kindle 3 on to the floor and broke the eink screen.... Now I have to wait for my kindle paperwhite. And this gives me one more reason to focus on the new ui branch... Hope I can managed to get some free time to hack when I received my new kindle...

[tigran123]

@houqp May I ask what is "kindle paperwhite"? Google-ing for it brings the Kindle Fire page, but surely you are not replacing an eInk reader with some LCD-based tablet? Or is there some new eInk-based reader called "paperwhite"?

[tigran123]

Ah, ok, found it! Oh, it seems for US-only at the moment :(

I see that it has a higher resolution (212dpi), but, unfortunately, it has a touch-screen and (more importantly) a guiding layer for the light. This latter causes very substantial degradation to the contrast. I own a Nook Touch Glowlight and when I put it side by side with Kindle 3 (eInk Pearl) and Hanlin V3 (ancient first generation eInk) it has the same quality as Hanlin V3 and MUCH MUCH WORSE than Kindle 3 --- all because of the extra layer for the light. The non-Glowlight Nook Touch is only very slightly worse than Kindle 3.

Oh, what a stupid thing we observe in the commercial "for-profit" real world --- they add excellent 212dpi screen and then destroy it by adding totally unnecessary features which only exist for the sake of making money for Amazon.