From kde-panel-devel Wed Aug 30 02:35:58 2006 From: "Wade Olson" Date: Wed, 30 Aug 2006 02:35:58 +0000 To: kde-panel-devel Subject: Re: [Panel-devel] Raptor(){Menu Ideas {Data {AI{Search}}}} Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=115690537323371 Top posting....(Top Posting Association of North American Member) What timing on a usability post from Seele (including her on this email thread): http://weblog.obso1337.org/ http://obso1337.org/hci/papers/Study_of_Desktop_Start_Menu_System_Usability.pdf Hopefully these Raptor ideas will be discussed with the HCI peeps? On 8/29/06, Aaron J. Seigo wrote: > On Monday 28 August 2006 15:39, Siraj razick wrote: > > therefore i'd analyze the users app launching behaviour (i.e. session just > > started, we need a konsole, kmail, amarok and konqueror, or: 12:30 launch > > break, we wanna play ksudoku) and have a ranking system on top of a > > (simple) bayes filter > > timelining based context ... this is something i'm interested in helping R&D > once i'm a bit more clear from immediate nuts and bolts stuff. > > > 5.) KServices already come from a binary cache, and one that is already in > > RAM: ksycoca. there's probably very, very little to be won by doing this > > againourselves. in fact, it would almost certainly be slower (since you > > still haveto read the binary cache), more bug prone and take up more memory > > .. Aaron<- > > ->Richard > > This is true but IIRC only the system level things are cached. It > > might be worth considering if we should be caching user specific stuff > > too. That said, this is of course an optimisation and can be looked at > > later after profiling.( From Richard Moore) > > right now the user specific stuff is cached during runtime, but read in from a > summary stored in a text config a load time. currently the amount of data > stored in this fashion is extemely small and therefore not significant to > startup overhead, and from that point forward is kept resident in memory. the > only annoyance right now is that we write it out to disk fairly often IIRC > (after each alteration?). not great. > > the RecentlyLaunchedApps class needs to be replaced. in fact, i'm not sure > this even belongs in plasma as it needs to be accessible from other points, > such as the run dialog. right now the run dialog is part of the desktop, but > that's not acceptable if we combine the desktop with the panels. IMHO, the > run dialog (which needs revisiting at some point in kde4's life; not a hot > point for 4.0 perhaps but would make a nice 4.1 improvement) should be > isolated into it's own long-running service and perhaps combined with a > simplified task listing. this would allow nice isolation (and process > prioritization) of these two critical desktop services. > > > Thomas: dose not like Stigi: :-) as he thinks of it as a desktop search > > engine..which is too much for a Menu..But as a personal note I do not > > think this as a big problem.as if we are using plugins as Thomas agrees on. > > we can switch off what we don't like. like in Kate or kopete.. > > if strigi is only to be used with the ALI then yes, it doesn't make sense. > if strigi becomes more widely used on the desktop then it becomes a shared > resource. the value of strigi and similar systems is derived directly from > the number and variety of data sources it draws upon with the filesystem > being simply one of those sources. > > > Kickoff: the Data is had coded into the menu ..very similar to the current > > Kmenu..actually from what I heard from Coolo(Kulow) ..it's a BIG patch to > > kicker; but there is no clear separation of data and GUI and links with > > Beagle ( I think).other than that; we have good things we can use in Raptor > > from Kickoff. > > agreed. > > > KBFX: Data source should be Separate from GUI and have a Generic search > > engine which allows for applications as well as files ( emails ,, > > notes..).. and also have plugin specific search methods. and let the user > > turn off what he dosen't want. which allows for hiding the data source from > > the menu.. > > a plugin based search system essentially removes the > to-strigi-or-not-to-strigi as well as the "but we want beagle, love novell" > issues. i like that =) > > > but just wondering into KDE4 and looking for a place to start. surely > > we wellcome all to Join the "Plasma Raptor" and make the Raptor vision come > > the run dialog separation is another fairly straightforward task that would be > a welcome entry point... > > -- > Aaron J. Seigo > Undulate Your Wantonness > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) > > > _______________________________________________ > Panel-devel mailing list > Panel-devel@kde.org > https://mail.kde.org/mailman/listinfo/panel-devel > > > > _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel