[app_server] Deskbar only visible on the current workspace

[diver]

Deskbar only visible on the current workspace in Workspaces.
Also miniature windows (in Workspaces) enlarges if you switch to another workspace.
Tested with hrev32596 in VirtualBpx 3.0.4

[axeld]

Not sure what you are talking about, and please don't mix bug contents.

If you mean that windows like the Deskbar aren't visible before you visited the workspace the first time, that's expected, as the app_server only hands out a position to a window on the first switch (this is the same as in BeOS, btw).

I can't reproduce or simply don't understand the other problem.

[diver]

As you could see from this screenshot, I'm on the 3rd workspace and Deskbar is visible there, but other workspaces only show thin vertical line (see Magnify window). And I'm visited all 4 workspace several times before taking this screenshot.


Sorry for mixing contents, but I thought it was related issues, I'll open another ticket for it.
Is this one still invalid?

[axeld]

The screenshot makes things a lot clearer, thanks!

How do you manage to reproduce this problem? Is there anything specific you're using (like different resolutions per workspace, ...)?

[diver]

Pretty strange, I can't reproduce it with ​http://haiku-files.org/vm/haiku-pre-alpha-r32645-vm.zip in VMware Player 2.5.2. Nothing suspicious, resolutions are the same per workspace. I think I could share my image if you need it. Here is my UserBuildConfig just in case.

[diver]

setting from ~/config/settings/system/app_server

[diver]

To reproduce:
place workspaces to ~/config/settings/system/app_server
Drop Workspaces replicant to desktop and reboot

[diver]

Still here as of hrev35833.

[diver]

Still reproducible in hrev38300 using method from comment:5

[pulkomandy]

(In #13015) Yes, but:

(the two far right one are of different resolution btw):

But right, seems to be a duplicate of #4306.

[AlienSoldier]

I missed that one, yes it seem mine was a duplicate. After reading this one i made more tests: Changing color of the problematics workspace did nothing I never changed my color space (16 bit) never changed refresh rate (60hz ). Note that this is a very slow PCI chipset used in very high res (so it might have a big latency when doing operation change) Then i changed the resolution from a low res workspace to the others 1080 res. This did not solved anything. I then made them all lower rez (800 x 600 perhaps), all where fine. Upped them to 1080 all again, still all fine. I played with putting one to lower rez again and noticed that the problem came back (i may have made a revert before a final apply).

I can't start the problem at will but i can get out of it at will now. It seem timming related as it is intermitent, but it persist a reboot until i do my resolution change trick. I assume the problem is easier to duplicate in a slow chipset, VM or heavy cpu load condition. Almost look like an internal list don't get populated fast enough or something and so it get corrupted.

Even if i no longer have the problem, the bug is still there. As a side note the screen pref seemed to be a pain to work with when the bug was present (it seem fine now) i was having a lot of trouble to de ghost the "apply" button. So even if the screen was different, it look was it was reading the same value as for other workspace. I was not able to test enough of this as so far i was not able to reproduce the problem.

I used to have a situation where i was KDL ling on a move to a certain low res workspace at random. I will stress test that situation a bit in the comming days to see if i can recreate that and see if it was related to this ticket.

[pulkomandy]

I think you can use the screenmode command to get the current screen mode. What does it say in these cases?

[AlienSoldier]

I will have to recreate the problem first before i can try this. I will when it happen again.

[axeld]

Ticket #12139 contains a better description of the actual problem that this bug describes.