~adnano/wmenu-devel

7 2

how should xdg-activation be handled?

Details
Message ID
<ea252cbaf9003a3eb8a840e037296d89@disroot.org>
DKIM signature
pass
Download raw message
in the default sway configuration, wmenu alongside dmenu_path is used 
for
using it to execute the program with swaymsg:

	# Your preferred application launcher
	# Note: pass the final command to swaymsg so that the resulting window 
can be opened
	# on the original workspace that the command was run on.
	set $menu dmenu_path | wmenu | xargs swaymsg exec --

sway does this to make the descendant program have the environment 
variable
$XDG_ACTIVATION_TOKEN; this variable (quoted by emersion) is used to 
properly
give focus to the launched app, to display it on the correct workspace.

for migration to wmenu_run on sway, xdg-activation needs to be 
implemented, which
is not easy due to it's nature as a protocol. theres only a few ways it 
can be done:

1. require leon_plickat's wat program as a dependency[1]
2. distribute a miniature copy of leon_plickat's wat program alongside 
wmenu (eg. wmenu_token)
3. implement a subcommand/flag for wmenu to fetch the token (eg. wmenu 
-t)

all of these methods in the end, will take a token and export it to the 
environment
in wmenu_run. there are also some other ways which are undesired:

4. integrate wmenu_run as part of wmenu, which is difficult to implement 
due to the caching
    system present
5. use 'swaymsg exec' as part of wmenu_run, making it compositor 
specific

which one of these methods are favored? personally i think the second 
method is the best.

[1]: https://git.sr.ht/~leon_plickat/wat
Details
Message ID
<D0DU6FBNGHNL.282SDF6WTQ7TU@maolood.com>
In-Reply-To
<ea252cbaf9003a3eb8a840e037296d89@disroot.org> (view parent)
DKIM signature
pass
Download raw message
I think the best approach would be to have wmenu implement the xdg-activation
protocol, and then execute the program itself. Perhaps a new flag should be
added to make wmenu execute the selected item (e.g. wmenu -x).
Details
Message ID
<D0DWMCWTFMTQ.336UH3HLBIN7O@maolood.com>
In-Reply-To
<D0DU6FBNGHNL.282SDF6WTQ7TU@maolood.com> (view parent)
DKIM signature
pass
Download raw message
I pushed a commit which adds a new wmenu -x flag. Feel free to try it out and
let me know what you think.
Details
Message ID
<dcba560c18626a2541806e63b6f0b347@disroot.org>
In-Reply-To
<D0DWMCWTFMTQ.336UH3HLBIN7O@maolood.com> (view parent)
DKIM signature
pass
Download raw message
On 2024-04-07 15:54, Adnan Maolood wrote:

> I pushed a commit which adds a new wmenu -x flag. Feel free to try it 
> out and
> let me know what you think.

This is not quite what i had expected, and this is makes wmenu do 
something it shouldn't.
wmenu is a menu program, not an executor. wmenu -x should print out the 
xdg token only.

If wmenu were to handle execution, then let's integrate wmenu_run into 
wmenu, which obviously is beyond the scope of wmenu.
Details
Message ID
<D0K5YZ10UECB.2K1LV657BIAEF@maolood.com>
In-Reply-To
<dcba560c18626a2541806e63b6f0b347@disroot.org> (view parent)
DKIM signature
pass
Download raw message
On Mon Apr 8, 2024 at 5:03 PM EDT, sewn wrote:
> This is not quite what i had expected, and this is makes wmenu do 
> something it shouldn't.
> wmenu is a menu program, not an executor. wmenu -x should print out the 
> xdg token only.
>
> If wmenu were to handle execution, then let's integrate wmenu_run into 
> wmenu, which obviously is beyond the scope of wmenu.

I agree that it is not ideal for wmenu to handle execution, but I think the
alternative of having another program be in charge of it is worse. Printing the
token in addition to the selected item feels like more of a hack than simply
executing it with wmenu.

Another possible approach would be to have another program fetch the token,
execute wmenu, and then run the selection. I'm not sure if that's much better
than the current approach, though. Perhaps this could be part of swaymsg exec.

bemenu also has a bemenu-run command which executes the selection, so there
is already some prior art there. We could potentially integrate wmenu-run into
wmenu like bemenu does, but that might be unnecessary.
Details
Message ID
<82aa50e385254a5b715c9b2fa2874e78@disroot.org>
In-Reply-To
<D0K5YZ10UECB.2K1LV657BIAEF@maolood.com> (view parent)
DKIM signature
pass
Download raw message
On 2024-04-15 00:29, Adnan Maolood wrote:

> Printing the token in addition to the selected item feels like more of 
> a hack
> than simply executing it with wmenu.

Why? I don't see a reason why this is. I believe printing the token is a 
better
solution. Tools should work together!

> Another possible approach would be to have another program fetch the 
> token,
> execute wmenu, and then run the selection. I'm not sure if that's much 
> better
> than the current approach, though. Perhaps this could be part of 
> swaymsg exec.

Initially, when i had talked to emersion in #sway, he suggested to 
instead make
wmenu_run support xdg activation tokens, to be universal as oppose to 
splitting
to wmenu_path and wmenu_run so swaymsg exec can be used.

> We could potentially integrate wmenu-run into wmenu like bemenu does, 
> but
> that might be unnecessary.

This is unnecessary because wmenu is not supposed to handle app 
execution.
Details
Message ID
<D10H3TIM11RA.1S6VHIFMI2RP3@maolood.com>
In-Reply-To
<82aa50e385254a5b715c9b2fa2874e78@disroot.org> (view parent)
DKIM signature
pass
Download raw message
I added a new wmenu-run executable to replace the wmenu_run script. It
implements support for XDG activation. The option to execute the selection of
wmenu has been removed.
Details
Message ID
<81b89fd0448c6d645e2e307d95ba827b@disroot.org>
In-Reply-To
<D10H3TIM11RA.1S6VHIFMI2RP3@maolood.com> (view parent)
DKIM signature
pass
Download raw message
On 2024-05-04 04:36, Adnan Maolood wrote:

> I added a new wmenu-run executable to replace the wmenu_run script. It
> implements support for XDG activation. The option to execute the 
> selection of
> wmenu has been removed.

Why did you choose to make a new executable, with the same code as 
wmenu? Now wmenu is double the size for no reason.

Couldn't you have chosen to, at the bare minimum, symlink it to wmenu? 
So the *ONE* wmenu executable knows that it is being invoked?

Additionally, the caching implemented in wmenu_run is gone, which means 
wmenu-run has to read PATH every time it is ran.
Reply to thread Export thread (mbox)