new version release planning

[houqp]

Um.. I think we are very close to the release now :)

I set up this issue as a check list to keep track of things that need to be done before the release. Feel free to edit it or comment below.

Todo

• add default.lua so user can still use the old one from keyboard branch

Done

• adapt source tree structure according to propose on adjusting directory tree structure (new UI branch) #756
• polish UI
  • more user friendly menu widget?
• make the final decision for the new name :)
  • KOReader, there you go
• switch the default branch on github to new ui branch since it's under more active maintenance

@hwhw could you create a new post in mobileread when the release is ready? A new thread can help us better keep track of things since we will have different groups of users for each version. Hopefully the announcement in new thread can also attracts new developers.

I think people will like the new scroll mode for pdf/djvu a lot. Kudo to @chrox 👍

EDIT:
issues need to be handled before release will also be tagged with "Next release" and added to new release milestone.

[hwhw]

Hi,

yes, of course I could do a new posting.

I agree, the menu widget should become a bit more user friendly - mainly,
this means a bit more spacing between items and maybe lines in between to
better outline the active areas. This is also true for the file manager, I
think.

I'm still in favor of OKReader, BTW :-)

[houqp]

I also like OKReader, let's leave that as candidate if there is no further objection.

[mayabtlaloc]

I agree also, for me OKReader is the best option.

[tigran123]

No objections from me on OKReader

[tigran123]

Is the full TOC tree-navigation support included in the new-ui branch? If not, any reason why not?

[houqp]

@tigran123 , sadly not yet :(

I really like to have it but I cannot think of an elegant way to implement it on current menu widget. Probably we have to write a dedicate tree widget for it. I would like to work on this for next release. But if anyone want to hack on it now, feel free to do so.

[tigran123]

Ah, I see. Yes, GUI programming is very unusual and difficult (esp. for a kernel hacker :)
I am now struggling with learning Android programming as I am trying to write a learning/testing tool for my School --- something like an interactive book...

[houqp]

Yeah, especially you are writing your own ui framework

BTW, I also plan to learn android to develop an open source device tracking app. ;p

[chrox]

I still prefer Koreader to OKReader as the official name of new release. Firstly, the shorter, the better. Ko·read·er is one syllable shorter than O·kay·read·er. And with only one capital letter, Koreader is easier to type than OKReader which will become less pretty in the forms of OKreader or Okreader or okreader. And the words "OK" and "reader" are so common that if new users mistakenly search with the phrase "OK Reader" in Google, they may be discouraged by the irrelevant results.

[tigran123]

Also, OKReader leaves the impression that it is merely "okay" I.e. barely use able, whereas in actual fact it is the most advanced and excellent piece of software technology.

[chrox]

Yes. I cannot agree with you more. And KOReader leaves this impression:

[hwhw]

I like the "companion" touch of "Koreader", too. And Tigran, you have a
point there. However, I get the impression we might be overthinking this.
Bikeshed coloring :-)

[houqp]

LOL, nice pic @chrox

I am OK with both names. The only thing that bothers me is they are bounded with kindle, but our reader can run (and already is running) on other linux eink devices. But I can live with that ;p

[houqp]

After mentioned linux and eink in the above comment, leviewer or lereader suddenly jumped into my mind. It also sounds like leetviewer/reader ;p

[houqp]

closing for now, let's leave that defaults.lua to next release.