Currently, unless one downloads nThe design behind using navbar in downloaded ebooks.

[sup]

Currently, unless profile is set to Kindle and output format to mobi, one gets a navbar ( Next | Section menu | Main Menu | Previous |) and "This article was downloaded by calibre from LINK" when downloading news through recipes in each article.

I do not understand the logic behind this.

1) Why is this set through profile? I*own both a Kindle (old Paperwhite) and a Pocket book (Inkpad 741 Color) and I do not see why Kindle does not need them and Pocketbook does. Pocketbook knows how to use a TOC, Kindle knows how to follow the links in the navbar. What is the difference?

2) Why output format has anything to do with that is also a mystery to me.

3) I love Calibre, but puting its name to every article downloaded feels more like spam than anything else. (I know, I could edit the source code, but that is nor really the point).

4) I can see that it can be a matter of preference - some people prefer navbars, some people, like me, just find them super annoying. I*do not mind them being on by default. However, why is avoiding them governed by such an obscure mechanism?

5) A further problem with this is that this setting is not atomic. I like the title of the downloaded news to have date in it. Output profile set to mobi causes that to not happen. So I can either have no navbars or date in the title, but not both.

6) Another mystery to me is if the output profile changes anything else. It feels weird and counter-intuitive to set it to kindle even though I*use Pocketbook.

This seems to be coming up now and then:

https://www.mobileread.com/forums/sh...d.php?t=133714

https://www.mobileread.com/forums/sh...ad.php?t=92371

https://bugs.launchpad.net/calibre/+bug/1870580

https://bugs.launchpad.net/calibre/+bug/1744057

(and I am sure there is more, I*definitely asked about it years ago but cannot find it)

[BetterRed]

Moderator Notice

Moved out of Development subforum, see ==>> PLEASE READ BEFORE POSTING HERE - Purpose of Development subforum

BR

[sup]

*I read it and I thought it applied (or is it a fundamental design decision)?

[BetterRed]

I didn't get the impression that you have, or have any intention of writing any code to enhance the calibre core or develop a plugin. Tell me I'm wrong and I'll move it back.

BR

[theducks]

Originally Posted by sup

*I read it and I thought it applied (or is it a fundamental design decision)?

IF you were writing code, your Q might apply.

This is for Code Writers, not general questions on why the authors did what.

Sometime code developers DO call for a 'design review' of proposed code.

Lots of folk only ever use one OS. Some decisions are because cross platform uniformity forces a certain way.

[sup]

Yes, I*might give it a go at doing about it something code-wise, depending on the answer and I*looked around the code already.

[BetterRed]

@sup - posting ii the Dev subforum won't attract any greater attention from the calibre designers than having it here, but having it here might attract the attention of someone who's figured out how to 'workaround' some of your concerns.

BR

[sup]

Ok. I am still interested in the answers. I would like to know if the way things are is a results of a thought out design or it is just that way because it has been that way for longer than anyone remembers. (because if it is not a design decision, then it might make sense to fix it).

[kovidgoyal]

Yes, it's by design. The navbars are extremely useful and they are not present for kindles because kindles are alone amongst e-ink devices in providin their own specialised UI for navigation of periodicals.

[sup]

You mean these two views in the images attached? I do not see how they provide functionality that is so different from other readers, i.e. Pocketbook. It also allows you to browse the ToC of a periodical. I agree the Kindle's interface is a bit better designed but I do not see much difference in functionality apart from Kindle's function to skip to the next article. This function is present in the navbar but only at the beginning of an article.

What other differences there are?

I understand you find navbars useful. As can be see from a number of threads about them linked above, not everybody finds them useful. Why is it necessary to force them on users (unless they set their default profile to Kindle even if they own an altogether different e-reader?)

[kovidgoyal]

It's not going to change, deal with it.

[sup]

I*can deal with that. However I would like to know the rationale behind it because what you say does not make much sense to me and the whole https://github.com/kovidgoyal/calibr...ze/profiles.py looks mostly ten years old after which new profiles more or less stopped being added. I really fail to see how Kindle is that special from say Pocketbook (periodicals without navbar are perfectly usable on both).

I think it would deserve a cleanup (fbsizes seem to be a function of fbase, some profile do not inherit from each other like KindleDXOutput not inheriting from output profile etc.). However, since new profiles are not being added, it would make sense to allow users to "create" their own profile. A generic profile where they could fill in dpi and screen size etc. I include a mockup.

That would easily accomodate making navbar (and date in title) optional (now, some recipes set no_inline_navbars to True, for example, but should this really be left to recipe authors?)

I would be willing to implement these changes and I do not really see much downsides to it. People with modern e-ink devices are just puzzled by the current design as they typically cannot find their device there anyway.

[kovidgoyal]

I'm afraid my design goal is not to make sense to you.

[sup]

Ok, and why is being able to set a new profile a bad idea given that most of the current profiles are rather outdated?

I also really don't understand why the navbar cannot by optional if I am clearly not the only one asking for it and there are even recipes where authors explicitly disable it for everybody (so also for people who presumably want it) - this really is something different users have different preferences about.

I am again noting I am willing to contribute the patches (it would not be much work).

[sup]

And would you accept patches that would extend the functionality of customizing recipes so that one would be able to patch a given recipe instead of replacing it? This would have the advantage one would get updates to the recipe without having to re-apply one's own customizations every time the recipe gets updated.

I.e. the code inserted would get initialized after loading the recipe itself. So one could add something like

    conversion_options = {
        'no_inline_navbars': True,
    }

to the recipe and would get rid of the navbars. However, when a recipe changes because the website changes, the change would get applied while the customization would be retained.