~tsdh/public-inbox

11 3

[swayr] Subcommand to return windows with icons

Details
Message ID
<1852721829.525740.1668686146374@office.mailbox.org>
DKIM signature
pass
Download raw message
I want to access icon information for all open windows. As swayr has this feature already implemented, it would be great to be able to access it. 
I can see multiple ways to implement this that would work for me (ordered most useful to least usable): 
1. Have a command that prints on every window change a JSON array with all the window nodes extended by `"icon"="/usr/.../icon.png"`.
2. Have a command that returns an array of all currently open windows with their icons added
3. Have a command that just returns the mapping `app_id/class` to `icon`.

(it might be that this mail is duplicate, as my mail program was acting up.)
Details
Message ID
<87zgcpix1u.fsf@gnu.org>
In-Reply-To
<1852721829.525740.1668686146374@office.mailbox.org> (view parent)
DKIM signature
pass
Download raw message
me@modprog.de writes:

Hi!

> I want to access icon information for all open windows. As swayr has
> this feature already implemented, it would be great to be able to
> access it.  I can see multiple ways to implement this that would work
> for me (ordered most useful to least usable):
>
> 1. Have a command that prints on every window change a JSON array with
> all the window nodes extended by `"icon"="/usr/.../icon.png"`.

Swayr uses the Node struct from the swayipc crate for representing the
tree of all outputs, workspaces, containers, and windows.  So there's no
way for me to extend that.

> 2. Have a command that returns an array of all currently open windows
> with their icons added

You mean, as above with an "extended Node" but not on every window event
but just when the command is invoked?  Then the same explanation
applies.

> 3. Have a command that just returns the mapping `app_id/class` to
> `icon`.

That would be pretty easy.

On the other hand, you could just as well stuff the function at
https://git.sr.ht/~tsdh/swayr/tree/main/item/swayr/src/util.rs#L137 and
its requirements in a private crate and have your own tool for that.
I'm a bit reluctant to adding a command that's useful for only one user.
And swayr uses a very hacky (but suprisingly well-working) algorithm for
icon retrieval because doing it the right way™ would mean adding more
dependencies as I'd like to.

Bye,
Tassilo
Details
Message ID
<fc06a007-68b6-415f-9785-1fd19620d71e@modprog.de>
In-Reply-To
<87zgcpix1u.fsf@gnu.org> (view parent)
DKIM signature
pass
Download raw message
Hi


17.11.2022 13:29:48 Tassilo Horn <tsdh@gnu.org>:

> me@modprog.de writes:
>
> Hi!
>
>> I want to access icon information for all open windows. As swayr has
>> this feature already implemented, it would be great to be able to
>> access it.  I can see multiple ways to implement this that would work
>> for me (ordered most useful to least usable):
>>
>> 1. Have a command that prints on every window change a JSON array with
>> all the window nodes extended by `"icon"="/usr/.../icon.png"`.
>
> Swayr uses the Node struct from the swayipc crate for representing the
> tree of all outputs, workspaces, containers, and windows.  So there's 
> no
> way for me to extend that.

I don't think that would pose too much of a problem. Using serde flatten 
it would be possible to return a type adding a field.

```rs
struct ExtendedNode {
  #[serde(flatten)]
  ipc_node: Node,
  icon: Option<PathBuf>
}
```

>> 3. Have a command that just returns the mapping `app_id/class` to
>> `icon`.
>
> That would be pretty easy.
>
> On the other hand, you could just as well stuff the function at
> https://git.sr.ht/~tsdh/swayr/tree/main/item/swayr/src/util.rs#L137 and
> its requirements in a private crate and have your own tool for that.
> I'm a bit reluctant to adding a command that's useful for only one 
> user.

That would be the advantage of a `get_windows` function, I think it woul 
add value further than just my use case. Getting the windows with swaymsg 
directly via e.g. `jq` is quite a complex task (though doable).

> And swayr uses a very hacky (but suprisingly well-working) algorithm 
> for
> icon retrieval because doing it the right way™ would mean adding more
> dependencies as I'd like to.

In case I implement this as a dedicated application, what would be the 
"correct way" didn't really find much more than "look at the .desktop 
files".
Details
Message ID
<871qq1bj0i.fsf@gnu.org>
In-Reply-To
<fc06a007-68b6-415f-9785-1fd19620d71e@modprog.de> (view parent)
DKIM signature
pass
Download raw message
Roland Fredenhagen  <dev@modprog.de> writes:

Hi Roland,

>> Swayr uses the Node struct from the swayipc crate for representing
>> the tree of all outputs, workspaces, containers, and windows.  So
>> there's no way for me to extend that.
>
> I don't think that would pose too much of a problem. Using serde
> flatten it would be possible to return a type adding a field.
>
> ```rs
> struct ExtendedNode {
>   #[serde(flatten)]
>   ipc_node: Node,
>   icon: Option<PathBuf>
> }
> ```

Ah, I didn't know. :-)

> That would be the advantage of a `get_windows` function, I think it
> woul add value further than just my use case. Getting the windows with
> swaymsg directly via e.g. `jq` is quite a complex task (though
> doable).

Ok, I'll implement a new command "swayr get-tree" which is like "swaymsg
-t get_tree" except that it enhances Nodes with a swayr_icon and
swayr_type.  That should make it easy enough to filter out windows with
jq, right?

Bye,
Tassilo
Details
Message ID
<2063511906.37964.1668707266875@office.mailbox.org>
In-Reply-To
<871qq1bj0i.fsf@gnu.org> (view parent)
DKIM signature
pass
Download raw message
Hi Tassilo,

> Ok, I'll implement a new command "swayr get-tree" which is like "swaymsg
> -t get_tree" except that it enhances Nodes with a swayr_icon and
> swayr_type.  That should make it easy enough to filter out windows with
> jq, right?

That would be great, wondering if something like an option to `--flatten` 
would be possible, but without a filter that would just lead to 
problems as it is unclear what to do with the sub nodes of containers
and workspaces.

And it should be possible to flatten it using the `recurse` in jq:
```sh
jq '[recurse(.nodes[]) | select(.swayr_type == "window") | del(.nodes)]'
```
Details
Message ID
<874juwt6cn.fsf@gnu.org>
In-Reply-To
<2063511906.37964.1668707266875@office.mailbox.org> (view parent)
DKIM signature
pass
Download raw message
dev@modprog.de writes:

Hi Roland,

>> Ok, I'll implement a new command "swayr get-tree" which is like
>> "swaymsg -t get_tree" except that it enhances Nodes with a swayr_icon
>> and swayr_type.  That should make it easy enough to filter out
>> windows with jq, right?
>
> That would be great, wondering if something like an option to
> `--flatten` would be possible, but without a filter that would just
> lead to problems as it is unclear what to do with the sub nodes of
> containers and workspaces.

Ah, well, after looking at the code, a get-windows command would be
easier because everything needed for that is already in place.

I just wanted to implement it but instantly hit a wall: swayipc::Node
and everything it contains doesn't implement Serialize (only
Deserialize).  Because of the orphan rule, I cannot implement it myself
and honestly, I wouldn't want to add dozens of manual Serialize impls.

I think the only way is to convince the swayipc author to make all the
IPC structs/enums derive Serialize but I guess there are reasons why
they don't (like binary size or so).  Since the only open issue there is
yours, you might want to file another wishlist item explaining in kind
words why it would be a good idea. :-)

Or, of course, you can still have some get-app-id-to-icon-map command...

Bye,
Tassilo
Details
Message ID
<359217966.135701.1668814868048@office.mailbox.org>
In-Reply-To
<874juwt6cn.fsf@gnu.org> (view parent)
DKIM signature
pass
Download raw message
Hi Tassilo,

> I think the only way is to convince the swayipc author to make all the
> IPC structs/enums derive Serialize

I created an Issue and PR, so hopefully they will add it.
https://github.com/JayceFayne/swayipc-rs/pull/43

> but I guess there are reasons why
> they don't (like binary size or so).  Since the only open issue there is
> yours, you might want to file another wishlist item explaining in kind
> words why it would be a good idea. :-)

In case they want to keep binary size low, it could just be put behind a feature flag (I offered to do so, so I'll see what they say).
 
> Or, of course, you can still have some get-app-id-to-icon-map command...

That would be my last resort, let's hope swayipc can be extended to support this use case.

Bye,
Roland
Details
Message ID
<1422339781.333607.1669103022759@office.mailbox.org>
In-Reply-To
<359217966.135701.1668814868048@office.mailbox.org> (view parent)
DKIM signature
pass
Download raw message
Hi Tassilo,
 
> > I think the only way is to convince the swayipc author to make all the
> > IPC structs/enums derive Serialize
> 
> I created an Issue and PR, so hopefully they will add it.
> https://github.com/JayceFayne/swayipc-rs/pull/43

They merged it, and released swayipc_types 1.3.0 including the change: https://docs.rs/swayipc-types/1.3.0/swayipc_types/struct.Node.html#impl-Serialize-for-Node .

Bye,
Roland
Details
Message ID
<87r0xvfmwu.fsf@gnu.org>
In-Reply-To
<1422339781.333607.1669103022759@office.mailbox.org> (view parent)
DKIM signature
pass
Download raw message
dev@modprog.de writes:

Hi Roland,

>> I created an Issue and PR, so hopefully they will add it.
>> https://github.com/JayceFayne/swayipc-rs/pull/43
>
> They merged it, and released swayipc_types 1.3.0 including the change:
> https://docs.rs/swayipc-types/1.3.0/swayipc_types/struct.Node.html#impl-Serialize-for-Node

Great, I'll try to have a look at it at the weekend or so.

Bye,
Tassilo
Details
Message ID
<878rk0esww.fsf@gnu.org>
In-Reply-To
<87r0xvfmwu.fsf@gnu.org> (view parent)
DKIM signature
pass
Download raw message
Tassilo Horn <tsdh@gnu.org> writes:

Hi Roland,

>>> I created an Issue and PR, so hopefully they will add it.
>>> https://github.com/JayceFayne/swayipc-rs/pull/43
>>
>> They merged it, and released swayipc_types 1.3.0 including the change:
>> https://docs.rs/swayipc-types/1.3.0/swayipc_types/struct.Node.html#impl-Serialize-for-Node
>
> Great, I'll try to have a look at it at the weekend or so.

I just wanted to let you know that I've started working on that feature
and arrived "almost there" but then found out that currently there is no
way that the swayr daemon propagates back a message to the swayr client.
That's on my todo list anyhow (see https://todo.sr.ht/~tsdh/swayr/24).
It's no hard task but means that I have to implement that for each and
every existing command, so it might take some time.

Bye,
Tassilo
Details
Message ID
<8735a5fnqk.fsf@gnu.org>
In-Reply-To
<878rk0esww.fsf@gnu.org> (view parent)
DKIM signature
pass
Download raw message
Tassilo Horn <tsdh@gnu.org> writes:

Hi Roland,

> I just wanted to let you know that I've started working on that
> feature and arrived "almost there" but then found out that currently
> there is no way that the swayr daemon propagates back a message to the
> swayr client.  That's on my todo list anyhow (see
> https://todo.sr.ht/~tsdh/swayr/24).  It's no hard task but means that
> I have to implement that for each and every existing command, so it
> might take some time.

Oh, well, I just made the new get-windows-as-json command the first one
making use of that feature and released swayr-0.24.0-beta.0 with it.
Give it a try.

Bye,
Tassilo
Details
Message ID
<2103234941.668646.1669499615753@office.mailbox.org>
In-Reply-To
<8735a5fnqk.fsf@gnu.org> (view parent)
DKIM signature
pass
Download raw message
Hi Tassilo,

> Tassilo Horn <tsdh@gnu.org> writes:
> Oh, well, I just made the new get-windows-as-json command the first one
> making use of that feature and released swayr-0.24.0-beta.0 with it.
> Give it a try.
> 
> Bye,
> Tassilo

Just tried it, and AFAICT it works perfectly.

Thank you a lot!

Bye,
Roland
Reply to thread Export thread (mbox)