[Cuis-dev] FileOutRework and personal introduction.

Mauro Rizzi mrizzi at fi.uba.ar
Wed Dec 2 13:37:00 PST 2020


Thank you Juan,

I've taken all of your advice in the development of the FileOutRework
package (which I now consider feature complete) but at this point i'm
specifically asking about the changeset I'm sharing with you so you can add
the features you think should be in the base image and I'm getting lost in
the chain of emails at this point so i'll do a list of questions:

1) I'm working under the concept that you only want to have the base
fileOut option do what my current fileOutTo option does. That is, to ask
the user where they want to fileOut to while recommending the last
directory they filed out to. Is this correct?
2) You want this to basically apply for all fileOut implementations on the
base image correct? (This would apply to ChangeList, ChangeSet, Classes,
method and system Categories, Methods, CodeFile, PseudoClasses, PseudoClass
categories and PseudoClass methods).
3) What do you think of having the save option of the package manager have
the same behaviour? This would allow saving packages wherever you want (and
the version tracking doesn't break).

I await your feedback to finish up the changeset with the features you
think should be included (and fixing a couple of bugs I found along the way
since the last changeset).

Also I'm sorry if I'm asking too many questions but it's my first time
coding for someone!

Kind regards,

*Mauro Rizzi*

El mié, 2 dic 2020 a las 17:44, Juan Vuletich (<juan at jvuletich.org>)
escribió:

> Hi Mauro,
>
> If you prefer to have the additional menu options, then your previous
> version was ok in my opinion. It is nice optional goodie to be loaded by
> those who want it.
>
> Cheers,
>
> On 12/1/2020 6:22 PM, Mauro Rizzi via Cuis-dev wrote:
>
> 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
>>
>>
>
> --
> 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/20201202/522e362e/attachment-0001.htm>


More information about the Cuis-dev mailing list