Re: [Nautilus-list] Nautilus user testing at MIT

[david <david bishop dhs org>]

On Fri, Jan 05, 2001 at 11:49:07PM +0100, Nicolas Mailhot wrote:
> 
> Le ven, 05 jan 2001 23:26:39, david a écrit :
> > I was thinking soley of having cursor feedback in the
> > "launching" phase, mainly for two reasons:  you can do it
> > with existing programs without requiring them to be
> > changed/modified (an extremely difficult process, the
> > modify all open-source apps, let alone close-source) 
> 
> If you move the thobbers to window manager (title bars) /
> desktop manager (task list) space, you've got no more
> modifying to do than with cursors.

The point wasn't having it be the cursor, it was that you can only monitor "loading", not "app busy" or "app in wait state" without modifying each application.  Unless I am mistaken, wrapping program launches to get feedback on launches is easy. It's getting the programs to report back *after* they've succesfully started to report other things that would require updating all apps.  I.e., we could easily replace the dreaded hourglass with a spinning pointer, but we couldn't replace the spinning mozilla in netscape without modifying the app. Does that make sense? I've deleted this paragraph 3 times now trying to figure out a better way to explain this.

> 
> Given the size of cursor forms an similar multi-state
> throbber would fit there easylly.
>

I don't know what you meant by that last sentence. Could you reword?

> > and
> > also because "throbbers" do a good job of feedback in
> > those apps that need it after being launched.  What you
> > mention as a defect (the cursor getting "stuck" if
> > something hangs on load) I see as a feature.  How many
> > times have you looked and seen three or four netscape
> > sessions loaded in the background, none of them visible? 
> > I've had it happen to me a *lot*, and if I had a spinning
> > cursor telling me something was wrong, I would investigate
> > it a lot sooner.
> 
> Well, better to see *what* app is stuck with a dedicated
> throbber than search all launched app for the one causing
> the problem.
> 

Point taken. Next question: how would you manage multiple programs being launched, finishing launching, whatnot?  I'm imagining something along the lines of enlightenment's iconbox, with icons appearing in it as soon as you double-click a program, and disappearing when they've completed starting.  This presents two problems (off the top of my head): 1) it would have to be resizeable, probably dynamically so, otherwise you'll lose apps. This causes havok when it's embeded in gnome-panel, as the current "task bar" functionality shows. I personally *hate* that, when everything on my panel moves around just because I opened some more apps. However, it's been a while since I've used gnome-panel, so if that isn't a concern anymore, good! 2) apps that start quickly will not take *longer* because they have to create an icon, start, then destroy that icon, requiring at least two more full screen updates per app.  Again, I'm not an X programmer, so if that isn't a concern, good!  If y!
 our response to this is that it won't be just a launch-throbber, well, see my first comment :-)

> > 
> > If you did go the way of the seperate "throbber" that apps
> > reported to, how are you going to handle the transition? 
> > What happens when a user opens an app that hasn't been
> > modified yet?  Wouldn't the inconsistency get frustrating?
> 
> Of course, for this to work the throbbers shouldn't be
> embeded *in* the application windows, but in WM/desktop
> manager space.
>

It actually doesn't matter to me whether its a seperate applet or whatever. I'm not stuck on using the pointer :-)

> >  On the other hand, if Nautilus was handing all the
> > launches, it could simply wrap any executables with that
> > Xaos (or whatever it was) and instantly get feedback on
> > *all* apps.  Again, what am I missing?
> 
> This shouldn't depend on nautilus.
> Nautilus should not try to do WM/desktop manager work
> 

Hrrm. I agree, the actual implementation should be lower down.  Could it be some sort of library that all gnome apps hook into, and when they launch other apps, they call this functionality?  As to why they shouldn't call it for themselves, well, that goes to the whole "modify every program out there" conundrum. To clarify, I think all apps that launch other apps (i.e., gmc, nautilus, sawfish, etc) should tell the throbber app "I just launched X. Start spinning.", as opposed to each program having to say "I just launched. start spinning and I'll tell you when to stop."

> > P.S. I think I dropped this discussion off the mailing
> > list on accident. I'm adding it back to the CC: line.
> 
> This kind of discussion belongs to the gnome general gui
> mailing list, not the nautilus one. I've changed the CC.
> 

Kay.

D.A.Bishop


> > On Fri, Jan 05, 2001 at 12:28:27AM +0100, Nicolas Mailhot
> > wrote:
> > > 
> > > Le ven, 05 jan 2001 00:03:22, david a écrit :
> > > > Gah, is this retread of old ground I smell? ;-)  Well,
> > as
> > > > I wasn't a part of the previous discussion, I don't
> > know
> > > > what was proposed.  Here is my idea, please feel free
> > to
> > > > thrash is:
> > > > 
> > > > When apps are launched in gnome/nautilus, and cursor
> > does
> > > > a slow "spin" like movement.  It doesn't turn into an
> > > > hourglass (which I agree is hard to point), but I've
> > seen
> > > > the "spinning symbol" metaphor as meaning busy in a
> > lot of
> > > > other places (particularly web browsers, which you
> > > > mention).  The spin continues as long as there are
> > apps
> > > > waiting to start, i.e., if you click in Netscape, then
> > ten
> > > > seconds later (while still waiting for netscape to
> > load),
> > > > you click on The Gimp, your mouse would not stop
> > spinning
> > > > until the gimp was fully launched (assuming netscape
> > > > finished first!).  If you keep clicking, it keeps
> > > > spinning.  People get the cursor-based feedback they
> > are
> > > > used to, you can keep using it as a pointer, and it
> > isn't
> > > > any more garish or ugly than an hourglass sitting
> > there. 
> > > > Now, what have I missed?
> > > 
> > > I see 2 problems :
> > > 
> > > * what if an app gets stuck ? You might launch a few
> > apps,
> > > then realise the cursor won't change state. How do you
> > find
> > > the faulty one then ?
> > > 
> > > * what if apps report different states ? Some apps might
> > > want the cursor in « busy » state, others in another one
> > ...
> > > How do you decide which state is more important ? How
> > many
> > > apps will it take for the whole system to become a
> > > meaningless nuisance ?
> > > 
> > > Introducing more states in thobbers is easier I think,
> > more
> > > intuitive, and works well with as many windows as you
> > want.
> 
> -- 
> Nicolas
>