[Cuis-dev] [IMPROV] Ups I did it again: TimeProfileBrowser in Compiler

Philip Bernhart philip.bernhart at posteo.de
Sat Jun 26 08:09:13 PDT 2021


Hi,

my 0.02 EUR to that topic is that there are not just
"tools" which are in need to be registered. But also
other things like URI schemes, filetypes, etc.

I started to write a registry in the "URI kernel"
project I have on github:

https://github.com/Phantasus/Cuis-Smalltalk-URI-Kernel

also there is a need to register "new" CBOR tag extensions:

https://github.com/Phantasus/Cuis-Smalltalk-CBOR

all of these need some kind of a system registry and I
wonder if the "best" is to use a similiar Cuis specific
"registry model" or should each part have their specific
homegrown registries?

Should Cuis provide an abstrac baseclass for this like "Registry"
and each specific subclassed registry implements it in their own way?

I haven't yet pondered enough about that topic. On one way you
want to bind it do a Smalltalk system on the other hand you want
to be as independent as reasonable possible, so that it can evolve
freely from version to version in an external package.


Cheers,
Philip

Gerald Klix via Cuis-dev <cuis-dev at lists.cuis.st> writes:

> Hi Juan, Hi folks,
>
> On 6/25/21 5:28 PM, Juan Vuletich via Cuis-dev wrote:
>> Hi Gerald,
>> 
>> On 6/19/2021 11:12 AM, Gerald Klix via Cuis-dev wrote:
>>> Hi all, Hi Juan,
>>>
>>> I also added the TimeProfileBrowser to
>>> Compiler>>#evaluateSelectionAndDo:ifFail:profiled: .
>>>
>> 
>> Thanks! Just pushed both to GitHub.
>> 
>>> BTW:
>>> We should improve discoverability in Cuis.
>>> Now more than 2 and a half years have passed,
>>> that you added me as a Cuis developer,
>>> but it took (me) til yesterday, until I discovered
>>> this TimeProfileBrowser class.
>> 
>> Yes. Indeed. We'd replace the "Open" World submenu with a better thought 
>> "Tools" menu. Maybe with a few submenu levels, and checking that all the 
>> included tools are there. There should also be some kind of registry, so 
>> packages can add additional tools.
> That is a more Cuis-like solution than my proposal.
>
> What I would really love to have is some facility,
> that provides some means to add tools that are implemented
> in packages that in turn are filed in upon request.
> Scanning the filesystem upon menu-creation is
> not an option. One old hard-disk/NAS,
> like my old time-capsule, will block the menu
> for at least 10 seconds until the disks have spun up.
>> 
>> Any takers?
> I am rather reluctant to say yes.
> I have the tendency to over-engineer solutions.
>
>
> Best Regards,
>
> Gerald
> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev

-- 


More information about the Cuis-dev mailing list