On Sat, 24 Sep 2005 08:35:50 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> It's 8 in the morning here, and I've been awake since some vague time > way back in yesterday. I may be rambling. I also have no idea what I'm > talking about, since I have not looked at the code or the design. > > On Fri, 23 Sep 2005 23:40:14 +0200 Gabriel Rossetti > <[EMAIL PROTECTED]> wrote: > > > Can't you just cache the eaps that need to be visible? I doubt that he > > has hundreds of eaps in his ibar/engage. > > As I said, to get e17 to start up quickly again, I cut it down to the 40 > odd eaps that I use on a regular basis, and start everything else from > the command line, living without icons for those. Most of those 40 live > in the menu, only a dozen are in engage. > > > and load the others if they are needed later on? 10 times out of 9 we > > use programs that are in our menu/ibar/engage first, > > that's why we put them there in the first place. > > Good point, which suggest a three level approach. At start up load > those used by ibar, engage, and first level favourite menu. Load other > menus as they are accessed (most menus will have few enough to make > this quick), or as a background process after handing control to the > user. Most of the time apps will be started via ibar/engage/menus, so > they will be loaded before they are needed, even if it just before (I > love 'just in time' code). Only loading the first level menu at > startup also caters for the time when all 4000 eaps have already been > spread around several levels of menus. > > The second level is to track often used apps, what "favourites" usually > means in other window managers/OS's. Recent versions of KDE let the > user choose between most recently used, and most often used. Nothing > stopping us from doing both, stick them in a menu or two. Once they are > in a menu, the eaps get loaded according to first level rules. Before > they get to the menus, they are loaded according to third level rules. > > Which brings us to the third level, a low priority task that checks > through all other eaps, caching the meta data and pointers to the > original eap, checking that this cache matches current reality, updating > when the eaps get changed, etc. In other words, Rastermans new idea, > but it only applies to eaps that are hardly ever used, or that where > newly created a few minutes ago. > > The beauty here is that the horrid 'scan several thousand files and > cache them' process is both low level background, and not needed most of > the time. The second level makes e17 customise itself based on your > actual usage. Visible ibar/engage/menu icons get loaded quickly, > sometimes just before they are needed. The only time you get a long > delay is when you start an app that you have not started before, AND has > not been processed by the third level task, in which case the delayed > thing is providing a tiny little icon in the corner of the window. Oh > yeah, and the same icon on your engage task bar, which will be a big > blue question mark until the icon is found. I suspect that this will > not happen often, and should never happen a few minutes after the > thousands of eaps are created in the first place, as the background task > will have caught up by then and the cache will be correct. > > Fresh e17 installs will distract the user with all this new, fancy, gee > wizz stuff that is accessed from ibar/engage/menus, that by the time > they get around to trying to access third level eaps, the background > task has completed B-). > > Create icon from the window menu may have to to display a "you have > 4000 of apps installed, and I have only processed 1234, 1235, 1236" > progress bar for a minute or two. why bother? when i can load a cache in like 1/100th of a second? :) that's my current plan :) right now its loading the cache and thus has a complete in-memory db of the apps, my next step is to now put a slow burn timer to tick over scannng the real fs and cache entries matching up reality to the cache and if the cache does not match, adjust the in-memory representation and flag it for needing a re-write to disk, on finish of a scan, write the cache file to disk again if it needs updating. > Everybody is happy, e17 gets a reputation for being fast, pretty, and > intelligent, Winblows dies a the horrible death that it deserves, and > we all get paid huge sums of money to develop e18. > > Over to you lot, pick holes in these ramblings. > > -- > Stuff I have no control over could be added after this line. > > Send instant messages to your online friends http://au.messenger.yahoo.com > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
