More default customization to E.showMenu?

[RKBoss6]

I've recently been designing an integrated workout app, and thought it would be nice to have taller menu items in the default E.showMenu, to help make this app and others feel more integrated with its design. However, we don't support that out-of-the-box. I could just make a showMenu override in the app itself, but that would increase loading times, processing demand, and file size, which is not ideal at all. I propose an addition to the options in showMessage, where

"" : { title : "-- Main Menu --", itemHeight:30}, // options

@gfwilliams I know we've seen eye-to-eye over this kind of proposition in the past, and I get that it's a hassle to maintain the changes, but I would really love to see this, as it's not just a matter of who uses it, its setting a new way to use and customize the bangle.js. All ui languages support this, even ones running on small SOCs.

As for the uses, choosing on a software functionality with the end number of uses in mind should definitely be considered. However, it's a gradual change of more users, depending on how many read the documentation and are aware of the change; it's not a number set in stone like 1-10 uses, and will definitely increase as more and more developers find out about it, just like any other firmware-level feature.

I love the Bangle.js because of the capability to modify everything you could ever want, but on a chip with small space, designing through firmware would help immensely, rather than cramming a E.showMenu override into a single app's file.

Thanks,
RKBoss6

[thyttan]

I have contemplated the opposite. I.e. reversing the long press button options we did in 'showPrompt' and reimplementing it just in the alarms where we use it for the snooze stuff 🙃 In order to lessen the maintenance burden for Gordon.

[thyttan]

I could just make a showMenu override in the app itself

That's how you should do it initially I think. If we try it and like it maybe it works its way into firmware in the future? or not 😛 but at least then it's been evaluated before we do firmware changes.

[gfwilliams]

Thanks for checking over before doing a PR!

Looking at the code, it feels like this isn't a big or problematic change, but I guess I don't really see what it'd look like since you're not actually changing what's being displayed in each menu item or how? Could you post a screenshot of what you envision and what it's meant to match with?

Since we're thinking much more seriously about a new Bangle (where the menu heights will almost certainly change to match the new screen) it feels like allowing someone to specify heights at this point is just going to be a source of pain. While I have plans to allow Bangle.js 2 apps to be compatible, something like this will probably make the experience for users worse than if it was just left alone.

to help make this app and others feel more integrated with its design

It's tricky, because by allowing you to change the height of menus for each different app, you're surely going to make everything feel less integrated if every different app has its own mish-mash of different menu heights?

[RKBoss6]

In my mind, there's something slightly wrong about all apps looking the same. To me, I feel like each app should be unique, so not only can you tell what app is open just by looks, it stands out from everything else. Perhaps could we have a scale factor instead of height? This way, default heights for each device will be scaled for consistency, and will still get the customized menus...

[gfwilliams]

there's something slightly wrong about all apps looking the same

I'm not sure I agree with this - and to me it goes against what you've been complaining about to date, which was that Bangle.js doesn't always feel like one coherent bit of software. If we allow different font scales and menu sizes in different apps it's going to be even worse.

You'd asked about making the colour schemes different for different apps, and we talked about how to manage that using Themes and how it works pretty well already - and I can see how that would make sense. But I feel like changing the defaault menus is a step too far.

Of course you can implement your own menus for the app - and maybe, given you've wanted separators and other things, that's a better way forward in your case if you really want it - but I'd advise strongly against it if you want people to have an easy time using your software.