if the Sugar control panel is open, then Frame icons are inoperable

[skierpage]

In Sugar 0.82.1 on XO-1 running candidate-800 (almost 8.2.1), I pressed the Frame key and tried to close some running activities. But the icons in the frame didn't highlight and were inoperable.

I finally realized that I had brought up the Sugar control panel in Home view, and then switched between activities using Alt+Tab. Once I closed the Sugar control panel, the Frame worked as expected.

Opening the Sugar control panel prevents the mouse corners from activating the frame in all activities and views. But you can still view and hide the Frame by pressing the frame key in any activity or Neighborhood/Group/Home view. The Frame looks usable but isn't.

I don't know what the right fix is. I often bring up the Sugar control panel to check some setting or my version, so it's nice to Alt+Tab to another activity while it's up. Maybe draw the frame background in Sugar's "disabled" or "inoperable" color when it's inactive.

[erikos]

Thanks for this observation. This is still true today. Lets see if we can do something about it for 0.84

[tomeu]

I think the actual bug is that you can go away from a modal alert like the control panel. Once you get into such a modal window, you shouldn't be able to interact with other screens.

[garycmartin]

Replying to tomeu:

I think the actual bug is that you can go away from a modal alert like the control panel. Once you get into such a modal window, you shouldn't be able to interact with other screens.

If so, then I think this bug may be my fault :-) I lobbied that folks making control panel changes would very likely need access to other information. Classic case would be trying to enter a new jabber server address and needing to refer to some wiki page in Browse. Or when reporting bugs where the first thing you need is the information in "About my XO" so you can report the various OFW, distro builds, Sugar version details. Or just reading a help document and going through the CP options available.

OT: I must admit I'm not a fan of the current CP modal presentation and side effects, and was disappointed that the new naming dialogue copied the style (I was hoping for an alert style naming dialogue, alerts seem a much better UI interaction).

[tomeu]

Replying to garycmartin:

Replying to tomeu:

I think the actual bug is that you can go away from a modal alert like the control panel. Once you get into such a modal window, you shouldn't be able to interact with other screens.

If so, then I think this bug may be my fault :-) I lobbied that folks making control panel changes would very likely need access to other information. Classic case would be trying to enter a new jabber server address and needing to refer to some wiki page in Browse. Or when reporting bugs where the first thing you need is the information in "About my XO" so you can report the various OFW, distro builds, Sugar version details. Or just reading a help document and going through the CP options available.

Yes, I see this general issue with modal UIs, they suck because they are modal but we resort to them because they are... modal.

If we were able to provide this functionality without a modal dialog, then we should totally do in that way because modal dialogs are evil. But the problem is that we sometimes fail to provide a non-modal way to do stuff.

So every time that someone sees a discussion about making something modal, please comment and try to help finding a non-modal solution (and implementing it). One example is the wireless key dialog. We know since a long time that the key should be entered in the palette of the access point instead of opening a dialog, but nobody has gotten to do it yet.

Maybe other stuff can be moved from the control panel to other places in the UI, not sure.

OT: I must admit I'm not a fan of the current CP modal presentation and side effects, and was disappointed that the new naming dialogue copied the style (I was hoping for an alert style naming dialogue, alerts seem a much better UI interaction).

You mean an inline alert? That sounds cool though don't know how we can put there all we want to. Care to do a mockup? This is something that I think can be changed for 0.86 without too big a disruption on users.

[garycmartin]

Replying to tomeu:

Replying to garycmartin:

Replying to tomeu:

I think the actual bug is that you can go away from a modal alert like the control panel. Once you get into such a modal window, you shouldn't be able to interact with other screens.

If so, then I think this bug may be my fault :-) I lobbied that folks making control panel changes would very likely need access to other information. Classic case would be trying to enter a new jabber server address and needing to refer to some wiki page in Browse. Or when reporting bugs where the first thing you need is the information in "About my XO" so you can report the various OFW, distro builds, Sugar version details. Or just reading a help document and going through the CP options available.

Yes, I see this general issue with modal UIs, they suck because they are modal but we resort to them because they are... modal.

If we were able to provide this functionality without a modal dialog, then we should totally do in that way because modal dialogs are evil. But the problem is that we sometimes fail to provide a non-modal way to do stuff.

Well modal is not all bad and evil, only when it blocks on things that have no need to be blocked on. In other OS, a document save dialogue is quite sensible to block edits to the document being saved, but should not block access to other open documents. The issue with the Sugar CP is that it blocks on the various neighboorhood/group/home zoom views for no reason, and causes misc. frame UI bugs.

So every time that someone sees a discussion about making something modal, please comment and try to help finding a non-modal solution

Agreed, none of these issues would exists if the CP had been written as a built-in Activity as it was first discussed, just like the Journal is, it could inherit special privileges as Terminal and Journal do already. The pretty mock-ups with a 50% black transparent border were (I think) an attempt to show that the CP was 'above' everything else (mental model)... and from that point on, actual usability fell out the window, and new issues due to the need for non-standard/custom implementation appeared (more maintenance, more bugs).

(and implementing it).

Well yes, and there's the rub – consider me as waiting in the wings for picking up *some* core tasks (remembering I can only test Sugar work on XOs), but we need fresh blood, and not just try to water down the old congealing stuff ;-)

One example is the wireless key dialog. We know since a long time that the key should be entered in the palette of the access point instead of opening a dialog, but nobody has gotten to do it yet.

Maybe other stuff can be moved from the control panel to other places in the UI, not sure.

OT: I must admit I'm not a fan of the current CP modal presentation and side effects, and was disappointed that the new naming dialogue copied the style (I was hoping for an alert style naming dialogue, alerts seem a much better UI interaction).

You mean an inline alert? That sounds cool though don't know how we can put there all we want to. Care to do a mockup? This is something that I think can be changed for 0.86 without too big a disruption on users.

Mockup, yes, very happy too (was planning to already to get feedback on the idea).

[tomeu]

Replying to garycmartin:

Replying to tomeu:

Replying to garycmartin:

Replying to tomeu:

I think the actual bug is that you can go away from a modal alert like the control panel. Once you get into such a modal window, you shouldn't be able to interact with other screens.

If so, then I think this bug may be my fault :-) I lobbied that folks making control panel changes would very likely need access to other information. Classic case would be trying to enter a new jabber server address and needing to refer to some wiki page in Browse. Or when reporting bugs where the first thing you need is the information in "About my XO" so you can report the various OFW, distro builds, Sugar version details. Or just reading a help document and going through the CP options available.

Yes, I see this general issue with modal UIs, they suck because they are modal but we resort to them because they are... modal.

If we were able to provide this functionality without a modal dialog, then we should totally do in that way because modal dialogs are evil. But the problem is that we sometimes fail to provide a non-modal way to do stuff.

Well modal is not all bad and evil, only when it blocks on things that have no need to be blocked on.

Sure, what I tried to say is that when we resort to modal is because we haven't found a way to expose that functionality without needing to block something else. Of course, whether we actually needed to block or not is subject to opinions.

Power users will say we shouldn't block anything because they want to be always in control and trust themselves not to forget an open dialog in some other view or believe to know all the possible interactions between other parts of the UI and the dialog.

But for not-so-power-users, the inconvenience of having to close the dialog before doing other stuff may not outweigh the simplicity of not having to track obscured dialogs or having to know how the control panel options interact with the shell components.

In other OS, a document save dialogue is quite sensible to block edits to the document being saved, but should not block access to other open documents. The issue with the Sugar CP is that it blocks on the various neighboorhood/group/home zoom views for no reason, and causes misc. frame UI bugs.

Well, it doesn't causes bugs. The bugs were caused by buggy programmers (us!).

And if we made it modal is because we thought we had a reason, that as I said above is likely to be quite subject to opinions.

So every time that someone sees a discussion about making something modal, please comment and try to help finding a non-modal solution

Agreed, none of these issues would exists if the CP had been written as a built-in Activity as it was first discussed, just like the Journal is, it could inherit special privileges as Terminal and Journal do already.

I don't really see what a control panel has to do with the concept of activity, other than being a fullscreen window managed from the switcher in the frame. That's one reason for it not being an activity.

The pretty mock-ups with a 50% black transparent border were (I think) an attempt to show that the CP was 'above' everything else (mental model)... and from that point on, actual usability fell out the window, and new issues due to the need for non-standard/custom implementation appeared (more maintenance, more bugs).

I think the point was more to let the user see that the modal dialog is a deviation of the normal (multitask) workflow. Something like an exception.

(and implementing it).

Well yes, and there's the rub – consider me as waiting in the wings for picking up *some* core tasks (remembering I can only test Sugar work on XOs), but we need fresh blood, and not just try to water down the old congealing stuff ;-)

Sure. My personal opinion is for Sugar to be successful, its development needs to be guided by its actual users. So if a new-blooder wants to do something that old-blooders don't like, but gets the support from the SL community members that are involved in deployments, then the young-blooder will win.

One example is the wireless key dialog. We know since a long time that the key should be entered in the palette of the access point instead of opening a dialog, but nobody has gotten to do it yet.

Maybe other stuff can be moved from the control panel to other places in the UI, not sure.

OT: I must admit I'm not a fan of the current CP modal presentation and side effects, and was disappointed that the new naming dialogue copied the style (I was hoping for an alert style naming dialogue, alerts seem a much better UI interaction).

You mean an inline alert? That sounds cool though don't know how we can put there all we want to. Care to do a mockup? This is something that I think can be changed for 0.86 without too big a disruption on users.

Mockup, yes, very happy too (was planning to already to get feedback on the idea).

Awesome, thanks!

[homunq]

Um... can someone remind me exactly why it is important for the control panel to be globally modal? If you're halfway through an unsaved global properties change, it hasn't happened yet - I don't see where that's more than a minor nuisance to any user.

Specifically, on first-boot, you are prompted to go to the activities update panel - but you're not connected yet, so it is useless. Personally, I'd want the control panel to be much *less* modal, so you can see the network view and connect to an AP.

My vote, for now, would be to make it a totally non-modal dialog, which nevertheless sits "in front" of the home view.

[garycmartin]

Replying to homunq:

Personally, I'd want the control panel to be much *less* modal, so you can see the network view and connect to an AP.

+1

My vote, for now, would be to make it a totally non-modal dialog, which nevertheless sits "in front" of the home view.

FWIW: I don't get the impression it was intentionally designed this way, it is just the implementation that fell out of the tree in the given time allocated. The "floats over neighbourhood/group/home" is because these 3 views are implemented in the place a traditional desktop UI would be put, they are just draw in that root window as needed. So along came the CP, and given there is/was no composition layering magic to really make a modal window float above *ALL* views with a transparent/dim edge area as per the original mock-up -- think how bad a UI design that would have been -- it was made a model of that traditional desktop layer, blocking you from seeing most of the 3 core UI views.

Maybe something can be considered for 0.86?

[homunq]

OK, a big fix for 0.86. Sure. But this bug (inoperable Frame) needs fixing NOW, so we need consensus. Are there any reasons we *shouldn't* just make the dialog nonmodal? (It would still get in the way, but at least the frame would work.)

[FGrose]

Please also consider adding a method to view the source for the Sugar control panel/My Settings. That way, Learners can see how things are controlled, and may begin to try alternatives, add new features, and maybe solve the next problem!

[garycmartin]

Control panel still causing Frame buttons to be inoperable, moving to 0.86 but don't think there's been any consensus yet for the right way to try and fix.

[alsroot]

The fast hack(since we are in freeze and this problem could be really confusing) for 0.86 could be just preventing changing zoom level from shell if non-desktop window is active.

[tomeu]

r+, but we need to test this really well or we risk losing major functionality (as in the desktop being rendered unusable).

For 0.88 we could make the dialog a fullscreen window that renders a dimmed border in the frame-space. That would make clearer that once you are in a modal dialog you cannot interact with anything else.

We should also remove the wireless dialog and move that to a palette or similar.

[alsroot]

0.86 fix
 http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/9406c42ed10a149d31e06a8db06806463d6f18c8

[tomeu]

I think this isn't a blocker any more.