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

[Nicolas Mailhot <Nicolas Mailhot email enst fr>]

Hi,

 Thank you for taking the time to read my proposal after so
long a time !

On sam, 06 jan 2001 00:20:40 david wrote:
> 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.

Well, sure some states are easier to implement than others.
But when an app like netscape change the cursor to a clock,
it must pass something to the X server, so that could be
wrapped.

So we can specify some states, wrap what can be wraped
now, and wait for developpers to implement the kewl new
states in their apps. The mini-icons we now see associated
with a lot of apps did resquire some inside coding too,
didn't they ? But once the way to pass this information was
codified (by kde, I think) people started coding it.

This is something that the kde/gnome group working on a
common specification could easily do ; and IMHO its worth
it.

> > 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?

I think I wrote this because someone thought a thobber would
never fit in a title bar. In my experience, mouse cursors
and title bars have about the same height, so a multi-state
titlebar-sized throbber would be no less difficult for a
user to see than an multi-state animated cursor (that's just
an opinion, by the way, with today shaped window
decorathions implementing a throbber a bit larger than the
rest of the title bar if perfectly possible).

> > > 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!

I myself use a lot of small panels with one dedicated to the
taskbar, so it can adjust as it likes, no one is hurt.
That's one solution. (It would be great if gnome allowed the
user to specify a panel space dedicated to an applet, so
that when it shrinks no other applet can step in, it just
shows an empty panel surface).

Anyway if one uses mini-icons to represent apps being
launched, one can specify a minimum size small enough not to
take too much screen estate, and big enough much of the
times (of course in some cases it would have to grow, but if
it's rare that's not a problem).

 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 :-)

Anyway a good solution is to create at once an entry in the
task bar, and draw the thobber over the mini-icon whenever
it's not in its  normal state. That's the xalf way, and it
seems to work well.

> > > 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 it would. That's life, computer systems are always
evolving for the better, which means that for a time they
are inconsistent. I don't think anyone even thought of a
solution, short of rewriting everything from scratch, which
usually takes too much time to be a real solution.

> > 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 :-)

I'm glad we agree on this.

> > >  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? 

I think the best solution would be to specify a set of state
hints, with the system adding automagicaly a titlebar
throbber (or whatever) to apps that report their states this
way.

General gnome libraries could declare state changes at
default points when its possible to give a good guess (for
example finalizing of main window change state to normal)
unless overidden by the app itself.

This way most gnome apps get a basic state support at once.
Now once the developper sees what throbbers can do for him,
he'll hapily code the state changes general libraries can't
guess to add a finishing touch. No need for the process to
be immediate, just for it to start, once enough apps support
enough states full support will appear a good thing for
everyone, and therefore happen:)

	Regards,

-- 
Nicolas