Fedora 9 Feature suggestion - The start menu and caching

[Leszek Matok]

Dnia 2007-11-07, o godz. 16:23:05 Mark <markg85 at gmail.com> napisał(a):

> What would be best with the start menu:
> - During boot the start menu and all it's icons (actually all the
> default icons) should be cached so that the start menu pops up right
> away when you click on it and all the icons are in place and vissible.
Not at boot. Not by any external readahead-like program. It should be loaded
by gnome-panel and its "main menu" icon or the default main menu, only, if it
is visible (added to the panel).

I can only guess that some people have the menu and don't use it, and not
loading it leaves some memory for other programs. Sounds like a nice feature
for low-end machines. On my low-end machine, loading the menu and icons can
take up to a minute. Imagine yourself waiting a whole minute longer to be able
to use your DE.

> Wouldn't it be best to precache all the applications that are gonna be
> started anyway? like:
> - gome-desktop
(...)
Yeah, especially by KDE users.

> - firefox
> - the default mail client (forgot the name)
> - the default wallpaper
I don't use those, so leave my system faster, and for you: why longer the boot
time, when you will get the apps loaded as soon as you log in and run them?

> - precache all the icons that where on the desktop in the last session
> so they appear fast when gnome starts
Again: not before someone logs in, and if you log in, they get loaded anyhow.

> - perhaps also GDM so that you don't see the picture building up like
> you see at this moment in nearly all linux distributions.
BTW: what happened to the "die-ugly-pattern-die-die-die" patch for Xorg? Or is
just my Fedora broken in the ugly-pattern matter?

> And perhaps some less importand programs that get used often:
Only if your session history shows that you use the programs. That would
require gathering and keeping of lots of statistics about files opened by you
when you're logged in. This would expand to precache documents which you're
going to open in a minute and so on, but I'm afraid

Instead of going after precaching things which then get wiped from memory when
I do things other ways than usual, losing the time instead of gaining it,
let's concentrate on making it obvious to people that something is going on.
You can't make everything to happen instantly. Making slow things a little bit
less slow doesn't gain anything, when the system isn't responsive. I need an
immediate response to my actions, then I can wait as long it takes to finish
the task.

I mean, if I open a document, a video file, a new gnome-terminal tab, I have
to wait few seconds to see any effect (like OOo popup, MPlayer window, new
terminal tab, without shell at first). This makes me wonder: did I really
press that button? Did I double-click that icon?

I've seen tens (!) of people running two-digit number of Outlook Express or
Word instances on Windows just because there was no indication that the
program was already being scheduled to be run. I'm very glad that in Fedora
(at least in GNOME), when I run a program from the panel, I see an immediate
effect (it's a new button in wnck-applet). I can see the computer is doing
what I'm telling it to do. But other than running things from the panel, all
my other tasks leave me wondering all the time: did I really press that button
or should I press it few more times?

This isn't easy to fix today, after years of lousy programming. Now it's
impossible to make it some system-wise user notification system. Or am I
wrong? Maybe there's some wonder libusermadnesspreventer.so that can be linked
to fix any program? :) Or is open market expected to regulate things (good
programs win over bad programs - is Evolution still the default MTA?) over
time?

Okay, thanks for reading to this point, I think I'm done. Thanks again.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/1baa8693/attachment.sig>