Hooking to all the toggled signals from all the buttons for executing
the same action is inneficient, and can potenticall end up in a segmentation
fault due to some race in the signal emmission, where the active button
gets deactivated before the clicked button is activated
Looking at the GTK4 code, in a radio group:
- The button which was previously active gets de-activated, emitting its
corresponding toggled signal.
- The active property for the clicked button gets set.
- The clicked button emits its toggled signal.
Therefore, if the first toggle signal gets processed before the active
property is set, there can be a race condition. We are seeing this downstream
at pmOS: https://gitlab.com/postmarketOS/pmaports/-/issues/1816
Instead of this racy behavior, follow upstream recommendation and keep track
of the state through a stateful signal.
In 861d762ce5,
the address labels on the IPv4 page were renamed, however the corresponding
change was not made in the respective .ui file, which results in a crash upon
construction of the page. This change fixes that.
Boy this was hard.
To ease the pain of porting wireless-security to GTK4, add
a new WsFileChooserButton class that mimics the behavior of
a button that triggers a filechooser, as per the migration
guide suggests.
There were lots of GtkGrids, so the diff is particularly
horrendous. Sorry.
This needs serious testing before landing.
Introduce a new IP{4,6} config method to allow sharing the default
network (usually the Internet) through the wired interface.
This is needed because the control-panel is lacking this feature backed
by nm and currently the only way to enable the connection sharing is by
using nm-connection-editor.
According to the latest mockups for the connection editor dialog [1],
the IPv4 and IPv6 pages are supposed to use a table-like editor to
manage the addresses, in a similar fashion of what was done to the
routes editor. This way of editing is not only easier to comprehend,
but also improves the size of the dialog, requiring much less vertical
space to present the routes.
The current implementation, however, uses a vertical layout and a toolbar,
which is inefficient in its usage of space.
Fix that by implementing the table-like editor widget, both in IPv4
and IPv6 pages.
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/network/aday2/network-wires.pnghttps://bugzilla.gnome.org/show_bug.cgi?id=779841
According to the latest mockups for the connection editor dialog [1],
the IPv4 and IPv6 pages are supposed to use a table-like editor to
manage the routes. This editor is not only easier to comprehend, but
also improves the size of the dialog, requiring much less vertical
space to present the routes.
The current implementation, however, uses a vertical layout and a toolbar,
which is inefficient in its usage of space.
Fix that by implementing the table-like editor widget, both in IPv4
and IPv6 pages.
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/network/aday2/network-wires.pnghttps://bugzilla.gnome.org/show_bug.cgi?id=779841
This code is fairly independent of the rest, and we don't want
net-device-wifi.c to become too massive and unmaintainable.
The code in connection-editor/ is fairly similar to
nm-connection-editor, with some simplification because we
currently only edit wireless connections.
The code in wireless-security/ is almost a straight copy
of the same code in nm-connection-editor, with some changes
to the .ui files to make them fit better in the new design.
