[Cuis-dev] Browse class subcategories

[Luciano Notarfrancesco]

Here's a new version with Hilaire's second proposal and some fixes. It also
renames four categories for consistency with the rest of the system. It's
not intended for integration yet, at this point we're just playing with the
idea. Anyone feel free to play with this and change it in any way.

On Sat, Jan 8, 2022 at 11:12 AM Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> Hi Hilaire,
> Good points. I think I like your second proposal better… it’s simpler and
> it looks better in my Domains project (and probably in DrGeo too). We
> should experiment and see how it feels, I’ll start using it in my image and
> see if I encounter any problems or annoyances.
>
> On Sat, 8 Jan 2022 at 5:45 PM Hilaire Fernandes via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hi Luciano,
>>
>> Cool it is working nicely!
>>
>> Here some feedbacks on the usability and user perception to mature
>> concept.
>>
>> IMHO, you don't want to slice each subcategory. But then, there are
>> several scenarii to slice.
>>
>> *First scenario.* You slice starting at the deeper category, (sliced at
>> the most right)
>>
>>    1. In my image I have a package Color-Extras. It is sliced but it is
>>    not useful. So you want to slice only if there are at least two
>>    subcategories in the same parent category. Otherwise it just add noise to
>>    the GUI.
>>    2. You may have a maximum of one slice per category.
>>
>>    For Example Morphic-Kernel, Morphic-Events, will all be sliced as
>>    *Morphic*>Kernel, *Morphic*>Events.
>>
>>    But DrGeo-App, DrGeo-Core-Builders, DrGeo-Core-Commands,
>>    DrGeo-Core-Factories, DrGeo-Item-Models, DrGeo-Item-Views will rendered in
>>    the hierarchy as *DrGeo-App* (not sliced as only one sub),
>>    *DrGeo-Core*>Builders, *DrGeo-Core*>Commands, *DrGeo-Core*>Factories,
>>    *DrGeo-Items*>Models, *DrGeo-Items*>Views
>>
>>    So, the left pane of the browser will looks like below when all
>>    subcategories folded:
>>    *> Morphic*
>>    *   DrGeo**-App*
>>    *> DrGeo-Core*
>>
>>
>> *> DrGeo-Item *and it unfolds as:
>>    *v Morphic*
>>          Kernel
>>          Events
>>    *DrGeo-App*
>>    *v DrGeo-Core*
>>          Builders
>>          Commands
>>          Factories
>>    *v DrGeo-Item*
>>           Models
>>           Views
>>
>>
>> *Second scenario.* You slice at the first category. The direct result,
>> will be a much smaller list in the category pane of the Browser. It will
>> give a better thematic view of what inside the image, without the noise of
>> the subcategories. But when you want to go deep, it requires a few more
>> click to unfold the contents.
>>
>> With the previous example, the folded categories will render as:
>>
>> *> Morphic*
>> *> DrGeo*
>>
>> And when unfolded:
>>
>> *v Morphic*
>>       Kernel
>>        Events
>> *v DrGeo*
>>        App
>>        Core-Builders
>>        Core-Commands
>>        Core-Factories
>>        Item-Models
>>        Item-Views
>>
>>
>> Of course, in this second scenario, you still don't need to slice an
>> isolated package Color-Extras
>>
>> *Conclusion.*
>>
>> May be the latter, for beginners, will be easier to get the grant vision
>> of the Cuis system. Also it is closer to the idea of namespace, matching
>> cognitively our representation of the image contents. The main drawback of
>> this scenario is that for one given top category, you don't reduce the
>> number of subcategories. Observe, when you unfold DrGeo, the number of
>> subcategories is the same as originally; under this perspective the former
>> scenario is a more pragmatic option.
>>
>> Other may have additional opinions.
>>
>> Hilaire
>>
>>
>> Le 08/01/2022 à 10:46, Luciano Notarfrancesco a écrit :
>>
>> Hi Hilaire, all,
>> Here's a starting point for experimentation. I made this over a year and
>> a half ago, but it seems to work on the latest Cuis. Anyway, it might need
>> tweaking before it is useful, let me know what you think. I don't like very
>> much that I had to add a SystemCategoryWrapper class, I kind of hate adding
>> classes to the base image. Another thing I don't like very much is that if
>> you click on a node that is not an actual system category (for example you
>> click on 'Kernel' that doesn't exist as an actual category) no classes are
>> shown, and that forces you to expand it and click again. Also, look at
>> Browser>>#systemCategoryTreeRoots, originally I showed namespaces between
>> brackets, maybe we can use brackets to show packages (for example, in DrGeo
>> it would show a '[DrGeo]' node to denote that all those subcategories and
>> classes belong to the 'DrGeo' package).
>>
>> --
>> GNU Dr. Geohttp://drgeo.euhttp://blog.drgeo.eu
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220108/7aeac0fb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5042-HierarchicalSystemCategories-LucianoEstebanNotarfrancesco-2022Jan08-15h05m-len.001.cs.st
Type: application/octet-stream
Size: 13991 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220108/7aeac0fb/attachment-0001.obj>