[Panel-devel] Raptor(){Menu Ideas {Data {AI{Search}}}}

Wade Olson wade at corefunction.com
Wed Aug 30 04:35:58 CEST 2006


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 <aseigo at kde.org> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>
>
>


More information about the Panel-devel mailing list