[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Gustavo Sverzut Barbieri <gustavo () gsbarbieri ! sytes ! net>
Date:       2004-05-25 16:09:27
Message-ID: 200405251309.27354.gustavo () gsbarbieri ! sytes ! net
[Download RAW message or body]

Em Tuesday 25 May 2004 11:55, Dik Takken escreveu:
> On Mon, 24 May 2004, Gustavo Sverzut Barbieri wrote:
> > What if you want all material about certain artist? You want every music,
> > video clip and poster/image/something.
>
> Then you write a nice 'Media' plugin that calls a number of other plugins.

OK.


> > I have another (yeah yet another!) idea: the framework should be able to
> > group plugins. This way we can have a "All" which groups every active
> > plugin, "Media" which search music, images and videos, "Documents" which
> > searchs .doc, .txt, .sxw, ...
> > 	What do you think?
>
> If you want the user to be able to groupd plugins, yes that's a great
> idea. If you just want developers to be able to group plugins: No need.
> They can write 'group plugins' that just call any number of other plugins.

I'm not sure about this. Maybe with good groups we don't need to let users 
group themselves. That's good since we don't to provide GUI for it :)


> > Maybe we should come with another view mode for searches... something
> > that use "Sections" and each section can display different modes and an
> > easy way to navigate through Sections.
>
> Yes, we definitely do. I don't know if it is technically possible to
> create a list of different widgets that present different types of
> information? Then you could just create a list of all widgets output by
> all plugins and put them on one page that can be scrolled up and down.
>
> For this, you need a scrollable widget that you can contain any number
> of other widgets.
>
> Can anyone enlighten us about this technical issue?

I'm not a KDE developer, so I may be wrong, but we could use something like 
khtml for that. If it's too slow, we can have something lighter but which do 
the same thing without parsing the html.


> >> There is room for a "search everything" plugin, but there is a lot of
> >> reason to not have the system just keep on searching beyond where you
> >> asked it to. This can be horrendously slow. Searching is a very
> >> intensive process, often. On my system, doing edonkey searches at the
> >> same time as any other large amount of work causes noticeable slowdown.
> >> Same for local file searches, although less-so.
> >
> > Yes, this may be a problem... however as computers go fast we can have
> > this... I know, what about the older... well, disable these plugins.
>
> Well, as plugins have user-configurable priorities, the highest rated
> plugin will output it's results before the next starts searching. If the
> user thinks he has had enough results, he only needs to hit the
> 'ok,that's enough' button, right?

Good idea.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsbarbieri@jabber.org
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]