Hide/Unhide android navigation bar (suitable for games)
You can hide navigation bar in dalvik for playing android games for exampple...
By pressing on the icon it will hide/unhide navigation bar.
Thanks to Ancelad for idea :)
Requires:
aliendalvik >= 0.17.35-1 - should be installed.
aliendalvik-control >= 1.0.10-1
python, dbus-python - to see notifications on the event screen.
lipstick-qt5-tools - to overwrite existing notification instead to collect them in the thread
v0.1-4
- Some changes in scripts.
- Removed notifications from notification screen.
v0.1-3
* Thanks to Coderus for Aliendalvik Control. Restart of dalvik not needed anymore.
Beware, use it on your own risk !!!
Donation are welcome :)
Screenshots:
Category:
Keywords:
Application versions:
| Attachment | Size | Date |
|---|---|---|
 dalvikbackicon-0.1-2.armv7hl.rpm | 15.26 KB | 25/01/2016 - 01:12 |
| dalvikbackicon-0.1-3.armv7hl.rpm | 15.32 KB | 27/01/2016 - 01:09 |
| dalvikbackicon-0.1-4.armv7hl.rpm | 15.71 KB | 29/12/2016 - 00:07 |
Changelog:
- Some changes in scripts.
- Removed notifications from notification screen.
Comments
olf
Thu, 2017/10/19 - 00:08
Permalink
Bug report:
After a reboot the "Android navigation bar / back button" is always present in the GUI, but Dalvik bar retains its last state over reboots.
Thus Dalvik bar and the actual GUI settings are always out of sync after a reboot, if Dalvik bar's state was "hidden" before the reboot: Then Dalvik bar is still red and shows "hidden", although the Android navigation bar *is* displayed.
Workaround:
Toggle the Dalvik bar twice: Once to get it in sync with reality, the second time to actually switch the Android navigation bar off.
Unfortunately that takes some time, so one has to be patient.
Suggestion for a solution #1:
Obviously Dalvik bar already remembers its state over a reboot. Detect this situation and then apply saved state again.
Note: I have not tested in which other situations (e.g. AlienDalvik restart, Lipstick restart) Dalvik bar' state becomes out of sync with the GUI. Hopefully there is a single signal, which Dalvik bar would have to listen to.
Suggestion for a solution #2:
If #1 is not feasible, maybe reading the real GUI state is, so Dalvik bar can adjust its own state, either when detecting a special situation or by polling (the latter is not nice under many aspects).
Suggestion for a solution #3:
Oh, simpler than #2, but yielding the same result: When detecting a "special situation", set Dalvik bar's state to "not hidden", as that keeps it in sync with reality. An optimization may be though to check if Dalvik bar's state already is "not hidden", first.
Note: This issue would be alleviated (i.e. less significant), if Dalvik bar performs quicker. If easy and simple performance optimizations exist ("low hanging fruits"), please consider implementing them, regardless if this issue can be solved.
Kudos for this extremely useful little tool.
olf
Mon, 2017/01/09 - 00:26
Permalink
An unrelated, rather political suggestion: Delete the "(suitable for games)" throughout this webpage, as this makes Dalvik bar less attractive and is a relict from the times, when "live toggling" (via AlienDalvik control) was not possible, if I understand the history of Dalvik bar correctly.
I actually love to use the extra space on the small and rather low-res screen of the Jolla 1 with K9-Mail, OSMand~ and other (mostly non-gaming) Android software.
Schturman
Wed, 2016/12/28 - 02:50
Permalink
Hi. Sorry, I didn't touched this package since I released it here... I think it better to remove it at all and use AlienDalvik control app from Coderus that have hide/show for navbar.
olf
Mon, 2017/01/09 - 00:20
Permalink
Hi Schturman,
oh, please do not underestimate the usefulness of Dalvik bar:
While many Android apps nowadays do not need the Android return button, some of them do not consistently (i.e. in some dialogues the button is still needed), and some older apps just rely on the button.
So toggling the Android bars's state has to be easily accessible, as that is needed regularly, and putting Dalvik bar in the first (i.e. topmost) row of application icons on the desktop provides easy access very well. In contrast to that, AlienDalvik control's "hide" and "show" buttons are buried in the settings and putting AlienDalvik control in the eventview quick access menu does not really provide a quicker access. But "yes", AlienDalvik control does not have this issue, because it offers separate buttons for hiding and showing the bar, while Dalvik bar toggles the bar's state (actually having a single toggling button is part of its beauty and ease of use).
Anyway, as this issue is just an inconvenience, and Dalvik bar is fully functional, don't mind too much. It is just a minor bug report, and I intentionally provided the workarounds in case this issue is not fixed soon or not at all.
As I appreciate your work very much and your consistent output (of software for SFOS) is surprisingly high, I can understand well, if you prefer to focus on other things. (BTW, IMO setting priorities is no reason to really feel sorry about the things prioritized low: You have proper reasons to do so. :) )
Cheers, Olf
Schturman
Fri, 2017/01/06 - 18:03
Permalink
Olf, please try new version and tell me if this ok. On my Jolla C it work quickly.
P.S. And here is another version without icon changer: https://dl.dropboxusercontent.com/u/17706605/Jolla_C/dalvikbackicon-0.1-...
P.S2. Did you know that you have Toggle android navbar from Aliendalvik-control? (Setting-Events view-Select shortcut) And it work very good...
olf
Wed, 2017/11/22 - 02:20
Permalink
I finally understood your P.S2. completely (a couple of weeks ago):
Yes, Settings --> Events view --> Setting shortcuts --> Select shortcuts --> Toggle android navbar is working nicely, it is just one swipe further away.
Sorry for taking so long to capture this; still, I like the look & feel of your "AlienDalvik bar" better, but never mind.
olf
Sat, 2019/04/06 - 01:56
Permalink
BTW (for other readers), the "Toggle android navbar" entry for the Eventsview shortcuts (SFOS 2) / the TopMenu shortcuts (SFOS 3) is part of coderus' AlienDalvik Control RPM.
olf
Mon, 2017/01/09 - 00:23
Permalink
Sorry for the delayed answer.
a. Disabling the notifications was a good idea, IMO.
b. Well, for the changes in the scripts, I see mixed results on my Jolla 1:
b1. Speed: Dalvik bar is slightly faster in actually toggling the visibility of the Android back button bar, but noticeably slower until it closes after that. So the turn around time for starting Dalvik bar twice rather increased than decreased, so I perceive this as a slight regression.
b2. New bug: Since the update to Dalvik bar 0.1-4 it sometimes fails to display its icon, but the text "Unhide icon" is still displayed. I have not yet understood what triggers this, but it happens regularly.
So all in all, reverting the changes in the scripts (unless there is an obvious bug), but leaving the notifications disabled, would be the easiest improvement. Looking at the number of (although all five star!) votes, I really think this nice little utilities is unfortunately not worth investing too much time optimising it.
Thanks again for all your cool SFOS software.
P.S.: I have downloaded but not yet tried the "version without an icon changer". Is the idea to reduce Dalvik bar's toggling time by not changing the icon? But then one has to look up its state by looking at the actual Android back button bar, right?
P.S.#2: Yes, I know and I have it there already. But it requires significantly more swipes and ticks to trigger the toggle; this and the fact that toggling the Android bar's visibility has become a regular operation for me, is why I love Dalvik bar so much. :)
Schturman
Fri, 2017/01/06 - 18:04
Permalink
Try version 0.1-6 - completely without notification, only switch: https://dl.dropboxusercontent.com/u/17706605/Jolla_C/dalvikbackicon-0.1-...
olf
Mon, 2017/01/09 - 01:41
Permalink
Emil, thanks for the new versions (and sorry again for my delayed testing and replies; unfortunately time will continue to be scarce for me the next couple of weeks):
- v0.1-5
Good:
a. No notification entries in eventsview.
b. Transient notifications still there in the upper left corner of the screen, informing about the freshly set state of the Android bar.
I just realized, that these always state the truth, i.e. after a reboot, when the bar was hidden before (and is now has become visible), starting Dalvik-bar results in the notification "Dalvik bar visible", which is correct (although just setting the already set state, again).
Not so good, IMO:
Dalvik bar's icon does not display the current state of the Android bar anymore. Well, that was obviously the purpose of this version, but knowing what the state of the bar is, before starting an Android app, was a nice part of Dalvik bar's functionality.
Speed:
To my perception the switching speed (until the actual toggle and notification occurs) is the same or a bit faster, but the time until Dalvik bar closes is the same or even longer than with v0.1-4.
Notes:
Well, without icon changes Dalvik bar's "no icon, but text"-state cannot occur anymore, the same is true for the displaying out-of-sync icon state after a reboots (while the internal state still is out of sync, AFAICT, but that is definitely O.K., as impossible or way too complicated to solve).
Ah, so these were the improvements you were aiming at with this version, but it comes with aforementioned drawback of not being able to see Dalvik bar's state when in sync with reality (i.e.: always, except after a reboot). Mmh, all in all I don't really think this constitutes an improvement, it just hides the out-of-sync issue. I personally prefer seeing what's going on, even if something goes slightly wrong. As the underlying "internal state is out-of-sync"-issue is not solvable, a v0.1-3 without notification entries in eventsview (or fixed v0.1-4, see notes below) suits my needs better than v0.1-5.
- v0.1-6
Bad: With no notifications at all, one has to have the impression Dalvik bar does nothing (i.e. is not functional) when started once in an out-of-sync situation (i.e. after a reboot with the bar hidden before the reboot).
So IMO v0.1-6 is definitely a regression compared to v0.1-5.
- So I tested v0.1-4 again, specifically the "no icon"-bug:
Steps to reproduce:
1. Create an out-of-sync situation:
Set Dalvik bar to "hidden", then reboot or restart AlienDalvik.
Now the Dalvik bar icon is red and it displays "Unhide icon", although the actual Android bar is visible.
2. Start Dalvik bar once. Transient on-screen notification displays "Navigation bar is: VISIBLE", which is correct.
Now the icon becomes transparent (or black; on a black background that is impossible to distinguish), and the displayed icon text remains "Unhide icon" (which is still incorrect and out-of-sync).
Expected behaviour: Icon becomes green and its text "Hide icon", as this ought to be the toggled Dalvik bar's internal state after its first run in an out-of-sync situation (after a reboot / AlienDalvik restart). Dalvik bar v0.1-3 did just this, i.e. handled an out-of-sync situation better than v0.1-4.
So I still believe it is best to revert to a v0.1-3 without notification entries in eventsview (or to a v0.1-4 with the "no icon"-issue fixed).
Thanks for spending so much time and thoughts on Dalvik bar, though I like to still suggest releasing a "final" version and then defining Dalvik bar being in "maintenance mode" (i.e. receiving just bug fixes and adaptions to new SFOS releases) as the easiest and most effective way to proceed.
Side note: IMO the icon texts "Unhide bar" / "Hide bar" would fit better than "Unhide icon" / "Hide icon".
olf
Mon, 2017/01/09 - 04:29
Permalink
Side note #2: One more thought on "finalising Dalvik bar".
I always wondered, why Dalvik bar's icon is *red* in hidden state, as red usually indicates an error, "Stop", an abort, "do not do that" etc., but here it is merely a notification / reminder that the Android back button bar is not visible.
So my suggestion is to change the red gradient of the "hidden state"-icon to something sufficiently different from the green gradient of the "visibile state"-icon, e.g. a light blue gradient (blue is often used for notifications; maybe some base colour similar to the SFOS browser or Cargo Dock icon colours), or if you really intend to denote a *warning* (which is not needed here, IMO) to a yellow one (e.g. base colour something between MeeCast's and Tiny Edit's icon colours).
And if you want to clearly indicate that the Android back button bar is currently not visible, you may dash out the "back button"-symbol within Dalvik bar's "hidden state"-icon (the one with text "Unhide bar") with a thin, black or red "/" (i.e. a thin, black or red diagonal line from the lower left corner of the "back button"-symbol to its upper right corner), or a "ghost busters"- / "no parking sign"-style circle around the "back button"-symbol (but there is very little space for that) plus such a diagonal dash (both also either in black or red). Actually I imagine a black dash (and maybe circle) looking better.
Cheers, Olf
Schturman
Tue, 2017/01/24 - 13:13
Permalink
Hi. Sorry for delay. I don't have too much time for the next 2-3 weeks. Will try to do something after this.
Schturman
Wed, 2016/12/28 - 21:02
Permalink
Hi. Ok, if you think it still useful, I will check what I can do :)
Emil
caprico
Mon, 2016/01/25 - 21:31
Permalink
Thank you. Neat way to hide the android bar :-) Since most modern Android apps support a back-swipe, the return button isn't needed in most cases.
Rikudou_Sennin
Mon, 2016/01/25 - 10:29
Permalink
Works great, thanks :)
alina
Mon, 2016/01/25 - 01:30
Permalink
Where to install lipstick-qt5-tools? I'm getting the "requirement cannot be provided" error.
alina
Mon, 2016/01/25 - 15:52
Permalink
Thanks coderus, it worked.
This is great, but it will be perfect if it's possible to shift text fields up to become visible in portrait. Due to navbar removal, they hide under the Jolla keyboard.
olf
Wed, 2016/12/28 - 01:24
Permalink
My workarounds are:
1. Tap on a non-text area of the foreground program (i.e. Android app).
2. Swipe the virtual keyboard away (i.e. down), but this always has been tricky to use and is quite error prone (i.e. triggering other, unintended actions).
itdoesntmatt
Mon, 2016/01/25 - 21:17
Permalink
maybe is possible to make not transparent the prediction bar? i think it could work.
However i am using An android app called Hide system bar, wich make a similar think without restarting dalvik and in addition let possibility to let bar appear when tapping the very bottom part of screen. Otherwhise with normal mode (not superuser mode) it pushes a button to hide/show the nav bar in every android screen.
olf
Wed, 2016/12/28 - 01:51
Permalink
Mmmh, have you taken a look at the permissions it demands (looking at "Hide System Bar (Full Screen) v2.0.4" in Aptoide's "jolla" store): A bit more than just "calling home", AFAICS. It seems to be a quite capable utility, though.
Schturman
Mon, 2016/01/25 - 16:22
Permalink
Yes, I know... Don't know how to do this if it possible... This is a reason that I mentioned "suitable for games"...
coderus
Mon, 2016/01/25 - 04:35
Permalink
pkcon refresh?