the problem I'll be describing might be caused by different reasons:
on linux opensuse leap 15.1 gnome (wayland) I can share e.g. mupdf but not evince or libreoffice in chromium jitsi session with screen share application window
another participant on windows tried to share a pdf document using microsoft office 365 and it seemed to show on his browser, but not on the other conference participants' browsers (one chromium on linux as in 1., the other firefox on windows), so he could not share his screen
I could not find any information on this topic using search machines. So I would appreciate if there is any answer on this out there in the community.
Looking forward to solving this ...
Cheers
JFM
PS: on the setup described in 1. also obs studio fails to screencast, maybe there is something related to this system setup causing this problem, some video driver setting e.g.?
This is probably related to Wayland, which has more restrictions than classic Gnome. Since you are having the same issue with OBS this sounds like this a classic Wayland permission issue.
I know they are working on implementing screen sharing support via pipewire but no idea how far this is.
You might try to switch back to Gnome on the X-Server until this is properly implemented.
I have some desktop linux software, which I'd like to use on Windows and make it as much easy to install as possible. Easier than "go install VirtualBox and use this Ubuntu image with all the preinstalled stuff".
I've looked at "portable ubuntu project" (which can be run as usual win-32 application) but it does not feel like something robust, and has old 10 version of ubuntu in it. And seems like you can't use it on 64-bit Windows.
Or if there is no other way - can you recommend a way to create a super robust automatic windows installer which will install VirtualBox and create a virtual machine using snapshot? I need it to run smoothly on very wide range of new and old versions of MS Windows.
Or actually any thoughts on this topic would be much appreciated.
I'm looking for a way to programmatically manipulate a windows program running on Linux under Wine.
Is there something similar on Linux to the Windows SetWindowForeground win32 command?
A function that sets a window by name to the foreground, that will work with a Windows program running under Wine on Linux?
Doe's wine use X11? If so I may be able to utilize this answer, will experiment and circle back
In Linux application windows (including your wine apps window) are managed by your desktop environment's Window Manager (WM). The Window Manager controls how windows are placed and the controls which operate on the windows (resizing, minimize, maxize etc).
Unfortunately there is no standardised Window Manager the major desktop environments (GNOME, KDE etc) have developed their own Window Managers and some people run stand alone WMs like IceWM or more exotic tiling WMs etc.
KDE's WM is called KWin, Gnome's is Mutter, Unity uses Compiz (I think - haven't used Ubuntu for a long time).
When the WM is running in an X sesion it probably uses X11 API internally to raise and lower windows.
However most modern WMs will prevent userpace X calls from popping up windows (because of security concerns etc) You will need to use the WM's wrapper functions. I think Wayland (whenever it is finally available) will have a proper secure API so this shouldn't be an issue.
The short answer to your question is any program you write will likely need to be Windows Manager specific and you should consult the documentation for your WM.
Long Answer - there is a freedesktop.org standard called Extended Windows Manager Hints I'm not sure how good conformance to the spec is among differing WMs (major ones like Gnome and kDE should be good). The property you are interested in is Window State (NET_WM_STATE)
See: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html
I hope that helps - my knowledge of WMs is probably outdated but should steer you in the right direction - I haven't really played around with WMs since GLX first came out and Compositing (wobbly windows and all that jazz) was in vogue.
You can use X11 window manager xdotool or X window manager wmctrl.
Consider the following scenario. A MS windows application titled WordWeb Installer running in wine on Ubuntu on workspace 2. Current workspace : 1. To switch to workspace 2 and focus the wine app execute
wmctrl -R wordweb or
xdotool windowactivate $( xdotool search --name wordweb )
I've just finished the LFS book and my Linux system is working right now. I want to use OpenGL to display graphics on the screen, while the only installed package right now are those described on http://www.linuxfromscratch.org/lfs/view/stable/chapter03/packages.html.
I don't want to install something like Gnome, KDE or X.org. Instead, I want to use OpenGL directly from my software. Is this possible, and how can I do this? Or is it just as easy (I don't think so :'p) as writing an OpenGL application which runs full screen?
You don't have to install Gnome or KDE. These are used to managed windows, and you can launch graphical applications without having a window manager.
Therefore, you'll have to install a X server. The X server is responsible of drawing things on your screen. Without X server, you can't launch graphical applications.
Once X has been installed, launch it, export your DISPLAY environment variable, and the rest is like writing an OpenGL application which runs full screen :-)
You can use Pygame as well to create custom launch UI. Also try looking at Wayland compositor as it has replaced XServer in verisons like Fedora and Ubuntu.
kmscube DRM example
https://github.com/robclark/kmscube
This is possibly the most popular demo available, it uses OpenGL and EGL.
Unfortunately, the Ubuntu 18.04 package with NVIDIA proprietary drivers it does not work for me after going into Ctrl + Alt + F3:
drmModeGetResources failed: Invalid argument
failed to initialize legacy DRM
bug report: https://github.com/robclark/kmscube/issues/12
But I did get it working on emulator.
It takes over the entire display, and shows a colorful spinning cube.
Many of my users have been telling me that they'd like to run my software on their Linux machines under Wine.
But I'm a Windows Developer who has practically no experience with Linux.
Now I could spend a month or two installing Linux, learning Linux, installing Wine, learning Wine, and thoroughly ensure my application runs well under Wine. But I am still developing for Windows, so I don't want to take so much time away from development right now.
So what can I do without too much effort to get my program running as well as possible under Wine?
I did find this General help on running applications under Wine.
Download VMWare and an Ubuntu virtual machine (Ubuntu is a popular Linux distribution) from the VMWare site. This will provide you with a working Linux O/S inside your Windows environment without needing to install Linux manually.
You can then use the instructions here to install Wine, that Wiki page also provides you with some instructions on how to use it.
If you follow what Adam Rosenfield suggested and just try running your application in Wine unmodified, you will be able to determine quickly whether there are problems. My guess would be that there are some, otherwise your users would not have contacted you about it :)
There are many ways for getting help with debugging applications in Wine, consult the website for options and pick a few ways that suit you. As always, it's best not to rely on a single channel for communication.
Also, if you are more comfortable with developing in Windows, the approach of using a virtual machine will allow you to compile your code as usual in Windows and copy the binary into the virtual machine for testing (Ubuntu supports browsing/mounting Windows shares).
As long as you're not doing anything unusual such as playing around with hardware or poking around in undocumented API calls and data structures, you should be able to run your code under Wine with few or no modifications. Wine has a fairly complete implementation of the public Windows APIs, so if your program plays nice and doesn't mess around, it should just work.
Don't use too much of the windows API! Don't use anything new from Microsoft ;)
Avoid using WPF is the #1 suggestion.
But it really wouldn't kill you to test your app under Wine. It's not that hard to try; it certainly won't take months. For instance:
Use http://www.ubuntu.com/getubuntu/downloadmirrors#wubi to install
Ubuntu into a file on your Windows machine, then start ubuntu and install the latest Wine from
http://winehq.org/download/deb
Then try running your app's installer.
If it doesn't work, check the Wine FAQ, ask for help in one of the wine forums, and/or file bugs in wine's bug tracker.
Should take about three hours from a dead start to trying out your installer.
I was rather surprised when one of my Delphi5 applications just worked out of the zip.
The only real way this is going to work is to do it yourself, i.e. install vmware and a linux distro as Sean suggested. Linux isn't actually that hard, and we're all here to help.
Having done a quick test I can confirm that it largely works. There is an ACCVIO reading 0x34 during start up, the error dialog can be ignored and the application runs, I opened the Steve McCarthy GEDCOM.
Screenshot
This was using Wine 1.1.12 under MEPIS 7.9.94-rc1_32 under VMWare. Highly recommend to use VMWare for this sort of thing.
What language/platform do you develop with? Depending on which it is, it should be no trouble to get it running native. For example, if you use Java or Python, both operate very cleanly on Linux. Likewise, if you're a .NET developer, you should be able, with some pain, to get your app running in Mono.
Find Linux beta testers. It can reports a bug to WINE developers or find a bug in your application.
Wine is more sensitive to errors than Windows. For example, Wine will crash on NULL window handles, and fail to create windows if the class is invalid, whereas Windows is more robust and will just circumvent the error.
It's an opportunity to clean up your code.
I was amazed at how well Wine ran my app the first time I tried. However, I had to get rid of a third-party driver-based component.