search

YACReader / yacreader

This repo contains the code of YACReader's desktop version.
https://www.yacreader.com
GNU General Public License v3.0
950 stars 94 forks source link

[feature] use same x-window class for library and viewer windows #124

Open brainchild0 opened 4 years ago

brainchild0 commented 4 years ago

Unix-based window managers treat the library and viewer windows as distinct applications. While apparently the implementation choice separates the two functions into separate executable files, both are conceptually part of the same application. As many Linux desktop systems group open windows corresponding to the same application, based on the class attribute of the X windowing system, it is intuitive if library and viewer instances are grouped together.

Note that optimal implementation of this request may involve customizing the FreeDesktop desktop entry associated with the Linux packaging of the application.

selmf commented 4 years ago

If I understand correctly implementing this would require setting a common StartupWMClass for YACReader and YACReaderLibrary? If that is the case this is a rather trivial change and I see no issue in including this feature. Patches are welcome :)

jeremydouglass commented 4 years ago

Interesting. Would such a change affect OS X windowing in the same way? There they are likewise separate applications, and the desktop acts accordingly.

selmf commented 4 years ago

No, this change would only affect platforms using the X windowing system which usually does not include OS X.

brainchild0 commented 4 years ago

I originally considered only the Linux case because I am a Linux user and have only used the application in this context.

Whether the separate groupings of the two window types by the window manager is deliberate or accidental, my feeling is that it is less natural than shared grouping from a standpoint of familiar and usable metaphors.

From a design perspective, uniform behavior across platforms is preferred, even if the implementations are distinct. I suppose the project maintainers need to indicate whether they prefer a separate issue opened for another platform, or whether the current one might be expanded in scope.

jeremydouglass commented 4 years ago

From a design perspective, uniform behavior across platforms is preferred, even if the implementations are distinct.

That's it in a nutshell. If window grouping is implemented under X windows, then the platforms will behave differently. And that's fine by me, honestly -- I don't have strong feelings about it, just noting it.

selmf commented 3 years ago

Short update. I did some tests with setting a common StartupWMClass on my Arch Linux machine using LXQT, but this did not result in the desired behavior. Unless I am missing something ovious this is not as trivial as I would have thought.

More information is required.

brainchild0 commented 3 years ago

It seems that StartupWMClass is less important than WMClass.

See question in StackExchange.

selmf commented 3 years ago

It seems this isn't trivial to change in Qt. You can set the first part for WM_CLASS by running a Qt5 app with -name customclassname as an argument and that will result in a change of the class, but at least LXQT seems to group windows based on the second part of the WM_CLASS. So allthough YRMV there is no universal solution for this.

brainchild0 commented 3 years ago

The second part seems to the relevant one, that the application developer sets, to identify the particular application, rather than some running user instance.

Have you seen QtApplicationManager::setWindowProperty?

selmf commented 3 years ago

The second part seems to the relevant one, that the application developer sets, to identify the particular application, rather than some running user instance.

Have you seen QtApplicationManager::setWindowProperty?

I don't think QtApplicationManager can be used with a classic X11/Wayland Qt app. It seems to be made for qml apps in an automotive/car environment.

brainchild0 commented 3 years ago

I wish I had noticed that I was looking at the automotive module, not one for desktop applications.

Well, is it possible to communicate directly with the window manager or other parts of the X11 system, through direct libraries, rather than the Qt modules?

selmf commented 3 years ago

That could be an option, but this is looking less and less like something I can just enable by adding some trivial lines of code.

Qt sets the second part of the WM_CLASS to the same value as the application name or, if that is not set, the name of the executable. We can't rename the app - this would trigger a whole cluster of problems with config files and other places where this name is used.

I'm afraid that adding this feature is not possible without a lot of work or even patching Qt. I'm happy to give it another go if you find a clean solution, but for now I'll call quits on this.

brainchild0 commented 3 years ago

I'd be happy if you left the issue open. Someone might discover it who can offer a solution.

selmf commented 3 years ago

Don't worry, I didn't plan on closing it. By the way, did you try if the -name argument is sufficient for your usecase?

brainchild0 commented 3 years ago

I have not tried, but if it works then it could be handled in the desktop launcher distributed in the application.

brainchild0 commented 3 years ago

Giving this entire topic deeper consideration, it seems appropriate, for anyone interested in doing so, to file the general issue as a downstream request, in Qt. I have not found any indication that the subject, which I characterize as a design limitation, yet has been discussed in this broader context.