Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
How to Specify Virtual Desktop for a Cron Task?
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Wed Oct 23, 2024 3:59 pm    Post subject: How to Specify Virtual Desktop for a Cron Task? Reply with quote

I'm looking for some help writing a cron task that opens a browser instance and assigns it to appear on a specific virtual desktop in X11.

My window manager is KDE. So far I've been able to deploy the task, but I have had no luck designating the virtual desktop where I 'd like it to appear.

My KDE desktop has multiple virtual desktops that I can select with Pager. I'd like to restrict the specified task to appearing only on the specified virtual desktop. Right now I've got things working to the point that deploying the task works reliably, but the window manager is assigning the task to whichever virtual desktop happens to have focus, or to have recently had focus, rather than putting it on the virtual desktop I'd like it to be assigned to.

I'm using:
KDE Plasma 5.27.11
KDE FRameworks 5.116.0
Qt 5.15.14

Here's an example of a cron entry where I can call Brave Browser to open the Gentoo Forums home page:

Code:
00  07   *   *   *   export DISPLAY=:0 && /usr/bin/brave-browser-stable --window-position=0,0 --window-size=1050,2100  https://www.forums.gentoo.org 2>&1


My problem is that I can't figure out how to designate the virtual desktop where the browser will appear.
I've tried adding display number suffixes to the display value, hoping that it would assign it to one of my virtual desktops, buy no joy. The following example doesn't work in assigning the broswer to appear on virtual desktop 4:

Code:
export DISPLAY=:0.3


Ideas?
Back to top
View user's profile Send private message
sMueggli
Guru
Guru


Joined: 03 Sep 2022
Posts: 497

PostPosted: Wed Oct 23, 2024 4:24 pm    Post subject: Reply with quote

Why are you using a cronjob for this task? I think XDG autostart is a better aproach to automatically start graphical applications.

Virtual desktops looks like a desktop specific thing. I do not think that cronjob and XDG autostart are aware of this.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Wed Oct 23, 2024 4:42 pm    Post subject: Reply with quote

Thanks for responding.

My feeble undestanding of XDG Autostart is that it's used to:
a) autostart applications when the desktop is started, or
b) autostart applications when a drive is mounted

In my case, those events aren't correlated with the time that I want the application to be deployed. So I'm looking at BASH and cron.

I'm thinking there's got to be some way to communicate with the window manager to assign a virtual desktop ... I just haven't found it yet.

Thanks again.
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3445

PostPosted: Wed Oct 23, 2024 5:11 pm    Post subject: Reply with quote

Long long time ago KDE had an option in the config manager to bind an application to a workspace, is it still there?
_________________
Make Computing Fun Again
Back to top
View user's profile Send private message
Ralphred
l33t
l33t


Joined: 31 Dec 2013
Posts: 656

PostPosted: Wed Oct 23, 2024 7:13 pm    Post subject: Reply with quote

There are a few ways to do this, but both have implications regarding "interrupting" what you are doing when the job runs:
  • Use KDE's "special window settings/rules"
    Easiest way to try this is let the task run, then right click the top left icon and use "special window settings" in the "more" menu.
    The downside of this is with a browser the window title changes with once the page is loaded, so you might find it ignores "window title".
    There are multiple options of when to apply the "desktop" property, but if you end up having to use "Force" and can't get the "window title" to work you'll confine all instances of Brave to the same desktop.
  • Use xdotool
    There are two ways to use this, the first is simple, use xdotool to read the current active desktop, if it isn't the one brave is to spawn in, change to that (xdotool again), once it's spawned, change back.
    The second way would be to have xdotool find the window after it's spawned, and use set_desktop_for_window to move it where it's supposed to be.


Below is a snippet from my media thingy, it starts the browser, waits for it to connect the amazon video site, then set focus on it so I can send the keystrokes for fullscreen etc.
Code:
/usr/bin/vivaldi >>~/vivaldi.log 2>&1 &
until [ "Amazon.co.uk: Prime Video - Vivaldi" == "${window_name}" ];do
    sleep .25
    window_name=$(xdotool getwindowname $(xdotool search --class "Vivaldi-stable"))
done
ID=$(xdotool search --class "Vivaldi-stable")
xdotool windowfocus ${ID}
I don't know how much you'd have to tinker if you have multiple brave window instances (probably iterate them looking for the right window title).


As a aside, when starting a thing inside KDE/Plasma from outside, I find using xdotool to have plasma/kwin start something via a keyboard shortcut works better than starting it by external script, it inherits the environment properly (I have udev start steam this way when my BT gamepad connects).
EDIT:
szatox wrote:
Long long time ago KDE had an option in the config manager to bind an application to a workspace, is it still there?
Yes it is, I use it extensively because of my complicated sound set-up, it also lets you confine them to specific activities too, I wote the reply abaove and had to go out before finishing, hence not starting my reply referencing your post.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Fri Oct 25, 2024 1:22 pm    Post subject: Reply with quote

szatox wrote:
Long long time ago KDE had an option in the config manager to bind an application to a workspace, is it still there?

I have to confess that I don't know. One of my problems is that KDE/Plasma is not very well documented.

Regarding the binding of an application to a specific workspace, I'm not sure that would help if it binds every instance of that application to an exclusive workspace. At any given time I might have a browser session open on one of many virtual desktops. Right now my cron task successfully opens a new browser instance, but it does so on whatever virtual desktop has focus, without regard for virtual desktop assignments or what I may be doing. This is a bit inconvenient, as the opening browser window steps on whatever I happen to be doing as the new window steals focus from whatever task I'm working on. I'd like to be able to assign a particular window to be opened on a particular virtual desktop, without stealing focus when I'm working on another virtual desktop. This would require allowing new instances of a browser to be opened on a specified desktop without stealing focus from wherever that focus might be, and it would also require the browser application to be available on any designated workspace. I'm not sure if binding an application to a workspace would interfere with that.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Fri Oct 25, 2024 1:58 pm    Post subject: Reply with quote

Ralphred wrote:
There are a few ways to do this, but both have implications regarding "interrupting" what you are doing when the job runs:
[list][*]Use KDE's "special window settings/rules"
Easiest way to try this is let the task run, then right click the top left icon and use "special window settings" in the "more" menu.
The downside of this is with a browser the window title changes with once the page is loaded, so you might find it ignores "window title".
There are multiple options of when to apply the "desktop" property, but if you end up having to use "Force" and can't get the "window title" to work you'll confine all instances of Brave to the same desktop.


I mentioned in the previous post that I've encountered the focus stealing/interrupting problem when the cron job runs. that's not a big deal when cron tasks occur infrequently, but it becomes decidedly frustrating with frequently occurring cron tasks. Untimately that establishes a barrier to automation of frequent tasks.

I had previously spent a lot of time trying to get "special window settings" and "special application settings" to work within the desktop manager using the menus available by right-clicking on window header. I have not had much luck. Obviously, when we're talking about browser instances, where many of the parameters would be the same when many browser instances are open, it makes sense to configure the special window or app settings to seek an exact match against the window title. In theory that's a good solution as chrome allows you to set the window title using the "--window-name=<string>" command line parameter.

In practice, naming the window using the command line parameter works superficially, in that the window is indeed displayed with the expected string in the title; unfortunately the window manager ignores the title string as well as all of the previously saved instructions regarding window sizing, desktop location, etc., irrespective of which setting I may choose, even when "forced."

I must be doing this entirely wrong because I can't get things to work if multiple instances are open -- the only other possibility is that these menus don't really work as advertised. Given years of fighting with malfunctions of these specialized windows settings, I always thought that they just don't work. I'd be surprised to learn that other people can actually get them to work as intended.

As you suggested, I have noticed that the window title rules are not honored -- this might suggest that the timing of the population vs. inspection of the window title is critical and a necessary condition is not being met. Unfortunately I've had no luck in spite of choosing a variety of control options including 'force'. I'm king of at a loss here.


I have tinkered with xdotool in the past, though not as extensively as with the special window settings / special application settings. I'll have to look at that again.


I seem to remember seeing a post somewhere that KDE/Plasma supports a dbus interface to the desktop manger when commands are initiated externally (ie: cron tasks). Unfortunately, there seems to be zero documentation about that, even though it sounded like dbus was the preferred way to do what I'm trying to do, insofar as it should provide a direct control interface to Plasma.


Thanks to everyone for their suggestions. :wink:
Back to top
View user's profile Send private message
Ralphred
l33t
l33t


Joined: 31 Dec 2013
Posts: 656

PostPosted: Fri Oct 25, 2024 3:04 pm    Post subject: Reply with quote

Bob P wrote:
I mentioned in the previous post that I've encountered the focus stealing/interrupting problem when the cron job runs

The obvious way around this is to bind the browser you want to "auto open" to a specific desktop by window class with "force", and only use that browser for the cron task.
The first time the task runs you'll get a focus issue, but after that you can just have it open a new tab in the background - you just need to be careful about browser settings so it actually loads the tab and doesn't sit there waiting for focus before it does.

The other thing that springs to mind is xnest, but the config, set-up and overhead involved pushes the idea to the very border of "do you want this, or actually need it?".

EDIT: I just tested this, because reasons: If you force a window class to a specific activity, invoking it doesn't do anything to focus as long as it's a different activity to the one you are currently in, so many headaches sidestepped that way...
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sat Oct 26, 2024 12:48 am    Post subject: Reply with quote

My experience is that when launching an app from the command line KDE/Plasma completely ignores all of your window or application window rules/settings in KDE, as well as your command line specifications, if there is any existing open browser instance. If no browser instance is open, then the window will be deployed honoring the on-screen location and dimensions parameters passed via the command line, but the desktop assignment in the KDE window rule will not be honored under any circumstance and the window gets opened on whatever vdesktop has focus.

OTOH if any browser window is open on any other vdesktop then all of the command line parameters regarding window size and location get ignored: vDesktop number, window location, window dimensions all get ignored. The parameters assigned to the window/application window rules in KDE will also be completely ignored. The location and dimensions for the newly generated browser window get cloned from whatever open browser instance most recently had focus, and the new window is opened on whatever desktop currently has focus.

For example, if I have browser instances on desktop 3 and 5, where the instance on 3 is narrow and 5 is wider, and I'm on desktop 1 in a terminal, then when the cron task executes the browser will be opened on desktop 1 with the dimensions copied from the instance on 3 or 5 depending on which one most recently had focus. All of the window management class rules get completely ignored, even when all of the browser instances have unique window titles and the rules are set to pay strict attention only to title and there are separate rules for each window instance. The bottom line is that the KDE window class thingy doesn't work unless there is only 1 instance of the window class (the one it opens). As soon as a second one exists the rules seem to be completely ignored.

Interestingly, the vdesktop number in the window classes only gets honored if there's a single instance of a window class AND the browser gets launched from within KDE. If the browser is launched via a shell script then the window manager comletely ignores KDE's window rule set to cast that new browser instance to a specific desktop.

I hadn't thought about this when I wrote my previous posts, but I've been using virt-manager within KDE/Plasma to launch virutal machines, with them reliably cast to a specific desktop if and only if they are launched from wthin the window manager. If I invoke them from the command line the window class rules for vdesktop assignment get ignored, just like with the browser instances.

It's hard for me to imagine that I'm the first person who's ever wanted to invoke an application from a command line and cast it to a specific vdesktop. It really amazes me that there isn't a straightforward solution to this problem. that is to say, if one does exist, I've had a hard time finding it.

I have LOTS of auto-opening web pages in my cron task. Having a unique browser for each instance doesn't really simplify the problem for me as I'd need many many different browsers. That and I'm really not a fan of browser-hopping.
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3445

PostPosted: Sat Oct 26, 2024 8:37 am    Post subject: Reply with quote

You mentioned you want those windows popping on a different workspace, because stealing focus breaks some automation for you. Maybe you could send those windows to a different instance of X? Maybe even start a new instance of X for each of them, so they won't be stepping on each others' toes?
There are ways to run an X-server for a remote user, like xrdp for example (something with SPICE would probably be better for a linux user, but that's not the point). Haven't used them myself, but they surely can run completely detached from any terminals at all, so it should be possible to use them for isolating those cron jobs.


Quote:
It's hard for me to imagine that I'm the first person who's ever wanted to invoke an application from a command line and cast it to a specific vdesktop. It really amazes me that there isn't a straightforward solution to this problem. that is to say, if one does exist, I've had a hard time finding it.
I think people _interact_ with GUIs and _automate_ with CLI.
GUIs are more natural for humans, but a CLI is much a much more defined, which makes it easier to use for a dumb computer devoid of any shred of actual intelligence.
_________________
Make Computing Fun Again
Back to top
View user's profile Send private message
Ralphred
l33t
l33t


Joined: 31 Dec 2013
Posts: 656

PostPosted: Sat Oct 26, 2024 1:15 pm    Post subject: Reply with quote

Bob P wrote:
Having a unique browser for each instance doesn't really simplify the problem for me as I'd need many many different browsers.

You misunderstand, you need two browsers, one for for everyday stuff that you can move from desktop to desktop as you see fit, and one that is used by the cron job that is "confined" to it's own activity (so it can be launched w/o focus stealing/changing vdesktops etc), using forced "application settings" and not "window settings" to overcome the dynamic nature of browser windows.
Bob P wrote:
The location and dimensions for the newly generated browser window get cloned from whatever open browser instance most recently had focus
This is your kde settings doing this, just turn of "allow apps position remembering", it in the "windows behaviour" section of systemsettings, along with where the Virtual Desktop Behaviour is set to "do nothing".

If none of the KDE behaviour settings work, then use Xnest* as suggested
szatox wrote:
send those windows to a different instance of X
and all the focus stealing nonsense goes away.

*set xnest use flag on xorg-server
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum