-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Conversation
There was a problem hiding this 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/Widgets/DeviceItem.vala
Outdated
@@ -137,6 +137,9 @@ namespace Network.Widgets { | |||
subtitle = _("Enabled (auto mode)"); | |||
status_image.icon_name = "user-available"; | |||
break; | |||
default: |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
src/Widgets/WifiMenuItem.vala
Outdated
/* 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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Thank you very much for you review, I’ll check that! |
9e2078a
to
c4dd7ff
Compare
There was a problem hiding this 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 😓
src/Widgets/DeviceItem.vala
Outdated
@@ -137,6 +137,9 @@ namespace Network.Widgets { | |||
subtitle = _("Enabled (auto mode)"); | |||
status_image.icon_name = "user-available"; | |||
break; | |||
default: |
There was a problem hiding this comment.
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
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). |
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. |
2c4b0b3
to
88caa01
Compare
@@ -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; |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
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.
88caa01
to
c44a288
Compare
c44a288
to
fca5cc1
Compare
Rebased on last master. |
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. |
There was a problem hiding this 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
33ca7f9
to
a9a6aec
Compare
Hi, and verry sorry for the long silence. I just rebased the branch on the last main state, updating it for gtk4 port.
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? |
@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 |
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! |
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.