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

Adhoc enhacements try2 #375

Closed
wants to merge 2 commits into from
Closed

Conversation

tchx84
Copy link
Member

@tchx84 tchx84 commented May 7, 2014

These are two patches I made to ad-hoc networks autoconnect behaviour.

The first change, simplifies the autoconnect logic, from a "connect to the first available network you find, or connect to 1 otherwise" to a "connect to the last network you used during this session, or connect to 1 otherwise". This change was made as a requirement from Australia deployment, as the previous behavior seemed too unpredictable for users.

The second change allow us to disable Ad-hoc auto-connect using a gsettings value. Auto-connect option will be enabled by default. When disabled, Sugar will no longer auto-connect until the user explicitly connects to an Ad-hoc network (this is to cover suspend/resume scenarios). When the user explicitly disconnects from the Ad-hoc network, auto-connect will be disabled again.

tchx84 added 2 commits May 7, 2014 14:21
Set _last_channel so it will re-connect to the last
ad-hoc network it was connected before, during the same
sugar session.

Unset _last_channel when the user explicitly disconnects
from the ad-hoc network, so it will forget about the last
network it was connected during the same sugar session.

Signed-off-by: Martin Abente Lahaye <tch@sugarlabs.org>
Add a gconf value to determine whether or not ad-hoc networks
should autoconnect.

This gconf value will be ignored if the user explicitly connects
to a ad-hoc network, for the rest of the session. It will be taken
into account again, if the user explicitly disconnect from the
ad-hoc network.

Signed-off-by: Martin Abente Lahaye <tch@sugarlabs.org>
@tchx84
Copy link
Member Author

tchx84 commented May 7, 2014

@manuq think this requires design discussion? @dnarvaez would it be too late for this stage of our release?

@dnarvaez
Copy link
Contributor

dnarvaez commented May 7, 2014

The first patch sounds fine from a release management perspective. It's more of a bugfix.

The second one breaks string freeze and probably feature freeze too. I think it would need to be discussed and approved also by the localization team.

@tchx84
Copy link
Member Author

tchx84 commented May 8, 2014

Fair enough, I will separate both patches in different PR as both have different requirements for their inclusion.

@tchx84 tchx84 closed this May 8, 2014
@tchx84
Copy link
Member Author

tchx84 commented May 8, 2014

I have sent a separate PR for the first change, #376

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.

None yet

2 participants