[Cuis-dev] PreferenceBrowser tool

Mariano Montone marianomontone at gmail.com
Fri Jun 16 11:14:47 PDT 2023


How about we create an Cuis-Smalltalk-Extras repository in 
Cuis-Smalltalk github organization, and also add it to the list of repos 
cloned and updated via clonePackageRepos.sh and pullAllRepos.sh ?

I think it would reduce the friction of what to add or not to the main 
Cuis repository, while at the same time making those packages available 
and ready to use for the Cuis user.

I could leave my package in its bitbucket repository, but it feels like 
it is floating around. Even add to the PackageDownloader list, but it is 
still not the same. By adding to that Cuis-Smalltalk-Extras I get my 
package easy to install and without the friction of potentially adding 
to main Cuis repo.

As another example, I have a Popup-Cuis-Finder package that is based on 
a Cuis-Finder package that I'm not the author of. I run into problems 
when I tried to include into main Cuis repo. But with the extra 
repository, I could add there and there would not be a problem.

Perhaps there won't be many packages there at this moment, and so I'm 
not sure if its creation is justified, but I think it could be something 
to consider.

Thoughts?

Mariano



El 16/6/23 a las 09:51, Luciano Notarfrancesco escribió:
> I think it’s a good idea to do that. It’s good to have different 
> implementations of things instead of merging everything into one 
> single implementation. The modularity of using packages allows us to 
> explore different approaches to UI. I think at some point we should 
> make packages for other tools, including the basic tools like the 
> browser, workspace, inspector, etc, and remove them from the core 
> image. Then we could still have releases with preloaded “default” 
> packages that you can use for development out-of-the-box without doing 
> any package installations, but at the same time we’d have more freedom 
> to make our own customized tools, and we could have both very simple 
> tools (that could be a good starting point for someone wanting to 
> customize and extend tools according to their preferences) and 
> alternative more complex tools that include a lot of functionality 
> already.
>
> I think there’s no need to rename it either, PreferenceBrowser is a 
> good name and I don’t think there’s the need to have both packages 
> loaded at the same time. Just my opinion, tho.
>
> On Fri, 16 Jun 2023 at 14:29 Mariano Montone via Cuis-dev 
> <cuis-dev at lists.cuis.st> wrote:
>
>     El 15/6/23 a las 12:20, Hilaire Fernandes escribió:
>>
>>     We should find a way to merge our work for the better. I am a bit
>>     busy right now though.
>>
>     We should, but still, I would like to rename my tool to
>     CompactPreferenceBrowser and include it as an extra optional
>     package in Cuis.
>
>     Otherwise, I feel like my work goes to waste.
>
>     The same way there's the FileList tool and also the FlatFileList
>     that provides some different properties. And there's no problem
>     with their co-existence.
>
>     In this case, the CompactPreferenceBrowser is a bit more compact
>     visually and also fits in one package as I'm trying to build it on
>     purpose with as few extra widgets as possible, reusing Cuis
>     widgets provided in Core and shipping in a package with no
>     dependencies.
>
>     Is that fair?
>
>
>     Mariano
>
>     -- 
>     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/20230616/476b60a9/attachment.htm>


More information about the Cuis-dev mailing list