[sugar] current network differentiation?

2008-07-31 Thread pgf
is it intentional that the currently-connected network is no
longer differentiated in the neighborhood view?  the outer ring
of that network icon used to be white -- it no longer is.

it's been pointed out that you can see your current network on
the frame, but somehow that's not quite the same (to me).

i'm also not sure how to disconnect from that network -- there's no
"disconnect" option in the popup anymore.

i'll trac these if they're bugs -- but they might just be 
misunderstandings on my part.

paul
=-
 paul fox, [EMAIL PROTECTED]
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread Eben Eliason
On Thu, Jul 31, 2008 at 3:14 PM, <[EMAIL PROTECTED]> wrote:

> is it intentional that the currently-connected network is no
> longer differentiated in the neighborhood view?  the outer ring
> of that network icon used to be white -- it no longer is.
>

This is intentional.  The colors of the stroke/fill serve as the visual
representation of the identity of the network; changing them effectively
strips this identity.  The new design does not make any indication of which
network is presently associated in the Neighborhood view; perhaps we can
find an alternative method.  Thoughts?


> it's been pointed out that you can see your current network on
> the frame, but somehow that's not quite the same (to me).
>

Yes, that's the preferred model.  The Frame serves as a perpetual status
element, and is instantly accessible no matter "where" you are within the
UI.  I'm open to improvements on the model.

i'm also not sure how to disconnect from that network -- there's no
> "disconnect" option in the popup anymore.
>

Well, that's a "bug", but not really.  The problem is that there is no
notion of "disconnect" in network manager at all.  The old behavior used to
switch into mesh mode, which disassociated with the network itself.
 However, we now have a more direct means of accomplishing this, via turning
the mesh device on or off explicitly.  It doesn't make sense to compound
these.  The more conventional option is something like "turn wireless off"
to disassociate with the current network, but that assumes that there is no
other potential use for the wireless at all. In our case we still have the
mesh to worry about, so that again doesn't map onto our circumstances.

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread Martin Dengler
On Thu, Jul 31, 2008 at 03:23:47PM -0400, Eben Eliason wrote:
> The new design does not make any indication of which
> network is presently associated in the Neighborhood view; perhaps we can
> find an alternative method.  Thoughts?

Perhaps the currently-associated network's icon can appear below the
XO icon, as the Journal does initially in the Home view.

> i'm also not sure how to disconnect from that network -- there's no
> > "disconnect" option in the popup anymore.
> >
> 
> Well, that's a "bug", but not really.  The problem is that there is no
> notion of "disconnect" in network manager at all.

cjb suggested to me on IRC that Disconnect/Turn Off (for
wireless/mesh, respectively) could just cut power to the radio.  I
then suggested that this would work if the restoration of power was
quick enough that switching to the Neighborhood view could power back
on the radio and update the icons in some acceptable lag.

I have implemented[1] and tested this behavior (as part, but not a
necessary part, of #6995) and I believe it fast enough for further
investigation and testing.  The only problem is that it's very
cumbersome to bring back up the msh0 interface correctly, and would
require some code changes in a variety of places in sugar.

This problem (and it affects "Extreme power mode" too) is
recorded in #7690.

>  The old behavior used to
> switch into mesh mode, which disassociated with the network itself.

This is much less desirable than powering off the wireless, IMO.

>  However, we now have a more direct means of accomplishing this, via turning
> the mesh device on or off explicitly.

This is spec'd but subject to #7690, IIUC.

> - Eben

Martin


1. Some example entry points:

wlan_radio.py: 
http://dev.laptop.org/git?p=users/mdengler/sugar;a=blob;f=src/hardware/wlan_radio.py;h=47b70474fe503e90d74c4aecf5ed4cd1992f8412;hb=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80
MeshBox.py changes (last last diff block):
http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80


pgpmZMGKeb4xv.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread pgf
eben wrote:
 > On Thu, Jul 31, 2008 at 3:14 PM, <[EMAIL PROTECTED]> wrote:
 > 
 > > is it intentional that the currently-connected network is no
 > > longer differentiated in the neighborhood view?  the outer ring
 > > of that network icon used to be white -- it no longer is.
 > >
 > 
 > This is intentional.  The colors of the stroke/fill serve as the visual
 > representation of the identity of the network; changing them effectively
 > strips this identity.  The new design does not make any indication of which
 > network is presently associated in the Neighborhood view; perhaps we can
 > find an alternative method.  Thoughts?

i get the color thing, though those colors are all arbitrary,
right?  but i guess you can say "connect to the green/orange
network" as a means of identification, and if the ring is white,
you can't do that.  but it still feels like the connected network
should be "special" in that view.  maybe little radio waves
emanating from it or something.  :-)

 > 
 > > it's been pointed out that you can see your current network on
 > > the frame, but somehow that's not quite the same (to me).
 > >
 > 
 > Yes, that's the preferred model.  The Frame serves as a perpetual status
 > element, and is instantly accessible no matter "where" you are within the
 > UI.  I'm open to improvements on the model.

it wasn't until charlie came over and showed me the icon in the frame
that i'd had the frame up at all today.  but it's certainly a good place
to go for status information.

 > 
 > i'm also not sure how to disconnect from that network -- there's no
 > > "disconnect" option in the popup anymore.
 > >
 > 
 > Well, that's a "bug", but not really.  The problem is that there is no
 > notion of "disconnect" in network manager at all.  The old behavior used to
 > switch into mesh mode, which disassociated with the network itself.
 >  However, we now have a more direct means of accomplishing this, via turning
 > the mesh device on or off explicitly.  It doesn't make sense to compound

i'm not sure what you mean by "turning the mesh device on or off explicitly",
at least in terms of the current UI.  is that the Radio: checkbox in the
Network control panel?

 > these.  The more conventional option is something like "turn wireless off"
 > to disassociate with the current network, but that assumes that there is no
 > other potential use for the wireless at all. In our case we still have the
 > mesh to worry about, so that again doesn't map onto our circumstances.

i guess i'm thinking of it in traditional terms.  if i'm browsing
available nets, i might connect to a network by mistake, and want to
disconnect without necessarily connecting to something else, and now
it feels (rightly or wrongly) like i can't do that.  i guess it's not
very important, though.

paul

 > 
 > - Eben

=-
 paul fox, [EMAIL PROTECTED]
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread Eben Eliason
On Thu, Jul 31, 2008 at 3:42 PM, <[EMAIL PROTECTED]> wrote:

> eben wrote:
>  > On Thu, Jul 31, 2008 at 3:14 PM, <[EMAIL PROTECTED]> wrote:
>  >
>  > > is it intentional that the currently-connected network is no
>  > > longer differentiated in the neighborhood view?  the outer ring
>  > > of that network icon used to be white -- it no longer is.
>  > >
>  >
>  > This is intentional.  The colors of the stroke/fill serve as the visual
>  > representation of the identity of the network; changing them effectively
>  > strips this identity.  The new design does not make any indication of
> which
>  > network is presently associated in the Neighborhood view; perhaps we can
>  > find an alternative method.  Thoughts?
>
> i get the color thing, though those colors are all arbitrary,
> right?  but i guess you can say "connect to the green/orange
> network" as a means of identification, and if the ring is white,
> you can't do that.  but it still feels like the connected network
> should be "special" in that view.  maybe little radio waves
> emanating from it or something.  :-)
>

They're arbitrary, but the colors are chosen as a hash of the essid, which
makes them consistently arbitrary.  Your favorite network will always be the
same colors, and a given network will be the same colors on everyone's
machine.  It's just a hint of an identifier, but it's a lot better than
nothing.


>  >
>  > > it's been pointed out that you can see your current network on
>  > > the frame, but somehow that's not quite the same (to me).
>  > >
>  >
>  > Yes, that's the preferred model.  The Frame serves as a perpetual status
>  > element, and is instantly accessible no matter "where" you are within
> the
>  > UI.  I'm open to improvements on the model.
>
> it wasn't until charlie came over and showed me the icon in the frame
> that i'd had the frame up at all today.  but it's certainly a good place
> to go for status information.
>

I hope that the Frame will see much more use as a result of the redesign;
it's meant to be a crucial interface element, but until now hasn't had much
utility.  It will help when the notification system is integrated, since the
act of connecting to a network will invoke a pulsing network icon in the
corner of the screen, which will then slide into the Frame as a hint at
where to go to find it later.


>  >
>  > i'm also not sure how to disconnect from that network -- there's no
>  > > "disconnect" option in the popup anymore.
>  > >
>  >
>  > Well, that's a "bug", but not really.  The problem is that there is no
>  > notion of "disconnect" in network manager at all.  The old behavior used
> to
>  > switch into mesh mode, which disassociated with the network itself.
>  >  However, we now have a more direct means of accomplishing this, via
> turning
>  > the mesh device on or off explicitly.  It doesn't make sense to compound
>
> i'm not sure what you mean by "turning the mesh device on or off
> explicitly",
> at least in terms of the current UI.  is that the Radio: checkbox in the
> Network control panel?
>

There has been lots of confusion about the difference between mesh and APs.
 They're really not the same at all, apart from the fact that they both
depend on the radio.  The new design no longer treats the mesh channels as
objects in the Neighborhood view.  Instead, there will be (is? not sure if
the patch landed yet) a mesh device in the Frame, which you can turn on (and
off?) at whim.

 > these.  The more conventional option is something like "turn wireless
> off"
>  > to disassociate with the current network, but that assumes that there is
> no
>  > other potential use for the wireless at all. In our case we still have
> the
>  > mesh to worry about, so that again doesn't map onto our circumstances.
>
> i guess i'm thinking of it in traditional terms.  if i'm browsing
> available nets, i might connect to a network by mistake, and want to
> disconnect without necessarily connecting to something else, and now
> it feels (rightly or wrongly) like i can't do that.  i guess it's not
> very important, though.


I'm trying to point out that your assumption isn't actually true.  I'm not
aware of a "disconnect" option which strictly disconnects from the current
network.  Instead, there is usually a "turn off my ability to connect to any
network, disconnecting from the current one in the process" option.  This
isn't what we want, because one may want to disconnect from a network but
remain on the mesh.

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread Eben Eliason
On Thu, Jul 31, 2008 at 3:37 PM, Martin Dengler <[EMAIL PROTECTED]>wrote:

> On Thu, Jul 31, 2008 at 03:23:47PM -0400, Eben Eliason wrote:
> > The new design does not make any indication of which
> > network is presently associated in the Neighborhood view; perhaps we can
> > find an alternative method.  Thoughts?
>
> Perhaps the currently-associated network's icon can appear below the
> XO icon, as the Journal does initially in the Home view.
>

Could be tricky, since (hopefully soon) the view will be fixed so that the
current activity is beneath the XO, consistent with the Home view.  There
may be other options, though.


>
> > i'm also not sure how to disconnect from that network -- there's no
> > > "disconnect" option in the popup anymore.
> > >
> >
> > Well, that's a "bug", but not really.  The problem is that there is no
> > notion of "disconnect" in network manager at all.
>
> cjb suggested to me on IRC that Disconnect/Turn Off (for
> wireless/mesh, respectively) could just cut power to the radio.  I
> then suggested that this would work if the restoration of power was
> quick enough that switching to the Neighborhood view could power back
> on the radio and update the icons in some acceptable lag.


Again, I don't think this is really the desired semantic.  It's /almost/
right, and is the traditional means of achieving this, but that also turns
off the ability to be on the mesh, which isn't necessarily what one means by
"disconnect from this AP".  They should be independent.  I realize this
isn't as crucial right now, since we can't be on both mesh and AP at the
same time, but in the future it's pretty clear that they need to be
orthogonal.

I have implemented[1] and tested this behavior (as part, but not a
> necessary part, of #6995) and I believe it fast enough for further
> investigation and testing.  The only problem is that it's very
> cumbersome to bring back up the msh0 interface correctly, and would
> require some code changes in a variety of places in sugar.
>

Interesting.


>
> This problem (and it affects "Extreme power mode" too) is
> recorded in #7690.
>
> >  The old behavior used to
> > switch into mesh mode, which disassociated with the network itself.
>
> This is much less desirable than powering off the wireless, IMO.


I agree.  That's why there's no longer a disconnect option.  We thought it
was better to remove it until it has a proper semantic, rather than
implement it in a peculiar and not readily understandable way.

- Eben


> >  However, we now have a more direct means of accomplishing this, via
> turning
> > the mesh device on or off explicitly.
>
> This is spec'd but subject to #7690, IIUC.
>
> > - Eben
>
> Martin
>
>
> 1. Some example entry points:
>
> wlan_radio.py:
> http://dev.laptop.org/git?p=users/mdengler/sugar;a=blob;f=src/hardware/wlan_radio.py;h=47b70474fe503e90d74c4aecf5ed4cd1992f8412;hb=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80
> MeshBox.pychanges
>  (last last diff block):
>
> http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread Martin Dengler
On Thu, Jul 31, 2008 at 05:42:26PM -0400, Eben Eliason wrote:
> On Thu, Jul 31, 2008 at 3:37 PM, Martin Dengler <[EMAIL PROTECTED]>wrote:
> 
> > On Thu, Jul 31, 2008 at 03:23:47PM -0400, Eben Eliason wrote:
> > > The new design does not make any indication of which
> > > network is presently associated in the Neighborhood view; perhaps we can
> > > find an alternative method.  Thoughts?
> >
> > Perhaps the currently-associated network's icon can appear below the
> > XO icon, as the Journal does initially in the Home view.
> >
> 
> Could be tricky, since (hopefully soon) the view will be fixed so that the
> current activity is beneath the XO, consistent with the Home view.  There
> may be other options, though.

It could also be made bigger (for a while I kept patching my
MeshBox.py to make favorite icons bigger) than the others.  Or a
128/128/128 rgb ring could be drawn around it.

Well, you asked for ideas :).

> > cjb suggested to me on IRC that Disconnect/Turn Off (for
> > wireless/mesh, respectively) could just cut power to the radio.  I
> > then suggested that this would work if the restoration of power was
> > quick enough that switching to the Neighborhood view could power back
> > on the radio and update the icons in some acceptable lag.
> 
> 
> Again, I don't think this is really the desired semantic.  It's /almost/
> right, and is the traditional means of achieving this, but that also turns
> off the ability to be on the mesh, which isn't necessarily what one means by
> "disconnect from this AP".  They should be independent.  I realize this
> isn't as crucial right now, since we can't be on both mesh and AP at the
> same time, but in the future it's pretty clear that they need to be
> orthogonal.

I guess if they won't be independent for 8.1.2 it seems like it's
exactly the right thing to do - whether I'm on the mesh or the AP, if
I want to disconnect from the wireless and connect to the mesh I just
hit the mesh channel in the mesh palette, so if I select "disconnect"
I don't want to do that and thus have no use for the radio; and
if I disconnect from the mesh I definitely don't need an AP (if I did,
I would've chosen it).

We thought about just doing a NetworkManager sleep, but then, well,
again, what is the radio then good for barring drawing 1W of power :)?


> > This problem (and it affects "Extreme power mode" too) is
> > recorded in #7690.
> >
> > >  The old behavior used to
> > > switch into mesh mode, which disassociated with the network itself.
> >
> > This is much less desirable than powering off the wireless, IMO.
> 
> 
> I agree.  That's why there's no longer a disconnect option.  We thought it
> was better to remove it until it has a proper semantic, rather than
> implement it in a peculiar and not readily understandable way.

Again, "Disconnect" and "turn off" the wireless and mesh
(respectively) seem to have quite intuitive semantics (to those not
familiar with MPP usage): turn off the radio, since I don't want to
use what it's providing (wireless or mesh connectivity). 

> - Eben

Martin


pgpU69izE0xtJ.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread FFM
On Thu, Jul 31, 2008 at 11:13:23PM +0100, Martin Dengler wrote:
> Again, "Disconnect" and "turn off" the wireless and mesh
> (respectively) seem to have quite intuitive semantics (to those not
> familiar with MPP usage): turn off the radio, since I don't want to
> use what it's providing (wireless or mesh connectivity). 
> 
> Martin

That'll work as long as there isn't a noticable delay when visiting the network 
view (time between 
viewing and network survey)

-FFM
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] current network differentiation?

2008-07-31 Thread Martin Dengler
On Thu, Jul 31, 2008 at 06:26:52PM -0400, FFM wrote:
> On Thu, Jul 31, 2008 at 11:13:23PM +0100, Martin Dengler wrote:
>
> > [...] turn off the radio [...]
> 
> That'll work as long as there isn't a noticable delay when visiting the 
> network view (time between 
> viewing and network survey)

Exactly[1].  I believe it could easily be fast enough to detect APs,
but I'm not sure about joining a mesh (because I've never joined one
and I don't know how it feels vis-a-vis AP scanning - which is fast).

I believe (on vague memory) that NM only scans for APs every so often
(20s? 40s?), so even what we're showing people now might be a bit
inaccurate; in which case, to be sneaky[2], we could just leave all
the icons in the MeshBox as-is when we disconnect, and then the user
would see them all update one or so second later when the radio and NM
came back online.

Alternately, some UI could be introduced in the Mesh view (think like
the "Journal is empty" or "Journal shows no matching items") to
indicate that the radio was coming back online.

> -FFM

Martin



1. 
> On Thu, Jul 31, 2008 at 3:37 PM, Martin Dengler wrote: 
> I then suggested that this would work if the restoration of power
> was quick enough that switching to the Neighborhood view could power
> back on the radio and update the icons in some acceptable lag.



> ___
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar


pgpVDTVrE0J2u.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar