Repository navigation
Conversation
…matically powered on
|
This behavior isn't intentional, it is a bug. There's no need for an additional flag. |
|
As I'm digging into this I think I need to check with you on the intent. I'm learning all this stuff as I'm going, so feel free to let me know where I'm off base. There's the adapter (physical) and the device (logical). Both can be powered on and off with iwctl. If the adapter is powered off, the program exits with errors. If the device is powered off, the program can function fine. For lines 38-44 in src/app.rs: Is the intent to turn on the adapter (not the device) without prompting the user. This seems like what the intent was based on the with_context string and that the current iteration of the project needs the adapter to be powered on to function. If this is the case then we need to replace it with: and add a function to src/iw/adapters.rs to turn the adapter on: Also, throughout the project there seems to be a lot of references to enabling and disabling the adapter but it's actually dealing with powering the device on and off. If the idea is to give the user agency over the adapter power management (as well as powering on and off the device), then we'd need to add a power_off function and I think that brings us into modifying the menus and the code and strings to distinguish between the two. Let me know what you're thinking. Like I said, I'm learning as I'm going here so if my thought process is off just tell me. |
|
I've thought it through and decided to run with an approach. I'll open a PR when I'm done and we can discuss. |
|
The auto power on behavior is a remnant from early development when there were no different navigation modes, and many features were unimplemented. In default mode (non-interactive), powering off should exit, while powering on should lead to the current iwd mode menu (Station/AP). You're right about the device/adapter inconsistencies. The device-level control is correct for Since this required significant refactoring I've addressed it myself in recent commits. Feel free to check the changes if you're curious about the implementation, and to open other issues or PRs if you want to help improve the project. |
|
Hey, I took a look at your commits and we had similar thought processes. However, I wanted to make an attempt at implementing the adapter power on/off functionality into the project. I based it around your latest commits and submitted a new PR. We can discuss under that one. I hope you like the concept. |
Issue:
Currently, if the adapter device is powered off and iwmenu is launched, iwmenu automatically powers on the adapter device. However, since
current_modeis declared before theif !adapter.device.is_poweredconditional, the menu remains on the Power On Adapter menu becausecurrent_modedoesn't reflect that the adapter device is now powered on. So, if you press Esc and relaunch iwmenu it then launches to the main menu. This is unexpected behavior as the adapter device is being powered on and the menu is stating that it's not.Solution:
Re-sequence
let current_mode = adapter.device.mode;to be after theif !adapter.device.is_poweredconditional. This way, if the adapter device is powered off, when iwmenu is launched it powers on the adapter device and appropriately launches to the main menu.Follow-Up PR:
I'm submitting an additional pull request to add a --no-auto-power-on argument so the user can decide if they want the device to power on automatically when iwmenu is launched. I find the default behavior to be undesirable for my use case. If I want the adapter device to be powered off, I don't want iwmenu turning it on by default, forcing me to power off the adapter device each time if I launch iwmenu. Adding a --no-auto-power-on argument maintains the current behavior by default unless the user chooses otherwise.