[Cuis-dev] PreferenceBrowser tool

[Juan Vuletich]

Hi Folks,

I agree with Luciano. The point of having packages is to give all us 
extra freedom. It is good to converge on a single implementation, but 
sometimes it's better to pursue several in parallel. Still, when 
possible, I prefer avoiding duplicate names, to reduce confusion for 
instance in emails, or ambiguity when doing `Feature require: 
'PreferencesBrowser'`. Calling it CompactPreferenceBrowser is ok.

Mariano, I agree that the best option is a new repo in the 
Cuis-Smalltalk organization. What about 'Cuis-Smalltalk-Tools' ? I 
believe that stuff in Cuis-Smalltalk-Dev/Packages/Tools and 
Cuis-Smalltalk-Dev/Packages/DevTools also belong there.

If people agree, I'm willing to create it, and grant write access to 
anyone asking.

Other possible reorganization could be to move OpenCL to its own repo.

Thanks,

On 6/16/2023 3:14 PM, Mariano Montone via Cuis-dev wrote:
> 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
>>
>


-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230616/79b99833/attachment.htm>