I’m old and my memory isn’t what it used to be so please bear with me.
Back when I used to use BeOS all the time, I seem to remember being able to start applications in a specific workspace. For instance, I always started my email client on workspace 2 just by selecting it from the Deskbar. Like there was a setting, somewhere, where you could specify which workspace it should start in.
However, I’m not finding any evidence that it was actually a thing. So, maybe, I’m thinking of a different OS? Or a flavor of Linux?
Anyway, the reason why I bring it up is because I would like to do the same thing in Haiku. I like having specific programs start in specific workspaces. Is this possible?
I don’t remember this feature from BeOS, but it sure would be nice. There could be an attribute available from an app’s “Get Info” panel to set a specific workspace. Unfortunately, most apps being locked in a HPKG we’re not able to save the setting…
The only method I can think of, and which should work nicely for apps you auto-start on boot-up, is to script it in the UserBootscript. For example:
# start app in the third workspace
Workspaces 2
/system/apps/EmailClient
Unfortunately, Workspaces doesn’t currently print out the current workspace. Else you could save the current workspace number in a variable and return to it after launching the app in another workspace.
It would be much nicer to be able to tell the roster about which workspace is the correct one.
Personally I don’t understand why, when launching an app, the roster doesn’t already get the info of where it is launched. I quite heavily dislike opening an app, then switching a workspace, and the app somehow “following” me
It’s going to drive me nuts trying to remember what it was I was using where I could define the workspace for the app to open. Oh well.
The script is mostly a good idea, but it would need a delay (I think) because of how long some apps open. I can start, say, LibreOffice in workspace 2 then switch to workspace 1, but LibreOffice will open in 1 because it didn’t really get all started while on 2. So, it’s not possible to be doing something else because it has to wait for the app to actually start.
$> waitfor
Usage:
waitfor <thread_name>
wait until a thread with 'thread_name' has been started.
waitfor -e <thread_name>
wait until all threads with thread_name have ended.
waitfor -m <app_signature>
wait until the application specified by 'app_signature' is ready to receive messages.
waitfor -n
wait until the network connection is up.
The way I remember doing things is, I would start up the computer, run the email program (which would start on workspace 2), then start up the browser (still on workspace 1). By the time the browser starts, the email client had already started and gotten new mail. So when I switch over to workspace 2, I can read the emails without waiting for anything.
With the delay, it’ll go to workspace 2, start the app and stay on workspace 2 until the app starts, then go back to workspace 1. There’s not much gained there over just switching workspaces manually.
Wasn’t WindowMaker was it? I seem to recall using something with a similar setting, and R5 and WindowMaker were the two things I used with virtual desktops back in the day!
I do the same manually since I use workspaces in Haiku - on Linux Mint I have named the workspaces too with the function I used for.
I haved installed workspanumbers from humdinger and WSnames from llorglas, and since years I planned to come with a post to initiate to merge WSname into workspacenumbers as WScocpit or WS-cocpit. I know that WSname possibly written in yab, so it is more work to convert into c++ code to be merged into workspacenumbers utility.
This direction is preferred, as I like as workspacenumbers is on shelf, instead of placing between running apps, meanwhile the several function can be available with its right-click context menu.
I still had not installed or used windowtailor, however I was red more times about it on the forum. If it would help to make applications to automatically launch in a specific workspace, then that function should call from WS-cocpit, if whenever or ever it evolving to one toolkit managing workspaces and its addition features and management.
I just still had not asked for until now - I’ve just planned to open a thread for some years I know both your utility and llorglas’s - and once just came up as WS-cocpit as if it would be centralized once when I made some visualization of my idea as daydreaming in thinkthank state about Haiku possible enhancements.
Is this option not already present in the current implementation of workspaces? I’ve opened a ticket on trac because this won’t work if the workspaces GUI is running…
It’s not in beta6 at least. The -i parameter shows the layout (columns x rows) butt not the current workspace number.
@korli did the directional switching, I think. Maybe he finds the time to add printing the current workspace, too. Otherwise it should be easy enough, so a patch will come in time, I’m sure.
Would introducing another parameter (“-n” for number of current workspace?) to ease scripting be preferable to adding it to the “-i” parameter showing the layout?
workspacesctl outputs in multiple lines, since I figured “| grep current | awk -F ‘:’ ‘{print $2}’” was an acceptable way to access it in a script, but I’m old and a sysadmin so my judgement on what’s ok in that regard is suspect.
