new working set icons... not unique?

[leonp at plris.com]

I strongly support numbering!!!!
Another option may be 1 or 2 user defined letters
Thanks

> I think numbering of the working sets would do better than any
> icons/colors/names. Last time I suggested that, some people were
> concerned with renumbering when you close the workingset. I personally
> don't think it's bad.
>
> And numbering reminds me of the similar concept often used in games to
> assign numeric shortcuts to groups of units. We could even have
> Meta-Alt-<Digit> shortcuts to switch between workingsets.
>
> PS: Furthermore, it is my opinion that Carthage^^^^.....working sets
> must be destroyed :)
>
>
> On Wed, Dec 18, 2013 at 3:22 PM, Sven Brauch <svenbrauch at googlemail.com>
> wrote:
>> Hi,
>>
>>> 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
>> here:
>> 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...
>>
>> Greetings,
>> Sven
>> _______________________________________________
>> KDevelop mailing list
>> KDevelop at kde.org
>> https://mail.kde.org/mailman/listinfo/kdevelop
> _______________________________________________
> KDevelop mailing list
> KDevelop at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop
>