I’ve developed two different full-screen GUI applications for the Raspberry Pi in the last year. Both applications seem to exhibit the same issue. When I poke the touch-screen near the top of the screen, instead of my application catching the mouse down event it falls through to the underlying Raspbian task bar. The task bar then pops to the top of the Z order and appears over my full-screen app.
In the video below, at 2:39 you can see an example of what is happening:
I haven’t been able to figure out why this happens. This is a big problem for me as both of my applications are touch-screen kiosk style apps that restrict the user to interacting only with my application. Once the task bar appears, the user can pretty much do anything they want with the system.
Since one of my applications is destined for use by the public, someone will surely find this back-door and take the opportunity to damage my kiosk. This is a serious problem for Xojo/Raspberry Pi kiosk applications.
I wrote a full screen touch-based Raspberry Pi application using XOJO. The wasn’t an easy way, for me at least, to deal with the task bar. What I ultimately did was remove all of the elements on the task bar (e.g. the time, network status, quick launch stuff) and after all that I reduced the tasked bar to a minuscule square in the bottom right of the screen. There no really touches anyways and it was so small that it was impossible to have the problem happen.
After booting up my system I played with it more and I was able to reduce it to 1 pixel and that made it invisible even when it was accidentally brought up. That may help as well. Of course, all of this depends on if you want the task bar to actually go away or if you need it for diagnostics or support work. Good news is that you can bring most/all of those things you remove just by right-clicking on the little bit that’s left and undoing all of the changes.
So you’re seeing the same behavior as is shown in my video? I’m always glad to find out that I’m not the only one seeing something weird.
Unfortunately, I tried the Raspbian option to automatically hide the task bar but that really didn’t provide a fool-proof solution and I would prefer to have the task bar available when a technician closes my app.
I wonder if this is something that Xojo can fix or if it is a problem with the underlying Raspbian desktop?
If the task bar is required then I would suggest minimizing its size so that the hit point is as small as can be.
The problem may be something that the XOJO developers can look at but given other Raspberry Pi and Linux oddities that may be GTK3 related they may not be able to do anything.
I dont remember doing it, but have you tried an older build before GTK3? Or if you are using the older, have you tried the newer? The move between GTK2 and 3 changed a few things for me when it came to the touch screen aspect.
[quote=376323:@Jukka Leino]What if You don’t start taskbar at all?
From:
~/.config/lxsession/LXDE-pi/autostart
comment out lxpanel line.
Jukka[/quote]
Jukka,
That is a really cool trick!
I need to have the task bar available for use by technicians who will be performing configuration and maintenance on my kiosk systems so I can’t remove the task bar. But I am certainly going to make note of what you just shared!
There’s a lot of useful information in the link you provided.
In my case since I’m running a kiosk with only a touch-screen (no keyboard or mouse) and a Xojo application as the interface (no web browser) most of the info doesn’t apply to my particular case. But I appreciate you sharing that page as it brings up a lot of issues that need to be considered if/when I ever do a web kiosk w/keyboard and mouse input.
Hi Wes - did you get all the solutions you needed in this thread? I’m starting a new kiosk-like (stand alone machine-control HMI) project this month, and had (solved) many issues, so I’m clicking around the forum for unanswered threads, trying to contribute where I can. Let me know if you are still stuck on anything in this one - I’d love to try to help.
I haven’t found any solution to this problem. Have you experienced it too? I provided the video because it is easier to show the problem than it is to describe it.
It’s very odd that when I click a Xojo button near the top of the screen, the desktop taskbar is summoned and appears over my application. Very odd indeed.
I have seen the EXACT issue. It only happens ‘once’, and is related to touching a control nearest the top of the UI. After it appears once my users touch anywhere else in full-screen (xojo) app and it dismisses it. But, it happens 100% of the time after rebooting the system.
I’m going to try the suggestion Jukka posted, and build a backdoor for restarting the task-bar if required (like you said, for service personnel etc).
I’ll give it a shot tomorrow when I’m back in the office.
One other irritation I have is getting rid of the mouse cursor. I’m sure there’s a thread on that somewhere if I go digging…
Yes! That’s exactly what I’ve seen. It only happens once. But even if the desktop taskbar only appears once that’s all it takes to let a user get past your full screen application and access the underlying OS. This is unacceptable for a locked-down dedicated system.
I’ve been able to hide the mouse cursor via:
Self.MouseCursor = System.Cursors.InvisibleCursor
And show it again with:
Self.MouseCursor = System.Cursors.StandardPointer
The only odd thing about hiding the mouse cursor seems to be that it doesn’t actually disappear until you tap the screen or move the mouse pointer. Then it finally disappears.
FYI: Since you are having the same magically appearing taskbar problem as me, here’s how my main window is configured:
Width: 800,
Height: 480,
Type: Plain Box,
Close Button: Off,
Resizable: Off,
Maximize Button: Off,
Minimize Button: On,
Full Screen Button: Off,
Implicit Instance: Off,
Placement: Default,
Visible: Off,
Live Resize: On,
Menu Bar: None
When I began my full-screen application project, I tried all the window types to familiarize myself with the characteristics of each and the above settings seemed to me to be the best choice for a full-screen application.
Wes - I’m totally going to respond to you. I’ve spent the last two hours on trial-error with lxpanel, and have to get back to it after a meeting. My goal is to not load it at startup, but then use Shell CMD (via xojo UI) to get it running for when it’s needed. Back to this and other topics shortly…
John: The Unclutter app does do a good job of hiding the cursor/mouse.
Wes: I’m very close to finalizing some demo code for reinstating the TaskBar, should have some irresponsible code to share shortly!
I used the following to prevent the TaskBar from loading at startup…
~/.config/lxsession/LXDE-pi/autostart
#comment out this lxpanel line...
@lxpanel --profile LXDE-pi
…and then tinkered with putting a Shell Command in Xojo to load the TaskBar should it be needed (kiosk maintenance, etc.).
The following code hangs the app, but gets the job done (linux eventually tells me the app is unresponsive, but it appears to be a move in the right direction). I need to find the right syntax to send lxpanel --profile LXDE-pi , and and have tried some odd things like putting nohup on the beginning of the command, and & on the end, in an attempt to send the request into the background and release the app. I’d love to get some experienced feedback on this one
[code]Dim s As New Shell
Dim cmd As String
#If TargetMacOS Or TargetLinux Then
cmd = “nohup lxpanel --profile LXDE-pi &” #Elseif TargetWin32 Then
cmd = “” #Endif
s.Execute(cmd)[/code]
Hi John.
The shell call fails to execute successfully when setting the mode property, whether it’s set to s.mode=0, s.mode=1, or s.mode=2 , I tried all three. The funny thing, the docs say what s.mode=0 is the default value, so excluding that line should have no effect. However, when I don’t include any setting of the s.mode=[x] property, the shell executes (and hangs). Anys.mode=[x] entry prevents hanging, but fails to execute the shell command.
I tried putting the shell command in a thread, and that didn’t help (the docs said it wouldn’t, but I tried anyway). Even setting a timer to kill the thread after a period doesn’t work either - as the shell call hijacks the entire main thread.
Unfortunately, my development pi isn’t attached to my debelopment system.
And I’m 800 miles away at the moment, so I can’t tinker/check directly for a couple of days.
