Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid compilation warnings about deprecated call #359

Closed
wants to merge 3 commits into from

Conversation

milouse
Copy link
Contributor

@milouse milouse commented Jul 24, 2023

As of NetworkManager 1.22, a lot of function should be asynchronously called.

This MR remove all the compilation warning still visible (at least on Archlinux). Maybe it’s only preparatory stuff for Debian/Ubuntu distros.

Copy link
Member

@danirabbit danirabbit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey thanks for your branch! I left a few inline comments

src/Views/VPNPage.vala Outdated Show resolved Hide resolved
@@ -137,6 +137,9 @@ namespace Network.Widgets {
subtitle = _("Enabled (auto mode)");
status_image.icon_name = "user-available";
break;
default:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to make sure we're actually handling all the possible cases here rather than just ignoring a warning

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure what it is all about.

The Utils.CustomMode seems to contain unrelated things: the PROXY_* constants and 2 HOTSPOT_* constants. In the case of this switch_status function, it looks like being called only from 3 places:

None of these call are dealing with HOTSPOT_* related stuff.

That’s why I proposed to silently skip possibilities which should never occur. However a more robust/clean solution would be to remove the HOTSPOT_* constants from the CustomMode enum if we are not using them anymore? It looks like those constants have been forgotten in #176

And if we remove them from CustomMode, maybe we should rename this enum to ProxyMode?

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay yeah, that makes sense since hotspot is handled already we should remove those from CustomMode and I agree makes sense to rename this to ProxyMode

Comment on lines 177 to 187
/* Could be a lot of various status (for now, one of:
* `DISCONNECTED', `IP_CHECK', `CONFIG', `UNKNOWN',
* `UNAVAILABLE', `IP_CONFIG', `SECONDARIES', `UNMANAGED',
* `NEED_AUTH', `DEACTIVATING'). Showing the spinner might let
* end-user try to have a look to what is going on. */
spinner.active = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like we should handle this more carefully as well instead of just silencing the warning. It seems like a spinner isn't appropriate for states like "disconnected" or "unavailable" for example

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ll see what I can propose to better wrap all those cases.

@milouse
Copy link
Contributor Author

milouse commented Aug 7, 2023

Thank you very much for you review, I’ll check that!

Copy link
Member

@danirabbit danirabbit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey sorry it took me so long to follow up on this, I didn't see your replies for some reason 😓

@@ -137,6 +137,9 @@ namespace Network.Widgets {
subtitle = _("Enabled (auto mode)");
status_image.icon_name = "user-available";
break;
default:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay yeah, that makes sense since hotspot is handled already we should remove those from CustomMode and I agree makes sense to rename this to ProxyMode

@milouse
Copy link
Contributor Author

milouse commented Aug 30, 2023

Hey sorry it took me so long to follow up on this, I didn't see your replies for some reason 😓

No problem. I’ll change the code in this direction then.

We still have one last issue regarding various wifi state. I didn’t take time either to look for a better solution than just activating the spinner. If I don’t find more time or a working solution for now, I might just rollback my change and just insert a TODO for a better skilled person (I’m very poor when it comes to design/UX).

@milouse
Copy link
Contributor Author

milouse commented Aug 30, 2023

Ok, I just take time to do it now. I also work on missing NM.DeviceState. From my point of view it was finally not that hard. However I did introduce new translation terms, don’t know if you are ok with that or not.

@@ -158,20 +158,41 @@ public class Network.WifiMenuItem : Gtk.ListBoxRow {

hide_item (error_img);
spinner.active = false;

connect_button_revealer.reveal_child = true;
connect_button_revealer.reveal_child = false;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Connect button should be hidden by default (if we know there is a problem or the device is not usable, we should not let the user infinitely click on something broken).

case NM.DeviceState.UNAVAILABLE: // the device is managed by NetworkManager, but is not available for use
case NM.DeviceState.UNMANAGED: // the device is recognized, but not managed by NetworkManager
case NM.DeviceState.FAILED: // the device failed to connect to the requested network and is cleaning up the connection request
case NM.DeviceState.SECONDARIES: // the device is waiting for a secondary connection (like a VPN) which must activated before the device can be activated
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All those states reflect a locked/failed state

show_item (error_img);
state_string = _("Could not be connected to");
break;
case NM.DeviceState.PREPARE:
case NM.DeviceState.NEED_AUTH: // the device requires more information to continue connecting to the requested network
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is also a failed state, but the resolution is quite different: we leave the connect button as a possibility for the end-user to be shown again a log in popup. I also introduce a new translation term to explain what is wrong.

case NM.DeviceState.CONFIG: // the device is connecting to the requested network
case NM.DeviceState.IP_CONFIG: // the device is requesting IPv4 and/or IPv6 addresses and routing information from the network
case NM.DeviceState.IP_CHECK: // the device is checking whether further action is required for the requested network connection
case NM.DeviceState.PREPARE: // the device is preparing the connection to the network
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All those states reflect an ongoing connection, thus I put them together.

connect_button_revealer.reveal_child = true;
break;
case NM.DeviceState.ACTIVATED: // the device has a network connection, either local or global
// Nothing to do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Activated is now the default state. Nothing to do as hidding the connect button is now the default behavior.

I introduced new steps as:

  • deactivating: the same as the "prepare" step, but in reverse, when the device is disconnecting. Thus it also trigger the spinner. I also added the new translation term "Disconnecting" as a reverse for "Connecting".
  • disconnected: this is a default "nothing to do" state, when the device is just disconnected, without any issue ongoing. As we hide the connect button by default, this case is used to show it. Finally I plug the "unknown" state to it instead of the first "error" state as unknown can be for a lot of other reason, not necessarily an error. Let see in the futur if it would be better plugged to an error state.

}
case Utils.ProxyMode.INVALID:
subtitle = _("Disabled (error)");
status_image.icon_name = "user-busy";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use the "user-busy" icon to display the error, as for the failed DeviceState on line 117 above in order to be coherent.

@milouse
Copy link
Contributor Author

milouse commented Nov 2, 2023

Rebased on last master.

@danirabbit
Copy link
Member

Hey sorry for not reviewing promptly. This has been hard to review because it changes several unrelated things that all have to be reviewed separately. It's much better to propose separate branches with unrelated changes.

Copy link
Member

@danirabbit danirabbit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you revert the changes in WifiMenuItem and propose that separately? That doesn't seem related to resolving the deprecation warnings with NM

@milouse
Copy link
Contributor Author

milouse commented Feb 23, 2024

Hi, and verry sorry for the long silence.

I just rebased the branch on the last main state, updating it for gtk4 port.

Can you revert the changes in WifiMenuItem and propose that separately? That doesn't seem related to resolving the deprecation warnings with NM

Actually my changes there were to address a warning about missing states in the switch/case statement, thus for me it’s still related to the topic of this MR (removing as much warning as possible). However I can understand you prefer to separate each fix step. Can you confirm your prefer 3 different MR?

@danirabbit
Copy link
Member

@milouse Yes please 3 separate pull requests would make a lot more sense here. The change to use async methods I can easily approve and merge immediately but the changes to the proxy enum I think might need some further investigation and the changes to the wifitem definitely needs a completely separate review as well

@milouse
Copy link
Contributor Author

milouse commented Oct 16, 2024

Hi, and sorry I’m not using elementary any more, thus I lose interest in the matter. I wish you all the best, and thanks for all the fish!

@milouse milouse closed this Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants