[Bugs] #453 UNSP: if the Sugar control panel is open, then Frame icons are inoperable

[SugarLabs Bugs]

#453: if the Sugar control panel  is open, then Frame icons are inoperable
------------------------------------------+---------------------------------
    Reporter:  skierpage                  |          Owner:  erikos  
        Type:  defect                     |         Status:  assigned
    Priority:  Unspecified by Maintainer  |      Milestone:  0.84    
   Component:  sugar                      |        Version:  0.83.x  
    Severity:  Major                      |     Resolution:          
    Keywords:                             |   Distribution:  OLPC    
Status_field:  Assigned                   |  
------------------------------------------+---------------------------------

Comment(by tomeu):

 Replying to [comment:5 garycmartin]:
 > Replying to [comment:4 tomeu]:
 > > Replying to [comment:3 garycmartin]:
 > > > Replying to [comment:2 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!

-- 
Ticket URL: <http://dev.sugarlabs.org/ticket/453#comment:6>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system