[Cuis-dev] PreferenceBrowser tool

[Mariano Montone]

Hi,

I've just added CompactPreferenceBrowser and PopupFinder tools to the 
Cuis-Smalltalk-Tools repo.

😁

Thank you all!

     Mariano

El 16/6/23 a las 16:03, Juan Vuletich escribió:
> 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/8812870f/attachment.htm>