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

List:       kde-usability
Subject:    Re: KIconDialog++
From:       Sébastien_Laoût <slaout () linux62 ! org>
Date:       2006-06-01 15:23:59
Message-ID: 200606011723.59782.slaout () linux62 ! org
[Download RAW message or body]

Le Jeudi 1 Juin 2006 15:37, Luke Sandell a écrit :
> Sébastien Laoût wrote:
> > - My KDE is configured in "Single-click" mode.
> >   When I click an icon in your dialog, the icon is directly returned.
[...]
> I am using KIconCanvas, which derives from KIconView. If KIconView is not
> honoring your settings, then there is a bug in kdeui that needs to be
> resolved. When I port this to Qt 4 it will be using all different classes,
> though.

Ah, yes that's true.
The old KIconDialog have this bug too.
That's posted:
https://bugs.kde.org/show_bug.cgi?id=128447

> I noticed this bug too. Shouldn't we also try to fix KIconView instead of
> just hacking it every time?

We will do both :-)
You will fix it because your dialog must run in every KDE versions.
And I also reported the bug:
http://bugs.kde.org/show_bug.cgi?id=128448

> This brings up another question that I had in the back of my mind: should
> the user ever be allowed to select "no icon"? What if he sets an icon for
> something and then later decides he doesn't want an icon? Maybe this could
> be handled by a "clear" context menu on KIconButton?

I also asked myself the question because I need it for BasKet.
What I will do is a custom KIconButton that, when clicked, popup a menu with 
most suitable icons (and/or recent icons) and a "Default" choice:

   [#]
   +-------------+
   | # @ { ç à § |
   | ~ " & ] \ ` |
   | ----------- |
   | @ Default   |
   +-------------+

Your right-click solution is nice (and easier to do).
But what about discoverability?!

I propose to allow both "None"/"Clear" and "Default" (for cases where an icon 
SHOULD be present).
And of course, options to activate/desactivate both buttons programaticaly.

> I already noticed this and fixed it locally.

Nice.

> I didn't add drop support, because I was puzzled on how dropping should be
> supported. One option is to simply use the path of the icon that is
> dropped. The problem with this is that the user could assume that the
> dropped icon was "copied" somewhere and then go and delete the icon. The
> other option would be to copy the icon to some resource folder so that the
> original can be deleted without problems (an advantage here is that icons
> from the WWW could be dragged in as well). However, due to the way we load
> icons, the filename always has to be preserved, meaning there could be
> conflicts if we drop another distinct icon with the same filename (though
> highly unlikely).

I would say copy it.
And do the same with "Browse...".
Browse and drop should act the same.

Currently, if I choose "Browse...", the full icon path is returned by the 
dialog.

I think you should copy it to eg. ~/.kde/share/customicons, and if there is 
already an icon with this name, append a number to it: myicon.png, 
myicon2.png, myicon3.png...

Hum... but what about if the user drop or browse the same icon several times!
It would be duplicated the same number of times :-/
_______________________________________________
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]