Closed pgaskin closed 4 years ago
NickelMenu is still safe to use, but the main menu items won't appear anymore. In addition, at least nickel_open
and nickel_misc:home
will need to be tested again to ensure they still work.
To put back support for the main menu, I can either turn the new clock which replaced it into a new menu, or I can add to the "More" tab, or both.
I haven't decided whether I'm going to release this as v0.4.0
or v0.3.2
. I'll probably decide based on how likely the necessary changes may inadvertently cause regressions for older firmware versions.
I will be testing most changes on 4.22.15268
and 4.23.15505
. I will also ensure the basic features still work on 4.6
, as that's the minimum supported NM version.
After a preliminary look at libnickel, I think it's more likely that I'm going to add another button to the bottom nav rather than adding items to the More menu itself. It appears to be safer and easier to hook, plus it'll be easier to use and there's enough empty space for another button (which would even make it look nicer IMO). I haven't looked into the option of replacing the clock yet.
The main disadvantage of both these methods is that I'll actually have to figure out the details of how touch input handling works in nickel.
Note that once I add either menu (clock or new nav tab button), it will be simple enough to add the other one since I'll be able to re-use the menu widget.
I'll also need to look into _ZN20MainWindowController21closeActiveTouchMenus
to ensure it's handled correctly (it isn't critical, but it'd be nice for them to behave like the other menus).
If I end up going with the idea for a new bottom button, I'll need to design an icon for NM (ideas would be helpful here).
Another random thought: I'll be able to reuse most of the menu hook code even with a custom menu.
The first thing I'm going to look into is showing a custom TouchMenu, as I'll be able to test this on older firmware versions and it'll be easier to debug things later if I figure this out first.
The _ZN31N3BrowserSettingsMenuController8loadViewEv
and _ZN19N3BrowserController12settingsMenuEv
functions seem to have the simplest example of its usage.
Relevant symbols:
_ZNK15NickelTouchMenu12autoPositionEP7QWidgetRK5QRecti
_ZN9TouchMenu10setVisibleEb
_ZN15NickelTouchMenuC1EP7QWidget18DecorationPosition
_ZN28AbstractNickelMenuController18createMenuTextItemEP5QMenuRK7QStringbbS4_
_ZN22AbstractMenuController15addWidgetActionEP5QMenuP7QWidgetPKcbbb
_ZN28AbstractNickelMenuControllerC2EP7QWidget
?Qt resources from 15015 (https://github.com/pgaskin/kobo-plugin-experiments/issues/8#issuecomment-640149720):
Note that StatusBarMenu
is a subclass of NickelTouchMenu
which is a subclass of TouchMenu
which is a subclass of QMenu
which is a subclass of QWidget
which is a subclass of QObject
.
The main differences between the styles for StatusBarMenu
and the base NickelTouchMenu
appear to be the thicker border, additional inner padding, custom separators, and larger font. Since we're doing it from scratch for this, I don't think there's a need to replicate the same styling, as there's nothing we need to be consistent with.
Note to self:
QObject::setParent
needs to be called on the menu before showing it, and if so, how it affects object lifetime._ZN22AbstractMenuController14grabTapGestureEP15GestureReceiver
manages touch gestures, as we'll need to reimplement it ourselves._ZN22AbstractMenuController14grabTapGestureEP15GestureReceiver
and _ZN12MenuTextItem22registerForTapGesturesEv
might be interesting.The GestureReceiver
stuff makes the clock idea more complicated, so I may or may not end up doing it for the next version (I certainly want to do it sometime, though). This is partly because GestureDelegate
makes use of virtual functions, and partly because I don't want to hook the creation of every widget just to catch the clock. But, alternatively, I might be able to hook the clock's constructor, then walk up the widget tree to maybe add an entirely new "NickelMenu" button beside it.
The simplest thing to do right now would be to intercept the "More" tab and make it show the custom menu with another "More" button inside it to show the real tab. This adds an additional tap to get to those items, but most of those items can be added to NickelMenu directly anyways (and I can add the ones which can't be right now). I'm currently looking into how feasible it would be to add a new tab button entirely.
Regarding the custom TouchMenu itself, I'm nearly finished. I just need to figure out the simplest and most future-proof way to handle the triggered signal for the action (see 19329daf1acfb19637605f774306b84177542915).
I've figured out a somewhat hacky way to handle the touch events on the menu item without needing a GestureReceiver
for the QWidgetAction
(which contains the MenuTextItem
) itself.
// `it` is the MenuTextItem
// `ac` is the QWidgetAction with `it` as the widget
if (!QWidget::connect(reinterpret_cast<QWidget*>(it), SIGNAL(tapped(bool)), ac, SIGNAL(triggered()))) {
reinterpret_cast<QMenu*>(menu)->deleteLater();
NM_ERR_RET(nullptr, "could not handle touch events for menu item (connection of SIGNAL(tapped(bool)) on MenuTextItem to SIGNAL(triggered()) on QWidgetAction failed)");
}
See 3660bed1343d4282cf0a73a36568ec041993ce86.
Now, I just need to polish that code a bit, figure out positioning, and figure out where I'm going to actually put the trigger for the menu to show.
I have managed to make an ugly and misaligned, but working trigger where the clock is, but I don't think I'll be going with that approach, at least for the next release, as it's a bit buggy and complex.
I'll probably end up going with my idea of intercepting the "More" button and showing NickelMenu along with another button to show the actual "More" menu for now.
I ended up going with the idea to add another item to the bottom tab bar, as it ended up being relatively straightforward and it wasn't too messy.
Here's what it looks like right now:
@shermp, @NiLuJe, @jackiew1, do you think I should make a custom icon for it (if so, I'd appreciate ideas, as I'm not really good with icon design)?
@shermp, @NiLuJe, @jackiew1, do you think I should make a custom icon for it (if so, I'd appreciate ideas, as I'm not really good with icon design)?
It's entirely up to you but with my predictable always-look-on-the-dark-side approach, personally I wouldn't do a special icon for these reasons:
It's got can-of-worms written all over it as far as I can see. But when did that ever deter your more positive outlook. 😃
ETA: Forgot to add that the extra menu in the footer looks fine to me.
If you open Pandora's Box for customising the NM icon don't be surprised if you get requests to allow icon customisation in other parts of the GUI.
Remember that we're running as part of Nickel, so we can just embed our own icon in NM (the Qt resources are registered globally).
Don't you have to provide a different size icon for each of the different Kobo models?
I think these ones are scaled, but I'll check to make sure.
Update: They are pre-scaled and included in nested resource roots which are separate for each device: https://github.com/pgaskin/kobo-plugin-experiments/issues/8#issuecomment-672587633.
As far as I remember nickel's CSS streams are coded to expect fixed icon sizes by model.
This one is slightly different, as it's drawn manually by the MainNavButton
.
It's got can-of-worms written all over it as far as I can see
This one isn't as bad as it seems since we have access to the proper Qt stuff rather than patching the binary directly. The real can-of-worms I was concerned about was my original idea to replace the clock with a menu button, as the code I had for that was quite messy and I didn't feel completely comfortable with its stability or how well it would work on different screen sizes.
ETA: Forgot to add that the extra menu in the footer looks fine to me.
Yes. I'm also starting to get used to that position myself. It helps that it's right against the edge of the screen because that makes it quite easy to press blindly the way I used to with the top-left menu. And, it does make the bottom nav look a lot more balanced.
I wouldn't mind a custom icon, yeah, and I kinda agree about what was proposed (i.e., something along those lines: https://github.com/koreader/koreader/blob/master/resources/icons/appbar.tools.png ).
On Tue, Aug 11, 2020, 18:40 Patrick Gaskin notifications@github.com wrote:
If you open Pandora's Box for customising the NM icon don't be surprised if you get requests to allow icon customisation in other parts of the GUI.
Remember that we're running as part of Nickel, so we can just embed our own icon in NM (the Qt resources are registered globally).
Don't you have to provide a different size icon for each of the different Kobo models?
I think these ones are scaled, but I'll check to make sure.
As far as I remember nickel's CSS streams are coded to expect fixed icon sizes by model.
This one is slightly different, as it's drawn manually by the MainNavButton.
It's got can-of-worms written all over it as far as I can see
This one isn't as bad as it seems since we have access to the proper Qt stuff rather than patching the binary directly. The real can-of-worms I was concerned about was my original idea to replace the clock with a menu button, as the code I had for that was quite messy and I didn't feel completely comfortable with its stability or how well it would work on different screen sizes.
ETA: Forgot to add that the extra menu in the footer looks fine to me.
Yes. I'm also starting to get used to that position myself. It helps that it's right against the edge of the screen because that makes it quite easy to press blindly the way I used to with the top-left menu. And, it does make the bottom nav look a lot more balanced.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pgaskin/NickelMenu/issues/78#issuecomment-672079289, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3KZRNTKBNGCHZDNSIIRLSAFX6FANCNFSM4P2IWAHA .
@pgaskin, could you swap between nickelmenu tab and more tab? the home screen will look more intuitive. when we mean more, it should be the last menu we looking for
MR:post-4021495 MR:thread-332254