[Cuis-dev] FileOutRework and personal introduction.

Tue Dec 1 13:22:46 PST 2020

Hello Juan,

I did as you suggested and replaced the original fileOut methods with the
previous fileOutToNewDestination methods.

However I feel this means as a user you lose the ability to batch fileOut
stuff. As in you can't do Class fileOut without actually pressing enter in
the text box asking for the destination (This is why I originally made it a
separate method on all instances, well this and what you said about
avoiding redefining methods).

Personally I only fileOut through context menus, but if someone needs to
make some sort of interface that batch files out stuff they'll have to
modify these methods or make new ones for their particular use.

I've also implemented it for ChangeSets, PseudoClass and, as you requested,
CodeFileBrowser (It's easier when I don't touch the menu options haha).

I'm sitting on the fence about implementing it for package saving too, not
sure if that would break the version tracking or not.

Also how would you feel about giving the user a "Operation was successful"
confirmation pop up after the fileOut was done? Or do you feel it's
unnecessary?

Looking forward to your feedback!

Cheers!

*Mauro Rizzi*

El mar, 1 dic 2020 a las 15:53, Juan Vuletich (<juan at jvuletich.org>)
escribió:

> Hi Mauro,
>
> I think Utilities is a better place than SystemDictionary for that kind of
> stuff. SystemDictionary should only contain stuff that is core to Smalltalk.
>
> I'd change something, though. Instead of adding new methods with the
> 'ToNewDestination' suffix, I'd just modify the existing methods, avoiding
> bloat and duplication. I'd also do the changes in CodeFileBrowser, for
> consistency.
>
> Cheers,
>
> On 11/29/2020 12:32 AM, Mauro Rizzi via Cuis-dev wrote:
>
> Hello Juan!
>
> I've actually been looking back at the code I shared in the changeset and
> except for the updateWorkDirectoryFromFileStream: method it looks OK to me.
>
> Have you had any time to take a look?
>
> I'd love to hear some extra feedback, as it is I'm not sure if the
> currentWorkDirectory should be contained in the Utilities class. Maybe it
> would make more sense for it to be part of the Smalltalk system dictionary?
>
> Kind regards,
> *Mauro Rizzi*
>
> El mar, 24 nov 2020 a las 11:16, Mauro Rizzi (<mrizzi at fi.uba.ar>)
> escribió:
>
>> Hello Juan,
>>
>> I found some time and made the changeset with your recommendations.
>>
>> I would like to add that the code still is a WIP and requires some work
>> but the expected behaviour is there if you want to test how it feels!
>>
>> Kind regards,
>> *Mauro Rizzi*
>>
>> El mar, 24 nov 2020 a las 10:29, Mauro Rizzi (<mrizzi at fi.uba.ar>)
>> escribió:
>>
>>> Hi Juan,
>>>
>>> In that case I would have to replace the regular fileOut subMenu option
>>> to use the current fileOutTo implementation, I could make sure to  only add
>>> the necessary methods for fileOutTo to work so that the only direct change
>>> to the base code is the change on the message that the submenu uses for
>>> fileOut.
>>>
>>> I do feel having to use the fileOutTo option at all times takes away a
>>> bit of the ease of use fileOutRework was intending to implement, since the
>>> destination confirmation dialogue box doesn't autofocus itself when
>>> created, so as a user you'd still have to mouse over it or click on it
>>> (depending your focus mode) to be able to press enter and confirm the
>>> fileOut (even if you had no intention to pick a new destination).
>>>
>>> The point of fileOutRework was to remove all the nuance in fileOut heavy
>>> workflows.
>>>
>>> But I could easily make the changeset file that only does what you
>>> recommend and keep the fileOutRework package as my own project not intended
>>> to be in the base image.
>>>
>>> I would like to have more opinions on the matter before moving on
>>> however.
>>>
>>> Kind regards,
>>> *Mauro Rizzi*
>>>
>>> El mar, 24 nov 2020 a las 10:01, Juan Vuletich (<juan at jvuletich.org>)
>>> escribió:
>>>
>>>> Hi Mauro,
>>>>
>>>> Let me go back a little bit. If you want to keep your code as an
>>>> optional add on, I think it is quite good. The only thing I'd perhaps
>>>> change is to avoid redefinition of existing methods as much as possible,
>>>> because these are fragile, and will break if the code in the base image
>>>> changes.
>>>>
>>>> But if you want your contribution to be part of the base image (this is
>>>> reasonable, we want Cuis to be comfortable for users!), then keep in mind
>>>> that Cuis tries to be minimalist. We include all that is worth its own
>>>> weight, in terms of class and method count, lines of code, etc. This keeps
>>>> Cuis being a system that is easy to adapt and evolve. In this light, having
>>>> several menu options for essentially the same thing is what I called "a bit
>>>> too much". I'd rather prefer a single option on each menu, that suggests
>>>> the destination folder, and allows modifying it, and remembers it for next
>>>> time.
>>>>
>>>> Additionally, for code to become part of Cuis base image, we need to
>>>> save it in .cs.st changeset files, instead of a .pck.st package file.
>>>>
>>>> Thanks,
>>>>
>>>> On 11/23/2020 8:17 PM, Mauro Rizzi via Cuis-dev wrote:
>>>>
>>>> Hello Juan,
>>>>
>>>> The fileOutTo submenu option does exactly what you suggest.
>>>>
>>>> If you never use the fileOutTo option fileOut has the same behaviour as
>>>> the base image fileOut since the default fileOut location for my setup is
>>>> smalltalkImageDirectory (The same used for the original fileOut).
>>>>
>>>> My idea was that as a user you would do fileOutTo to the folder you're
>>>> currently working on, use fileOut normally in that folder until you need to
>>>> work on a different folder and then you'd do fileOutTo to that new folder
>>>> and continue on from there.
>>>>
>>>> However, if you think it's better to have the option to file out to the
>>>> image directory with a single button on the context menus I could change
>>>> the package so it keeps the original fileOut option and adds fileOut to
>>>> work directory and fileOut to new work directory as new options (So there
>>>> would be 3 fileOut options, the current smalltalk implementation,
>>>> fileOutToWorkDirectory and fileOutToNewDestination).
>>>>
>>>> Of course I would also add the corresponding methods across the system
>>>> so the fileOut method has the old implementation and my current fileOut
>>>> reimplementation would be renamed to fileOutToWorkDirectory.
>>>>
>>>> However i'm not sure if you wanted the current fileOutTo implementation
>>>> and missed the option or if you want to have the regular fileOut option
>>>> stay on the menu. I'd love to get further feedback on why you feel the
>>>> current implementation sounds a bit too much for you (So I can improve it!).
>>>>
>>>> Kind regards.
>>>> *Mauro Rizzi*
>>>>
>>>> El lun, 23 nov 2020 a las 17:33, Juan Vuletich (<juan at jvuletich.org>)
>>>> escribió:
>>>>
>>>>> On 11/18/2020 12:44 PM, Mauro Rizzi via Cuis-dev wrote:
>>>>>
>>>>> Hello everybody!
>>>>>
>>>>> My name is Mauro Rizzi and i'm currently studying Computer Engineering
>>>>> in the Engineering Faculty of the University of Buenos Aires.
>>>>>
>>>>> We're using cuisUniversity as an environment for one of our classes
>>>>> and I found current fileOut implementations to be counter productive to a
>>>>> good git workflow. The current idea of having fileOut always fileOut to
>>>>> image path means you either have to have your repository on your image
>>>>> folder or you have to manually move the file to your local repository
>>>>> folder.
>>>>>
>>>>> This is not conductive to making frequent commits but rather it
>>>>> results in us just doing a single giant commit at the end of the session.
>>>>>
>>>>> Because of this I set out to make a package that would streamline the
>>>>> user experience allowing for cuis to remember the last destination you
>>>>> filed out to and adding the option for the user to directly specify a new
>>>>> destination.
>>>>>
>>>>> You can find the package in my FileOutRework repository.
>>>>> <https://github.com/Mauro-Rizzi/FileOutRework>
>>>>>
>>>>> I've just started with this rework but I was encouraged by my teacher
>>>>> to share it with you, so far I've only implemented this behaviour for the
>>>>> Category list context submenus for the System browser.
>>>>>
>>>>> I'm open to any comments, criticisms or requests for collaboration.
>>>>>
>>>>> Hope you all have a nice week!
>>>>> Kind regards.
>>>>> *Mauro Rizzi*
>>>>>
>>>>>
>>>>> Hi Mauro,
>>>>>
>>>>> I agree that doing file out always an arbitrary tacit directory might
>>>>> be uncomfortable. Still, duplicating the file out menu options sounds s bit
>>>>> too much to me. Would a reasonable alternative be to include dialog with
>>>>> the full path+name in an edit box? The edited path could be remembered for
>>>>> suggesting it next time.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>>>>> @JuanVuletich
>>>>>
>>>>>
>>>>
>>>> --
>>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>>>> @JuanVuletich
>>>>
>>>>
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201201/a1beacce/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4386-CuisCore-MauroRizzi-2020Dec01-16h41m-MJR.001.cs.st
Type: application/octet-stream
Size: 8955 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201201/a1beacce/attachment-0001.obj>