new working set icons... not unique?

Sven Brauch svenbrauch at
Wed Dec 18 21:22:40 GMT 2013


> However you also
> don't seem to be restricting the possible colors to ones that are
> distinguishable, period. (More on this below.)
Yes, I agree the current approach has its issues and I'm happy to
discuss and implement improvements to it.

> (Hum. This reminds me, I was reading somewhere about algorithms to generate
> recognizable graphical "fingerprints". I wonder if that would be applicable
> here. I believe the general technique is to do a random walk over a modest
> grid size - in KDevelop's case, probably 5x5 or even 3x3 - and increment the
> cell value per visit, using a mapping of number of visits to, in the case I
> was reading, an ASCII character. For KDevelop, I would probably have two
> 'bins', one red and one blue, choose one at random to 'operate on'
> initially, and alternate that choice every time the random walk tries to
> cross the edge of the grid.)
Yes, I have investigated this when I was writing the feature. The
problem is that those fingerprints are usually large pictures (e.g.
64x64). In 16x16 you really can't put that much shapes before the
image gets blurry and messy.
Effectively such an algorithm is what I have implemented here.

> ...and I get where you're coming from also. Just saying, that despite their
> other flaws, the old icons were at least easy to remember. It would be best
> if there was a way to have both attributes.
I agree. Maybe we can come up with a change which improves the situation here.
That being said, I don't find the new icons particularily hard to
remember -- except if they are very similar, of course.

> What about just letting the user pick the icon? One option then could of
> course be to generate a new, random one, but this would allow the user to
> assign genuinely memorable and relevant icons as well.
Mmh. I don't feel good with mixing the auto-generated icons with
user-picked ones with a completely different style concept. It feels
like "we could't make this concept work properly so we added another
concept on top of it"...
I'd much prefer if we could find a way to make the generated icons better.

> Yes, or choose, or as per the first paragraph, limit the possible color
> choices to ones that are reasonably distinct to begin with. Even if you
> limit the colors to [dark, light] × [red, magenta, blue] (and dark gray),
> that still gives 7^4 (2401) possible icons, which ought to be enough to
> choose unique ones for any reasonable session. (I'd be surprised if any
> human can realistically cope with 100 sessions, let alone thousands...)
Although I'm perfectly aware that technical reasons are not an excuse
for poor UI ever, let me explain a bit about the technical situation
Currently, a working set has an identifier, a short, random string
(which is stored with the working set), and the icon is calculated
*from that identifier*. So, same identifier, same icon -- we don't
need to store icons at all, we just generate them from the identifier
whenever they are requested.
If you start comparing icons to each other and checking whether an
icon is too similar to an existing one, that does not work any more.
The reason is that if you have two sets which would generate very
similar icons, then one will draws a different icon to avoid the
similarity. But if you now close the first set, the icon for the
second one will change too because the similarity is gone. So that
doesn't work.
So, if we want to compare icons for similarity, we need to store them
to disk so they stay stable for a given working set. That's not
trivial, because when we save them somewhere we need to delete them
again when they are not needed any more. And for deciding whether they
are needed or not -- it is infeasible to catch all the corner cases in
which an icon becomes unused.

This is also the reason for not limiting the choice of colors -- my
hope was that we could have a large enough pool of possible icons that
random similarities do not happen. In my tests this worked okay, but
it turns out it's not the case for a larger set of samples.

One thing which just came to my mind though is that we could store the
icon data among with the identifier in the session. It's quite small,
so that might work. I'll look if that makes sense, because if it does,
we can compare icons for similarity and make sure we draw icons which
are sufficiently different from each other at least.

The alternative, which is also quite simple I think, is just making
the icon in the left corner of that popup widget clickable and if you
click it, it will change to a different one.

When it comes to remembering the icons, you'll have to tell what would
make them easier for you to remember. I find them quite easy to
remember, but then again I usually only have 2-3 working sets...


More information about the KDevelop mailing list