Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wid_edit: Widget Editor #1303

Merged
merged 8 commits into from Jan 18, 2022
Merged

wid_edit: Widget Editor #1303

merged 8 commits into from Jan 18, 2022

Conversation

rigrig
Copy link
Contributor

@rigrig rigrig commented Jan 15, 2022

Widget Editor, so we don't need to edit code to move our widgets around.

Every feature seems like a good idea while happily coding away, but "disabling" widgets is tricky. I think it works fine with most widgets, but they are still loaded.
And apps that try to call WIDGETS[<myappid>].someCustomFunction() probably break.
Maybe better to strip this out, and if people want to get rid of a widget we adjust that app? (Maybe someday we can come up with a standard setting for this, so apps don't all need to build their own "show widget?" setting)

Also, maybe we should "officially" get rid of bottom widgets? Bangle.appRect doesn't looks like it supports it for one...
The only bottom widget is wdclkbttm, I haven't tried that particular one, but it seems Things (like menus) Break with bottom widgets.

With all the "disabled"/bottom row breakage, I figured this should be a separate app.
But if we strip out disabling, and only allow choosing between "top left"/"top right", maybe this could go directly into the settings app?

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Jan 17, 2022

Thanks! So...

Also, maybe we should "officially" get rid of bottom widgets?

I think so, yes... I mean with appRect we could kind of support them in apps (and I should add that to the firmware), but I'm not sure anyone really seems to care about them.

but "disabling" widgets is tricky.

I think for disabling we should just ask the user to uninstall. But maybe you could switch to hiding? This seems quite successful and is already used a few places:

wd.draw=()=>{};
wd.area="";

@rigrig rigrig marked this pull request as draft Jan 17, 2022
@rigrig
Copy link
Contributor Author

@rigrig rigrig commented Jan 17, 2022

I think for disabling we should just ask the user to uninstall. But maybe you could switch to hiding?

It tries to hide them now, and could probably try a bit harder (and properly label it "hide" instead of "disable"), but "just ask the user to uninstall" seems like the better way. Also because otherwise you end up with a whole bunch of widget code loaded for no good reason, and it would mean much cleaner code for this app.
Same goes for only supporting top-row widgets: that way the boot code doesn't need to mess with appRect.

I'll update it to just support tl/tr and sortorder.

@rigrig rigrig force-pushed the widget-editor branch 3 times, most recently from 0cd2503 to 3468e12 Compare Jan 17, 2022
@rigrig rigrig marked this pull request as ready for review Jan 17, 2022
@rigrig
Copy link
Contributor Author

@rigrig rigrig commented Jan 17, 2022

Updated to just support tl/tr and sortorder.
Also removed "bottom bar" references from the general README.

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Jan 18, 2022

Thanks!

@gfwilliams gfwilliams merged commit 115230e into espruino:master Jan 18, 2022
@rigrig rigrig deleted the widget-editor branch Jan 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants