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

List:       kfm-devel
Subject:    Re: KLook - quick preview extension for Dolphin
From:       todd rme <toddrme2178 () gmail ! com>
Date:       2012-10-21 15:15:17
Message-ID: CADb7s=v7j85+9z7cGza+foweyxoYgFfQDDyAah-kzR4FM3gHMg () mail ! gmail ! com
[Download RAW message or body]

On Sat, Oct 20, 2012 at 5:19 PM, Frank Reininghaus
<frank78ac@googlemail.com> wrote:
> Hi Sergey,
>
> 2012/10/19 Sergey Borovkov:
>>
>>
>> On Wed, Oct 3, 2012 at 5:04 PM, Frank Reininghaus <frank78ac@googlemail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> 2012/10/3 Sergey Borovkov <serge.borovkov@gmail.com>:
>>> > Yes, of course that bug will be fixed before I ask for review.
>>> > I just need
>>> > to merge my current work on KLook in master to do that (it's just a bit
>>> > incomplete and I am finishing it up).
>>> > About patch:
>>> > 1) I think nothing prevents to use Klook on space?
>>>
>>> Peter pointed out some time ago [1] why the "Space" shortcut for KLook
>>> does not provide a big usability improvement compared to the current
>>> situation in single-click mode (which is the default), and I agree
>>> with his arguments.
>>>
>>> > 2) The problem of insufficient space for icon is of course problematic,
>>> > I
>>> > agree - may be it would be ok not to show KLook icon when there is no
>>> > place
>>> > for it?
>>>
>>> If we do that, I can already see bug reports like "I enabled the KLook
>>> button, but Dolphin doesn't show it" coming from users who always use
>>> the Details View with a small icon size. And I also see that some
>>> users will request that we make it configurable if the selection
>>> markers or the "KLook" button will be hidden when there is
>>> insufficient space for both. In other words: such a solution would be
>>> a maintenance nightmare.
>>>
>>> Best regards,
>>> Frank
>>>
>>> [1] http://lists.kde.org/?l=kde-devel&m=133607423519253&w=2
>>
>>
>> Can you suggest an alternative to preview toggle?
>
> Unfortunately, I don't have any idea how to make it work better,
> sorry! If I had one, I would have suggested it already.
>
>> (or may be what todd rme proposed would be acceptable?)
>
> Hm, I think that showing the toggle somtimes on the icon and sometimes
> next to the icon would feel strange.

For people who want the feature I think they would get used to it
pretty quickly, and from that perspective it would be better than not
having the feature at all.  The selection toggle itself was pretty
strange when it was first implemented but people got used to that.

> It would also require quite a few
> different code paths (depending on the icon size and on the enabled
> toggles [none, selection, preview, selection+preview]) and thus make
> maintenance considerably harder.

Ideally it would be at most 1 additional code-path, since the handling
of the selection and preview cases should be the same.  Depending on
how it is implemented it wouldn't need to be a completely separate
code-path, either, since for example the icon bounding box could be
limited by the total size of the action icons, without needing to pay
attention to how many there are.

However, I think we are thinking about this on the wrong level.  I
think the question isn't how to best implement klook, but rather how
to best implement multiple action icons.  Digikam already has a bunch
of action icons, although apparently they implement them differently.
There are certainly use-cases for other programs specifying other
collections of action icons (calligra, kdenlive, etc.).  So I think
restricting this to just klook is missing the big picture.  This is a
feature with a wide variety of use-cases in a variety of programs, and
has already been implemented in various ways in various programs.  So
I think having a defined, generalized, consistent way to handle this
across KDE applications is important.  Even if you don't allow klook
in, the problem still exists in the other implementations.

I also think that it is a mistake to limit the dolphin corners to
klook.  I think being able to assign arbitrary actions to the three
available corners of the icon is a better approach.

-Todd
[prev in list] [next in list] [prev in thread] [next in thread]