Taskbar does not run properly on Android-x86

[ib]

On Android-x86 9.0-r2 taskbar cannot open its settings dialog. It seems to crash: "Taskbar keeps stopping".

Furthermore, the title bar buttons of freeform windows don't work. The left button does nothing (no idea what it's supposed to do), the middle one seems to minimize the app (if that's its purpose) and the right one (fullscreen?) renders the background black, but the window remains unchanged.

[utzcoz]

@ib there are some improvements(including problems you mentioned) after Android-x86 9.0 r2, but it doesn't been released with Android-x86 9.0 r3. If you want it, you can show your need for Android-x86 9.0 r3 at Android-x86 Google groups.

If Taskbar crashes on Android-x86 9.0 r2, it's better if you could provide stack-trace of crashing.

[ib]

there are some improvements(including problems you mentioned) after Android-x86 9.0 r2, but it doesn't been released with Android-x86 9.0 r3

I have compiled the pie-x86 branch of Android-x86 myself now. (Wow, that took a while!)

Taskbar is now version 6.1.1 and behaves much better. The settings dialog can be opened and the fullscreen title bar button works too.

However, although you can configure windows to open "large", it does not have any effect. Instead, Taskbar remembers the position and size changed by the user for each window, even if that is not configured. A bug?

The left and center title bar buttons still leave me stumped. While the middle one does something like minimizing, the left one does nothing. (Is there no description of the buttons anywhere?)

[utzcoz]

I have compiled the pie-x86 branch of Android-x86 myself now. (Wow, that took a while!) Taskbar is now version 6.1.1 and behaves much better. The settings dialog can be opened and the fullscreen title bar button works too.

Cool. I know building Android-x86 is difficult for many guys. Congratulations.

However, although you can configure windows to open "large", it does not have any effect. Instead, Taskbar remembers the position and size changed by the user for each window, even if that is not configured. A bug?

It's not a bug. It's a feature. I have patched frameworks/base to persist window bounds.

The left and center title bar buttons still leave me stumped. While the middle one does something like minimizing, the left one does nothing. (Is there no description of the buttons anywhere?)

Could you provide a screenshot for title bar? I can explain functions of those buttons. Some are added by me, and some are added by @electrikjesus.

[ib]

It's not a bug. It's a feature. I have patched frameworks/base to persist window bounds.

In this case, the settings for the default window size on opening (as the setting to always save window sizes) don't make sense anymore, do they?

Could you please point me to the commit? I'm just curious.

It seems that Android-x86's packages-apps-Taskbar is pretty far behind this master repository. Would it make sense to pull the missing commits before I build Android-x86?

Could you provide a screenshot for title bar? I can explain functions of those buttons.

Here you are.

[utzcoz]

Could you please point me to the commit? I'm just curious.

The change of ActivityLaunchParamsModifier in https://osdn.net/projects/android-x86/scm/git/frameworks-base/commits/f3b4e6b21d6372c2118cf7f200469c897b296929.

It seems that Android-x86's packages-apps-Taskbar is pretty far behind this master repository. Would it make sense to pull the missing commits before I build Android-x86?

I don't know whether Taskbar can built with hidden API helper library added recently. But you can try, or use older version before adding hidden API helper library.

Here you are.

The four buttons are for: pip, minimize, maximize(fullscreen) and close. See https://osdn.net/projects/android-x86/scm/git/frameworks-base/blobs/pie-x86/core/res/res/layout/decor_caption.xml.

[ib]

I don't know whether Taskbar can built with hidden API helper library added recently.

It could not. (Your recent patch only came after I had tried.) Instead, I patched Android-x86 to not include Taskbar, which allows installing the most recent version now.

The four buttons are for: pip, minimize, maximize(fullscreen) and close.

Thank you for the explanation.

However, I don't notice any difference between the minimize button and the close button. The close button does not close (quit) the application, but sends it to the background. The same seems to happen when minimizing, doesn't it?

Maybe I am going to remove all the header buttons except for minimizing and maximizing and see how that goes.

There are a few Taskbar features that I would like to be improved:

• The start menu grid is tiny. It would be useful if its size (rows / columns) could be configured.

• I don't like the windows flying in and out on launch and close. (I was able to stop that with a developer option, but maybe a Taskbar option would be useful.)

• If possible, the close button should actually close the application (like the close button in overview mode).

• If possible, the recent apps should be exactly those that are still running in the background.

[utzcoz]

However, I don't notice any difference between the minimize button and the close button. The close button does not close (quit) the application, but sends it to the background. The same seems to happen when minimizing, doesn't it?

Close button will close app, and it will quit. Minimize button just moves app to back.

Maybe I am going to remove all the header buttons except for minimizing and maximizing and see how that goes.

The logic is simple, and you can read code to investigate the behavior of captionbar buttons.

The start menu grid is tiny. It would be useful if its size (rows / columns) could be configured.

Does not Taskbar have this function? It's a good feature. I think you can file a new issue for it if there is no other existing issue for it. Maybe cc @farmerbb for this feature request.

I don't like the windows flying in and out on launch and close. (I was able to stop that with a developer option, but maybe a Taskbar option would be useful.)

In higher Android version, Launcher can use system callback to control app opening/closing animations. The Launcher3 is an example. But I don't know whether it's open for normal app, instead of system app. Anyway, we can use gradle to build Launcher3, and maybe we can use hidden API stub mechanism to enable those APIs if they are hidden APIs, although I don't think it is a good idea for normal Launcher app. If you want to build Taskbar with system app, maybe you can investigate it. :)

If possible, the close button should actually close the application (like the close button in overview mode).

I think this button works for it. But it will not remove cache/history from system, and it's the reason you can see it on overview window/recents. You can use adb shell ps -A to check its' process state after clicking close button(it should work for normal app without hack process restarting mechanism).

If possible, the recent apps should be exactly those that are still running in the background.

I don't know what you mean this statement. Could you explain it more?

[utzcoz]

It could not. (Your recent patch only came after I had tried.) Instead, I patched Android-x86 to not include Taskbar, which allows installing the most recent version now.

Maybe you can try again. I have tested it for Android-x86 pie.

[ib]

If possible, the close button should actually close the application (like the close button in overview mode).

I think this button works for it. But it will not remove cache/history from system, and it's the reason you can see it on overview window/recents.

I see. Well, the feature request would be to clean up cache/history then.

If possible, the recent apps should be exactly those that are still running in the background.

I don't know what you mean this statement. Could you explain it more?

The recent apps to display shouldn't be any apps I've used, but those apps that are currently still active in the background (i.e. not closed, not quit).

There is code for it (showRunningAppsOnly()), but Taskbar seems to have to be system app for this (don't know if this is a technical requirement). Currently (with my approach) it's easy to deinstall or update Taskbar.

[utzcoz]

I see. Well, the feature request would be to clean up cache/history then.

I think we should keep this behavior. The cache of snapshot can help to improve cold-starting experience.

The recent apps to display shouldn't be any apps I've used, but those apps that are currently still active in the background (i.e. not closed, not quit).

The same as above.

[ib]

I don't know whether Taskbar can built with hidden API helper library added recently.

Maybe you can try again.

I did. It works like a charm now. Thank you very much for the patch.

Building as a system app has the advantage that I can now choose only the running apps as "recent apps". The disadvantage is that updating Taskbar requires recompiling it and updating Android-x86.

Not an easy decision.

[ib]

If possible, the close button should actually close the application (like the close button in overview mode).

I think this button works for it.

It doesn't seem to do that.

You can use adb shell ps -A to check its' process state after clicking close button

I did. The process remains existent until using the close button in the overview mode.

[phicha20224]

I dont know how to build. please help share iso for r3, since i do have same problem with taskbar button ( maximize and minimize )

Thank You

[ib]

@phicha20224 Which build do you mean? Both of them (Android-x86 and Taskbar) are not so easy to explain.