--===============0371194994==
Content-Type: multipart/signed; boundary="nextPart2243245.opvs1YqtRj"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: quoted-printable


--nextPart2243245.opvs1YqtRj
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"

On Friday, April 29, 2011 23:57:57 Luiz Rom=E1rio Santana Rios wrote:
> 2011/4/29 Aaron J. Seigo <aseigo@kde.org>
>=20
> > On Friday, April 29, 2011 00:21:11 Luiz Rom=E1rio Santana Rios wrot=
e:
> > > 2011/4/28 Aaron J. Seigo <aseigo@kde.org>
> > >=20
> > > > On Thursday, April 28, 2011 09:15:08 Luiz Rom=E1rio Santana Rio=
s wrote:
> > > > > Currently, when we type something in, krunner displays the
> > > > > results
> > > > > as it finds it, without giving a feedback of whether it is
> > > > > searching or just didn't find anything.
> > > >=20
> > > > that would be a nice addition.
> > > >=20
> > > > > It also does not separate the results into its different
> > > > > categories
> > > >=20
> > > > that's because they are organized by relevance. if they are
> > > > sorted into categories, and if there are 4 categories that
> > > > match and 5 items in
> >=20
> > each
> >=20
> > > > category then the best match from the 4th category will be the
> > > > 16th
> >=20
> > item
> >=20
> > > > in the list(!) even though it is more likely to be what the use=
r
> > > > wants than most
> > > > of the items above it.
> > > >=20
> > > > i have yet to see a solution for this problem, but am open to
> > > > such a
> > > > solution
> > > > being offered.
> > >=20
> > > Well, I thought about showing only the most relevant results for
> > > each
> > > category and priorizing the category with the most relevant resul=
ts.
> > > If a
> >=20
> > which is almost always going to be the nepomuk search ;)
> >=20
> > > user want to see more results for that category, they would just
> > > need to expand it. I'll do some mockups for that and will post
> > > here.
> >=20
> > sounds good; mockups always help.
>=20
> Here's one:
> http://lh5.googleusercontent.com/_V8ZPvFyTxNc/Tbty2kU7CII/AAAAAAAAARs=
/v_Ut1J
> 8P4DQ/01%20-%20Expand%20and%20Shrink%20less%20relevant%20results.png
>=20
> It's bad, I know, I suck at making mockups, but it gives part of the =
idea of
> what I mean.

wire frame mockups like that one are just fine. they let one concentrat=
e on=20
the structure rather than get distracted by shiny things ;)

> Notice that I show two different ways of expanding the results
> in it. I think the button is better, but it takes too much space, so =
I'm

and what would be the workflow to expand / collapse / run?

an important part of krunner is being able to very quickly type and exe=
cute.=20
the UI is not fancy, but it is designed for speed.

> > then the Nepomuk runner needs tweaking in how it rates results.
>=20
> So this is the first thing we should do, I guess.

it's definitely a good starting point. :)

> What I meant was that I think it's better to wait one or two seconds =
after
> the user stops typing so that krunner doesn't start querying with an
> incomplete string.=20

that would probably ruin one of the main features of krunner: match as =
you=20
type.

> I also think it would give focus to the main result, if
> there's one, but I may be wrong.

it already does.

> Weird. Should it work if I just type in something and then press the =
down
> arrow?

yes...
=20
> Well, I will stop and think over this project and get back with bette=
r
> summarized idead and more mockups tomorrow.

:)

--=20
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

--nextPart2243245.opvs1YqtRj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEABECAAYFAk27uGYACgkQ1rcusafx20OpvQCeKB8uuWEOLUENUofjVobq8s80
XyMAoJkkrDCTESrboogx+HWCiJIY+HUy
=w/L6
-----END PGP SIGNATURE-----

--nextPart2243245.opvs1YqtRj--


--===============0371194994==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

--===============0371194994==--