Most recent activity
-
The duplicated thread with better pics (smaller size) has been the removed one.
Anyway it was a false alarm, but that's true that i expected the same size and horizontal/vertical centered independently of length of the string.
On the other hand, what is the expect app to display in bangle.js for a debug notification?
Currently it shows "Bangle.js gadgetbridge" or the fake app selected from the debug dropdown list, a even i would propose a 3rd option "Debug: %app%" so "Debug: Whatsapp"But also it is not a real life problem, so it is just a curiosity :D
-
Yes, this is a known issue. Mozilla refuse to implement Web Bluetooth
in their browser.Sad but true
*Status:
RESOLVED WONTFIX*https://bugzilla.mozilla.org/show_bug.cgi?id=674737
Mozilla's Position:.... Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
-
I don't know if there is a reason to display notification from GB Debug in a different way than those from real apps.
At the moment when notifications come from Debug:- font size is always the same (big) independently of the number of lines
- header is shown different
- text can go out of the content area and overlay widget areas
See the photos with multi line messages
photo1. a test from Debug
photo2. a real notification (it is not recent, so maybe the text distribution has been improved) - font size is always the same (big) independently of the number of lines
-
I deliberately avoided feedback in the app loader
I agree with a separating feedback from the installing function, but maybe having a link to the github filtered result.
By "feedback" i was referring more to personal opinions or functional analysis, focused more in end-users than in issues/technical feedback as bugs or feature demands focused on developers.
In fact i just realized that my example (reviews page of firefox addon) lacks of a version number field (btw google play reviews lacks of it too), and imo it is must to have info.
Through fields and filters I am sure that Github can manage this review info :)
-
so maybe after that one is gone completely?
I think keeping support for old models like bangle.js1 is not bad at all for the project neither for users of new models. As it forces to apply better coding practises, help detecting the lack of abstraction between the code and the hardware.
It would be amazing having the official espruino and most apps working in some of the watches that jeffmer made to work with its espruino fork.Yes, the different display sizes are a challenge, but I am sure there is a solution for it :)
-
Using Favorite is good way to avoid risks or a trial&error installing process with its associated time consuming.
I missed the "favorite" filter when I was new with bangle.js. Now I find interesting the "New" filter and give a chance to new apps.
To be even more perfect I just miss a page for feedback (considering privacy), so users can give opinion and even tips. (inspiration from Firefox addons page)
-
I see that this OWM weather is not defined as compatible with bangle.js 1. Isn't it? or it just has not been tested
-
Not the answer to you question but
I managed to have weather working on the "advanced casio clock" with the API key of openweathermap.org and syncing from its own web app.The syncing method is not ideal, but it can be re-coded ;)
-
Thanks to this question I've realized that espruino has a fork of "gadgetbridge" with additional functions. ;)
learning