Language widget for panel #301

WShad · 2025-07-19T21:31:45Z

Adds language widget displaying current keyboard layout language.

WShad · 2025-07-29T22:27:13Z

Implemented IPC-client + language widget based on it

WShad · 2025-08-01T07:21:27Z

NamorNiradnug · 2025-08-01T12:22:15Z

Hi! I haven't checked the PR carefully yet but I suppose it should use yyjson instead of nlohmann_json because wayfire uses the former. Could you please fix that?

UPD: also please fix the formatting.

NamorNiradnug · 2025-08-01T12:38:39Z

src/util/wf-shell-app.hpp

    int inotify_css_fd;
    wf::config::config_manager_t config;
    zwf_shell_manager_v2 *wf_shell_manager = nullptr;
+    WayfireIPC *ipc = nullptr;


I would suggest making WayfireIPC a singleton so that it won't be initialized until needed.

I usually do it like this:

WayfireIPC doesn't have a public ctor

has private static std::weak_ptr<WayfireIPC> instance_

has public static std::shared_ptr<WayfireIPC> Instance() which simply returns instance_.lock()

has public static std::shared_ptr<WayfireIPC> Open() (or something, maybe you will come up with a better name) which initialize the instance_ if it's expired

Instance() should be called in reload_widgets so that we don't close-and-open the socket on every reload.

Probably Lock() would be a better name for Instance(), but I would still call it Instance for consistency with existing singletons.

See https://github.com/WayfireWM/wf-shell/blob/master/src/panel/widgets/tray/watcher.hpp#L18-L31 and https://github.com/WayfireWM/wf-shell/blob/master/src/panel/panel.cpp#L268.

NamorNiradnug · 2025-08-01T12:56:11Z

src/util/wf-ipc.hpp

+
+class WayfireIPC
+{
+        int socket_fd;


Have you considered using Gio's SocketClient instead of handling it manually? I believe it would simplify the code.

ammen99 · 2025-11-04T11:27:01Z

@WShad sorry for the delay, we were finishing the gtk4 port .. if you still have interest, please update this PR to gtk4 as well.

ammen99 · 2025-11-14T12:09:00Z

@WShad thanks for your updates! I looked briefly over your PR, a few things that stood out to me:

uncrustify.ini was copied from Wayfire's repo, but I don't think we use it here? So it shouldnt' be added
You have copied the yyjson wrapper from Wayfire. I find it ok to use either nlohmann/json or yyjson here, though I suppose yyjson makes us closer to Wayfire. In any case, if we are going to use wrapped yyjson like wayfire, we shouldn't duplicate the code. If you want I can make a new repo here where we can put the json wrapper and then we can share it between wayfire and wf-shell as a subproject.

WShad · 2025-11-14T12:46:31Z

Wow! Thanks for so fast feedback!)))

Removed
As you say. Lead me, plz)

ammen99 · 2025-11-14T12:52:02Z

I will separate wayfire's json handling into a subproject and will let you know when it is ready for incorporating into your pr :)

ammen99 · 2025-11-14T13:10:20Z

@WShad It was actually easier than I expected, here is the json wrapper itself: https://github.com/WayfireWM/wf-json

Here is the Wayfire PR where it is used WayfireWM/wayfire#2892
You can add it as a subproject to wf-shell as well and then you get the json wrapper header automatically. The rest of the IPC handling is glib-specific so maybe best to keep it here in wf-shell.

ammen99 · 2025-11-14T13:14:04Z

src/panel/widgets/language.cpp

+    button.show();
+
+    ipc->subscribe(this, {"keyboard-modifier-state-changed"});
+    ipc->send("{\"method\":\"wayfire/get-keyboard-state\"}", [=] (json_t data)


I find your design very interesting with this send and the callback for the response. One thing I am not very sure about however is this, what deregisters the callback if the WayfireLanguage class is destroyed while waiting for the reply?

I find your design very interesting with this send and the callback for the response

Thanks! I'm glad to hear that)

what deregisters the callback if the WayfireLanguage class is destroyed while waiting for the reply?

Nice point. Didn't think about it.

One idea would be to somehow connect the full ipc->send() version with the IPC subscriber interface, then have the IPC subscriber interface deregister itself from the IPC socket automatically. This is what we do for signals in Wayfire itself. Maybe the implementation will give you some inspirations, but feel free to come up with a different idea if you have a better one :)

https://github.com/WayfireWM/wayfire/blob/master/src/api/wayfire/signal-provider.hpp
https://github.com/WayfireWM/wayfire/blob/8a3e1cae5beda079060d7c5725812bdc589a6ae3/src/core/object.cpp#L7-L59

Resolved. Now widgets must have their own IPC clients, they deregister themselves and all replies to that clients will be safely ignored.

src/util/wf-ipc.cpp

ammen99

getting closer to perfection :) a few smaller items that i noticed, otherwise lgtm

ammen99 · 2025-11-25T09:56:27Z

src/util/wf-ipc.cpp

+WayfireIPC::~WayfireIPC()
+{
+    disconnect();
+    LOGI("IPC destroyed");


i don't think we need this message in 'production' :)

Disagree, but - ok

ammen99 · 2025-11-25T09:58:38Z

src/util/wf-ipc.cpp

+
+        while (connection->get_socket()->get_available_bytes() > 0)
+        {
+            received = input->read(&length, 4);


I prefer to have length as a local variable, it is not some 'state' which needs to be preserved across method calls.

Also instead of 4, consider using sizeof(length), that way I think it is way clearer why we read those bytes separately :)

I prefer to have length as a local variable, it is not some 'state' which needs to be preserved across method calls.

Will fix. Legacy of prev impl)

ammen99 · 2025-11-25T09:59:34Z

src/util/wf-ipc.cpp

+            received = input->read(&length, 4);
+            if (received == -1)
+            {
+                LOGE("Receive message length failed");


when we log errors, it would make sense to also indicate where they are coming from, for example: "Error in Wayfire IPC communication: failed to receive message length"

(also applies to all the other LOGE calls in this file / PR

ammen99 · 2025-11-25T10:11:12Z

src/util/wf-ipc.cpp

+
+        while (connection->get_socket()->get_available_bytes() > 0)
+        {
+            received = input->read(&length, 4);


Another thing: when calling read(), I we are not guaranteed to get the full number of bytes we request. In particular, if we have a longer ipc message, I think read could stop in the middle, return just some part of the message. At least the underlying read() syscall works this way. Example of what Wayfire does to combat this: https://github.com/WayfireWM/wayfire/blob/9c427024e849b0c676184c1af3c82b38f1f8fb67/plugins/ipc/ipc.cpp#L171-L285

Can't actually confirm that. I experimented a lot and this is a results:

under the pressure of data socket can get buffer overflow, if not read frequent enough

if n bites written - n bites can be read (not like in a tcp connection)

if server lags on read or write - client disconnected immediately

Can't reproduce situation where was read less than was written.
Using this IPC for three months, fixed some bugs, have no problems.

under the pressure of data socket can get buffer overflow, if not read frequent enough

That's exactly the issue! It can be that the buffer can only accommodate the message partially.

I mean in practice I expect this to not cause any issues, so maybe we could simply leave this as a TODO comment in the code and fix it when somebody actually complains.

In any case would be good to at least check what is going on, so instead of errorring on n_bytes_read == 0, we need to error on n_bytes_read != n_bytes_wanted

ammen99 · 2025-11-29T10:04:41Z

@WShad For the CI to work, I think you need to add cmake to the list of dependencies, or to install yyjson as a dependency so that we don't have to build it as a submodule. Also you'll need to fix the codestyle. Otherwise LGTM, good work!

WShad · 2025-12-07T21:20:18Z

Clean now: https://github.com/WShad/wf-shell/actions/runs/20010484337

WShad · 2025-12-07T21:25:22Z

I don't understand... How? My action completed successfully, they are the same - how it even can be?

ammen99 · 2025-12-08T09:13:28Z

@WShad I also find it hard to comprehend why it works on the one CI and not on the other, but my guess would be that you add the json submodule as a dependency only to the util static library. But it should also be a dependency of the panel itself (because it needs the json include headers). To solve such issues, we have a dependency object which includes all the necessary stuff, you can add json as a dependency to it as well:

wf-shell/src/util/meson.build

Line 14 in 57a68cb

    
           libutil = declare_dependency(link_with: util, include_directories: util_includes)

I believe this will fix the CI issue.

A note on uncrustify: we use a custom uncrustify to be consistent with Wayfire. Wayfire itself uses a custom uncrustify because uncrustify-git currently crashesh on Wayfire's codebase, plus it had some formatting bugs which I fixed in my fork ... At least however, the CI will give you a patch to apply so you don't have to set it up locally, see https://github.com/WayfireWM/wf-shell/actions/runs/20010484621/job/57379300256?pr=301#step:9:1

WShad · 2025-12-08T10:09:19Z

my guess would be that you add the json submodule as a dependency only to the util static library. But it should also be a dependency of the panel itself (because it needs the json include headers)

Exactly! And why i lost that dependency(?) - it compiles locally just fine, without explicitly included 'json'. Strange...

A note on uncrustify

Got it

Will compile now.

ammen99

LGTM now, thanks a lot!

birdie-github · 2025-12-15T16:21:17Z

Does it support a language emoji? If not, would be very nice to have along with an option to either show:

text only (EN)
text and language emoji (EN 🇬🇧)
just language emoji (🇬🇧)

feat: language widget implementation

e7411ab

WShad mentioned this pull request Jul 19, 2025

WF shell protocol: keyboard lang manager implementation WayfireWM/wayfire#2742

Closed

WShad marked this pull request as ready for review July 19, 2025 21:33

WShad added 5 commits July 20, 2025 02:19

chore: shell manager method name fix

496f77f

chore: fix misspell

53e0f53

feat: IPC, language widget on IPC

2f1113e

chore: discard wf-shell proto changes

219248f

refactor: removed shared ptr

5ae10f7

WShad added 2 commits July 30, 2025 01:31

chore: include removed

5d61aaa

fix: IPC message data

505f466

fix: recv interrupt, retry

2bccb62

NamorNiradnug reviewed Aug 1, 2025

View reviewed changes

ammen99 mentioned this pull request Nov 4, 2025

Visual workspaces plugin #123

Open

WShad added 2 commits November 14, 2025 14:34

GLIBed IPC + shared manager,, yyjson

9e97c5c

Merge branch 'master' into language_widget

bf689c2

WShad added 2 commits November 14, 2025 15:41

fix: update to GTK4, deps

3b9aeef

remove uncrustify

c366289

ammen99 reviewed Nov 14, 2025

View reviewed changes

WShad added 3 commits November 15, 2025 10:19

migrate to wf-json

bf6e25d

IPC rework

0f63bef

Merge branch 'master' into language_widget

9844e36

ammen99 requested changes Nov 25, 2025

View reviewed changes

fix: graceful IPC shutdown, logs

adeac00

WShad added 5 commits December 7, 2025 21:53

chore: code-style

3857365

CI: yyjson

3574e12

chore: more code-style

6fea5d2

chore: clean-up

43ec9d2

chore: different uncrustify??

b2c8eaf

fix: deps, paths, enums

6dbfa79

ammen99 approved these changes Dec 8, 2025

View reviewed changes

ammen99 merged commit d935c4b into WayfireWM:master Dec 8, 2025
2 checks passed

Language widget for panel #301

Language widget for panel #301

Uh oh!

Conversation

WShad commented Jul 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WShad commented Jul 29, 2025

Uh oh!

WShad commented Aug 1, 2025

Uh oh!

NamorNiradnug commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NamorNiradnug Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NamorNiradnug Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ammen99 commented Nov 4, 2025

Uh oh!

ammen99 commented Nov 14, 2025

Uh oh!

WShad commented Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ammen99 commented Nov 14, 2025

Uh oh!

ammen99 commented Nov 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WShad Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ammen99 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ammen99 Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WShad Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ammen99 commented Nov 29, 2025

Uh oh!

WShad commented Dec 7, 2025

Uh oh!

WShad commented Dec 7, 2025

Uh oh!

ammen99 commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

WShad commented Jul 19, 2025 •

edited

Loading

NamorNiradnug commented Aug 1, 2025 •

edited

Loading

NamorNiradnug Aug 1, 2025 •

edited

Loading

NamorNiradnug Aug 1, 2025 •

edited

Loading

WShad commented Nov 14, 2025 •

edited

Loading

WShad Nov 14, 2025 •

edited

Loading

ammen99 Nov 25, 2025 •

edited

Loading

WShad Nov 25, 2025 •

edited

Loading

ammen99 commented Dec 8, 2025 •

edited

Loading