[Cuis-dev] [IMPROV] Ups I did it again: TimeProfileBrowser in Compiler
Nicolás Papagna Maldonado
nicolas.papagna at gmail.com
Mon Jun 28 07:31:59 PDT 2021
Aloha folks,
In a related note to this thread, I've developed
https://github.com/npapagna/cuis-finder some time ago.
It's a spotlight-like tool for Cuis.
It allows plugging in different sources (Catalog subclasses) to augment the
stuff Finder searches on).
Please check the readme in the repo for more info, and let me know if you
have any questions!
Cheers,
Nico PM
On Sat, Jun 26, 2021 at 12:09 PM Philip Bernhart via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:
> 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
>
> --
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
--
Nicolás Papagna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210628/7231c523/attachment.htm>
More information about the Cuis-dev
mailing list