Tricky situation as it involved three programs: the terminal, the shell and the newly launched app.
Your approach of essentially by-passing the shell and communicating between the two GUI apps is likely the most viable.
Otherwise we would need some standard protocol/interface between shell and terminal so that the shell could ask for a new activation token every time it launches something. And there are many shells, probably too many to make this work for enough users.
That brings the area at the bottom right of the panel to just say the current Activity.
It is also the widget I am using, mostly as an indicator on which activity I am on.
Switching happens almost exclusively with shortcuts :)
I think the panels are currently not affected by activities, i.e. they remain the same across activity switches.
Applets on the desktop, wallpaper, etc seem to be per-activity
Getting rid of what? Wallpapers? The ability to have different ones per activity?
Mostly due to work. One activity for each on: browser, IDE/Editor, email, etc on different virtual desktops
I also have 3 monitors but also 6 virtual desktops and 5 activities :)
You can have different wallpapers (and different widgets and all kinds of other things) per activity.
I think the focus of the article is on that specific device as this is the one the developer had access to and personal need to get it to work.
The chosen approach of adding support to an existing kernel driver and libinput suggests that any changes above, e.g. in Plasma, should work generically across similar devices as long or as soon they are supported on the kernel level.
That might already be true for the device you have or could have been enabled by these recent changes.
In the worst case it should enable someone to make similar additions to the low level stack without having to worry about the levels above. E.g. by a driver developer who doesn’t necessarily have development experience or setup for desktop changes
No.
People work on things they like to work on. Might be hard to understand if you don’t create things for fun or for the challenge or because you have a use case but many people are motivated that way.
Which doesn’t have the interface that this entire concept is about
I guess that will mostly depend on whether the web interface detects being using in big screen mode.
and is limited to 720p.
Really? Last time I streamed on my laptop I had the impression it was full screen resolution, i.e. 1080p. Might depend on the subscription level, you connection and with which browser.
That explains absolutely nothing…
It explains the question of “why do they make this”.
What’s changed is a compatibility layer.
Much more than that. What has changed is that studios explicitly work towards compatibility with it.
Are you saying there’s going to be a compatibility layer for iOS apps or something?
Well, there are already those for Android.
Wouldn’t be surprising if someone did the same for Tizen or any of the other vendor’s SmartTV systems. They all Linux systems after all.
Also this is only an issue for some proprietary apps. Some of which are often just fancy frontends for services which are also accessible in a web browser.
The people working on this might not even be using those
I vaguely remember having that on a new user account that I created for a demo.
I think what I did back then was to go to about config and set browser.tabs.drawInTitlebar to 0
Not just window position. Also size, which screen, which virtual desktop, which activity, state (maximized, etc)
Probably just replacing “KF5” with “KF6” in the cmake file and changing the version from “5.90” to something like “6.0” (or higher)
The “menu at the top of the screen” is just one possible visualization.
Essentially an application that supports this can “export” its menu so that it can be consumed by another process.
In the case of the “global menu” this is Plasma (applet).
However, the data can also be consumed for example by a window decoration plugin, like this one https://discuss.kde.org/t/decoration-with-locally-integrated-menu/29492
There are likely many more possibilities. Maybe a Kwin effect that shows the menu as a circle of options around the mouse cursor’s current position.
Strange video description. Contains advertisement for Proton Drive which does not even have a Linux client or any form of KDE integration
Welcome to KDE Plasma land 😀
I am particularly happy that you’ve mentioned activities! 😁
They are a somewhat under appreciated (or misunderstood?) feature that I personally find invaluable and it is great to see someone else feeling the same way
The primary issue is always that the shell is an “unaware participant”, essentially blocking the flow of information between the terminal and the newly launched application. Your approach essentially creates a by-pass communication channel which is likely the least hackish way even if it might not feel like that.
I have tried to come up with alternative ideas but they all have their own difficulties.
One option would be to use a mechanism like LD_PRELOAD to intercept the shell’s exec-family calls and inject an updated activation token.
A rather wild idea was to run the shell in-process on a thread of the terminal. This would then allow access to the now shared environment.
Probably best to somehow get various terminal developers together to think about this. They all have this use case at hand and best understand how they are currently “embedding” the shell.