I hope this doesn't [negatively] affect Profiles... @hius07

Presently this change would unfortunately be highly undesirable, and to a large degree I'm not sure if that can or even should change. E.g., being able to set ReaderPaging and ReaderRolling things in the same gesture half of which ignored when not applicable is a feature, not a bug.

I was kinda expecting something like that to be honest, would removing the elseifs ameliorate the situation? I still believe the reader and fm stuff should not overlap.

The reader and file browser are part of that. Actions like folder shortcuts can be started from anywhere but the file browser is a logical place for them.

Contrary to the rolling vs paging thing it's something that could be resolved more or less satisfactorily, but the solving would all have to happen prior to any disabling.

Folder shortcuts could be moved to "General" (seems reasonable) and remain accessible everywhere. File search can also be accessed from the reader so perhaps the same treatment...?

That way we'd have fm and reader stuff segregated.

I agree with both of you, @Commodore64user and @Frenzie

Like Frenzie said we don't want to disable them.

I like the context construct . Maybe it can be used in a help_func that generates programatically a infomessage with the context where the action applies.

ie: "$Named action is for scrolling read"

That way they can setup their actions in any context and still get useful info when in doubt.

Edit: I think the help_func is paired with a long press on the menu. Anyhow that's the intended behaviour of my suggestion.

I would support such division a lot!

I remember when I got confused the first time. I was setting up gestures in Reader, and also set up those for FM actions.

Then I realized that I needed time set up those FM gestures again, but from within FM.

I've just reviewed the code.

hold_callback is already in use by the dispatcher menu generator. Cannot be used to display text messages.

I'm not necessarily convinced by the eviction as opposed to duplication, but I suppose it's okay.

At a glance you overlooked export all notes. (I'd say definitely duplication for that one.)

it is not available from the top menu

The default menu has different goals.

File search should be available in Reader by a gesture.
OPDS catalog should be available in Reader by a gesture.
All actions should be available in FM/Reader for Profiles.
Generally, undesirable change and inaccurate implementation.

At a glance you overlooked export all notes. (I'd say definitely duplication for that one.)

that bad boy already is duplicated

File search should be available in Reader by a gesture.

it is. I was just asking

OPDS catalog should be available in Reader by a gesture.

will do

All actions should be available in FM/Reader for Profiles.

I came up with something... if you have a better approach, please feel free to comment.

Generally, undesirable change and inaccurate implementation.

think of the children, you are not thinking about them. In all seriousness, this is genuinely helpful for users new to the programme, I know it makes sense to you and me now, but normal user struggle figuring all this stuff out.

would these two also need to be in both reader/fm? not familiar with sync as I don't use it.

Don't waste your time.

I remember when I got confused the first time. I was setting up gestures in Reader, and also set up those for FM actions.

We can extend the menu item name:
Taps and gestures (in file browser) and Taps and gestures (in reader) as a reminder to an inexperienced user.

Taps and gestures (in file browser)

This solution sounds like trying to put white paint over the black paint. The result will NOT be a white surface, but rather something gray.

IMHO, a better wording would be something like Taps and gestures (**must be set while** in file browser) (and the same for reader).

What is needed to fix this ambiguity for real, is to sand down the black paint to bare metal, then put base, then emulsion, then white paint (and then lacquer). Which I believe this PR is trying to achieve: if users don't see unnecessary options, they won't be able to set them up and get confused.

I'm not convinced that graying out signals the app is a bit like two apps with some shared features. It seems much better to state it plainly, for example along the general lines suggested by @hius07, than to try to hint a little louder.

Forgot to say, but I do think the two can be complementary. I don't see any harm in this in principle.

I'm not convinced that graying out signals the app is a bit like two apps with some shared features.

i agree with that, and i do so because it doesn’t. Signalling that FM and reader are two separate entities is another beast altogether for which I don’t have a solution to. What this is a solution to is the problem of choice, instead of having hundreds of options to choose from, let’s only have the dozen or two that actually make sense. The alternative is to expect people to know that changing the margins with a gesture in FM doesn’t do anything even if the software is happy to accept it as input.

My thinking though is that upon seeing that some options are greyed out, a user might think that if the open from a book, they’ll be able to see those other options and that in my opinion should offer a slightly better user experience.

edit: perhaps it would be a brilliant idea to mention in the quick start guide that some settings work independently in fm and reader… that’s an idea.

I doubt that which isn't on page 1 is given all that much attention (though maybe a little later as a reference), but it can't hurt.

Any other comments here @Frenzie ?

@hius07 Do you still have misgivings? It seems more reasonable now, though I admit I'm also not the biggest fan.

I do not like the idea of disabling Gesture manager submenues.

Yeah, me neither. :-/