On Tue, 16 Mar 2021 10:04:35 +0100 Vojtěch Bubník wrote:
VB> I was pleasantly surprised how well the Linux integration works. By default
VB> a relatively small Debian 10 image gets installed, which contains both GTK2
VB> and GTK3 images, thus a Linux AppImage will most likely run without having
VB> to install another dependencies. Our PrusaSlicer runs quite well.
This is indeed great news, thanks for sharing!
VB> We have experienced the following glitches though:
VB> 1) Swapped red/blue channels in OpenGL when multi-sampling was enabled, see
VB> Most likely it is a bug in the OpenGL hardware virtualization layer virgl.
VB> We worked around it by detecting Chrome OS and disabling multi-sample
VB> anti-aliasing in our application on Chrome OS. It may be an OpenGL
VB> initialization issue in wxWidgets as well though.
If it's a bug in wx, it should be fixed, of course. Do any other
applications using OpenGL (with multi-sample) show this issue? But it might
be better to wait until the bug above gets looked at.
VB> 4) Entering full screen. Due to the issue 3) and because the screens on
VB> Chromebooks are tiny, there is a button on the keyboard in the first row to
VB> enter full screen mode. For example on xterm this removes the application
VB> title bar and frame. The same applies to our competitor software Cura
VB> written in Qt. For wxWidgets based applications the button does nothing, no
VB> key event is being delivered to the wxWidgets application. However manually
VB> calling wxFrame::ShowFullScreen() works.
Do you know which key code this key generates at GTK level? It's probably
simple enough to map it to some (new) WXK_FULL_SCREEN, we just need to know
what its value is.
VB> 5) When in full screen mode, Alt-Tab is passed surprisingly to the
VB> application. This has been done to support remote desktops I suppose, but
VB> it is very weird for normal desktop applications and I suppose most users
VB> would avoid to t enter full screen mode due to this issue. Is it possible
VB> to not consume the Alt-Tab events by wxWidgets?
I am not sure if we really want to filter out these events if we do get
them. It's simple enough to check for them in the code and, if you really
want to get rid of them globally, you can do it in overridden
VB> 6) Chromebook keyboards have the 1st row of keys switched to "browser back,
VB> browser forward, refresh, full screen, .....". The first row may be
VB> switched to function keys (F1..F10) in setup, also the "search" key plus
VB> the 1st row sends an F key. For the Linux wxWidgets apps, only the browser
VB> back, browser forward buttons are passed to the application with
VB> WXK_BROWSER_BACK, WXK_BROWSER_FORWARD. The other keys, namely the "full
VB> screen" key are not routed to the Linux application (maybe they are, but
VB> not translated to wxEvents).
Again, if you could please look up the GTK key codes, we should be able to
map them to something.
VB> 7) Also the Chromebooks are equipped with touch screens. On Windows 10,
VB> two-finger multi touch events are automagically translated to mouse events:
VB> Zooming gesture translates to scroll wheel events, two finger moves
VB> translate to right mouse dragging. I did not have a chance to test that on
VB> Linux / GTK, but on ChromeOS all gestures work as left mouse click or left
VB> mouse dragging only. Zooming and right mouse events are not simulated. I
VB> have no idea whether the screen touch behavior on Crostini is Crostini
VB> specific, or whether this is how it works on Linux / X11 / GTK2/3. Is there
VB> any plan for such Linux / GTK mouse emulation through multi-touch gestures?
Sorry, I'm completely lost myself in Linux/GTK multitouch support, I don't
even know at which level is this supposed to happen. We do have gestures
support in wx itself, see wxWindow::EnableTouchEvents(), but I'm not sure
if this is really what you need...
TT-Solutions: wxWidgets consultancy and technical support