Re: UI-Glitch?

Andreas Schleth <schleth_es-S0/[email protected]> Tue, 16 Feb 2021 22:42:28 +0100
Newsgroups	gmane.comp.kde.kimdaba
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--===============7271726557614630779==
Content-Type: multipart/alternative;
 boundary="------------0966E1D1D027241B3D50BAA9"
Content-Language: de-DE

This is a multi-part message in MIME format.
--------------0966E1D1D027241B3D50BAA9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Johannes,

these seemingly simple things are always much more complicated than
expected, see below in the text.

Anyway, I am on the branch for now to give it a go - let's see how it
develops.

Best regards, Andreas


Am 16.02.21 um 01:02 schrieb Johannes Zarl-Zierl:
> Hi Andreas,
>
> Am Mittwoch, 3. Februar 2021, 00:30:55 CET schrieb Johannes Zarl-Zierl:
>>> I use the search box in many other cases (when sifting through
>>> categories or so) but then I always know which data pool I am fishing =
in.
>>>
>>> So my preference would be #3:
>>> - when in thumbnail view: focus on the thumbnails,
>>> - when in other views: focus on the search box.
> I've implemented #2 (don't give focus to search bar) anyways - at least =
as a
> basis for further discussion.
>
> I think given Reimar's suggestions for making the whole window more keyb=
oard-
> friendly, this variant may now work significantly better than when I ini=
tially
> suggested it as an option.
>
> If you could try out the branch "work/jzarl/searchPopup" [1,2] you'll fi=
nd

This my current version: v5.7.0-209-gb2034b26 (after some fiddling with
git - I am not so git proficient that I can swear that I have the right
branch)

It feels nearly right.

And I am just exploring the difference between searching and just typing
in the category list...

Why is it that the arrow-keys and home/end do not act on the search
string when the focus is on the search bar? The left-right arrows are
"dead" and the up/down arrow keys act on the category entries.

I would naively expect that the keys would help editing the search
string...

> that:
>   - the searchBar no longer has input focus by default
>   - pressing '/' activates the search bar (regardless of current view)
I like that, feels like vim :-)
>   - tab order makes going back to the main content easier
>
> One further tweak that may make this even smoother could be for the Sear=
chBar
> to loose focus when it is cleared by pressing escape - any thoughts on t=
his?

As mentioned above, it might worth a try to make the search box function
in more or less the same way as the google search slot (in terms of key
bindings when it has focus).

I this respect "enter" and "esc" behave different from the google
example. The "esc" function is a nice addition, "enter" however behaves
strangely:

- in a category of many names I type 3 letters so the list is down to 6
names, none of which is highlighted

- on "enter" (from the search bar) some selection is done and I am back
in the main window.

- going back to the same category, I would expect to find at least one
of the 6 names - but no: all of them are different.

So what exactly did my "enter" action select?

- OK, ok, ok: the "enter" (from the search bar) selects the first in the
list (which is not by default highlighted) and this name is not anymore
displayed when opening the category list again.

- However "enter" in a fresh category selection view (without selecting
anything and with focus in the list albeit not activated by any
keypress) does nothing at all.

>
> Cheers,
>    Johannes
>
>
>
>
> [1] https://invent.kde.org/graphics/kphotoalbum/-/commits/work/jzarl/
> searchPopup
> [2] Sorry for the confusing branch name - I initially intended to implem=
ent a
> search popup like you'd get in dolphin or firefox.
>
> _______________________________________________
> KPhotoAlbum mailing list
> [email protected]
> https://mail.kdab.com/mailman/listinfo/kphotoalbum


--------------0966E1D1D027241B3D50BAA9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-=
8">
  </head>
  <body>
    <div class=3D"moz-cite-prefix">Hi Johannes,</div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">these seemingly simple things are
      always much more complicated than expected, see below in the text.</=
div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">Anyway, I am on the branch for now to
      give it a go - let's see how it develops.</div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">Best regards, Andreas<br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">Am 16.02.21 um 01:02 schrieb Johannes
      Zarl-Zierl:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:2253847.GAQig012V3@mani">
      <pre class=3D"moz-quote-pre" wrap=3D"">Hi Andreas,

Am Mittwoch, 3. Februar 2021, 00:30:55 CET schrieb Johannes Zarl-Zierl:
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">I use the search box in m=
any other cases (when sifting through
categories or so) but then I always know which data pool I am fishing in.

So my preference would be #3:
- when in thumbnail view: focus on the thumbnails,
- when in other views: focus on the search box.
</pre>
        </blockquote>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">
I've implemented #2 (don't give focus to search bar) anyways - at least as=
 a
basis for further discussion.

I think given Reimar's suggestions for making the whole window more keyboa=
rd-
friendly, this variant may now work significantly better than when I initi=
ally
suggested it as an option.

If you could try out the branch "work/jzarl/searchPopup" [1,2] you'll find=
 </pre>
    </blockquote>
    <p>This my current version: v5.7.0-209-gb2034b26 (after some fiddling =
with git - I am not so git proficient that I can swear that I have the rig=
ht branch)</p>
    <p>It feels nearly right.
</p>
    <p>And I am just exploring the difference between searching and just t=
yping in the category list...</p>
    <p>Why is it that the arrow-keys and home/end do not act on the search=
 string when the focus is on the search bar? The left-right arrows are "de=
ad" and the up/down arrow keys act on the category entries.</p>
    <p>I would naively expect that the keys would help editing the search =
string...
</p>
    <p><style type=3D"text/css">
</style></p>
    <p><style type=3D"text/css">p, li { white-space: pre-wrap; }
</style></p>
    <blockquote type=3D"cite" cite=3D"mid:2253847.GAQig012V3@mani">
      <pre class=3D"moz-quote-pre" wrap=3D"">that:
 - the searchBar no longer has input focus by default
 - pressing '/' activates the search bar (regardless of current view)</pre=
>
    </blockquote>
    I like that, feels like vim :-)<br>
    <blockquote type=3D"cite" cite=3D"mid:2253847.GAQig012V3@mani">
      <pre class=3D"moz-quote-pre" wrap=3D"">
 - tab order makes going back to the main content easier

One further tweak that may make this even smoother could be for the Search=
Bar
to loose focus when it is cleared by pressing escape - any thoughts on thi=
s?</pre>
    </blockquote>
    <p>As mentioned above, it might worth a try to make the search box fun=
ction in more or less the same way as the google search slot (in terms of =
key bindings when it has focus).</p>
    <p>I this respect "enter" and "esc" behave different from the google e=
xample. The "esc" function is a nice addition, "enter" however behaves str=
angely:
</p>
    <p>- in a category of many names I type 3 letters so the list is down =
to 6 names, none of which is highlighted</p>
    <p>- on "enter" (from the search bar) some selection is done and I am =
back in the main window.</p>
    <p><strike>- going back to the same category, I would expect to find a=
t least one of the 6 names - but no: all of them are different.</strike></=
p>
    <p><strike>So what exactly did my "enter" action select?</strike></p>
    <p>- OK, ok, ok: the "enter" (from the search bar) selects the first i=
n the list (which is not by default highlighted) and this name is not anym=
ore displayed when opening the category list again.</p>
    <p>- However "enter" in a fresh category selection view (without selec=
ting anything and with focus in the list albeit not activated by any keypr=
ess) does nothing at all.
</p>
    <blockquote type=3D"cite" cite=3D"mid:2253847.GAQig012V3@mani">
      <pre class=3D"moz-quote-pre" wrap=3D"">

Cheers,
  Johannes




[1] <a class=3D"moz-txt-link-freetext" href=3D"https://invent.kde.org/grap=
hics/kphotoalbum/-/commits/work/jzarl/">https://invent.kde.org/graphics/kp=
hotoalbum/-/commits/work/jzarl/</a>
searchPopup
[2] Sorry for the confusing branch name - I initially intended to implemen=
t a
search popup like you'd get in dolphin or firefox.

_______________________________________________
KPhotoAlbum mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:KPhotoAlbum-XR6rmp8fbRTRv0WFA/[email protected]=
.com">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://mail.kdab.com/mailman/l=
istinfo/kphotoalbum">https://mail.kdab.com/mailman/listinfo/kphotoalbum</a=
>
</pre>
    </blockquote>
    <p>
</p>
  </body>
</html>

--------------0966E1D1D027241B3D50BAA9--

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

_______________________________________________
KPhotoAlbum mailing list
[email protected]
https://mail.kdab.com/mailman/listinfo/kphotoalbum

--===============7271726557614630779==--