new working set icons... not unique?

[Alexander Dymo]

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