[Cuis-dev] [Ann] First sketch of Cuis 6.1 release - Please REVIEW and TEST!

[Juan Vuletich]

Hi Gerald,

On 12/22/2023 6:44 AM, Gerald Klix via Cuis-dev wrote:
> Hi Juan,
>
> still one hour left to answer your mail.
>
> I discovered that Cuis now automatically creates a UserPrefs.txt
> file. I am not sure whether this is really clever.
> I faintly remember some support cases, where you directed
> users to delete that file, because their changes where not persisted
> in their images. Now it is persistent, but all images use the same 
> settings.
> Users accustomed to the old behavior will be baffled.

When there was no prefs file, people would be annoyed by the need to 
save the image to keep their preferences, and their preferences being 
lost when a new image was published.

When I added the file, people would get annoyed that whatever they chose 
with the Preferences menu was not persisted, even if they saved the 
image. Needing to edit an external file when there was a Preferences 
menu made no sense.

What I did is to create the file automatically when you change a 
preference (but only for GUI size, ANSI/ST-80 assignment, and 
ClickToFocus). Your preferences persist regardless of saving the image 
or not, and you don't need to edit the file by hand.

If someone prefers to have #userBaseDirectory tied to the main Cuis 
folder, they can use the -udIsBase command line argument, as I said in 
another email yesterday.

Changing behavior is not a problem, especially if the new behavior is 
more comfortable and more flexible than the old one.

> Please don't get me wrong, personally I can live with that change,
> but it's just another feature that needs to be documented, explained
> and supported (by answering questions).
>
> Please see below for my answers.
> ...
> Fair enough. The script needs bash and sudo; it should be replaced by 
> something simpler.
>>> Maybe a simple image, like your hello world demo, that starts the 
>>> actual image is better.
>>> This approach would be a clear case of eat your own dog-food ;-}
>>> (https://lists.cuis.st/mailman/archives/cuis-dev/2023-October/008099.html) 
>>>
>>
>> I don't see the need for an "official" way to do that. Expert users 
>> can set up their environment as they prefer. In other words, that's a 
>> nice idea, but doesn't need to be part of the Cuis core. More like a 
>> community developed optional feature / workflow. We'd need to be sure 
>> that Base Cuis supports those developments, by making them possible.
> IHMO it will make sense for non version controlled Cuis distributions, 
> like CuisUniversity or Haver.

Sure. Their maintainers are welcome to do so.

>>
>>>
>>>> ...
>>> I would love to have the Cuis checkout separated from my project. 
>>> Additionally It should
>>> be possible to reuse the checkout for more than one project.
>>
>> Some people already asked for handling more than one Cuis folders 
>> (including image, etc) for one project. Others, like you want the 
>> opposite: use a single Cuis folder for several projects. So we need a 
>> way to support these different scenarios. (see below)
> For Unix, it should be easy to distribute a shell script that creates 
> symlinks to all of the repos
> in an the current directory. I don't see a portable solution for windows.

Again, the main distribution should be especially friendly for novice 
and casual users. To me, this also means to try to avoid stuff that is 
too complex for them, and that experts can do by themselves easily.

It also means to try to give a platform agnostic experience. For 
instance, right now, I'm doing a kind of introductory curse to CS for my 
daughters and a few friends (teenagers and young adults). I prepared a 
bunch of thumbdrives with this very Cuis setup. They bring a mix of 
Windows, Intel and ARM Mac, and Linux laptops. This works on all of them 
without needing to waste their attention on irrelevant technicalities. I 
like that, and I think it reflects the kind of experience most novices 
will have.

>>
>>> ...
>>
>> One point to have in mind is that inside the Cuis repo directory, no 
>> files from other repos should be stored. The reason is that most 
>> users would no longer know what is part of the Cuis distribution and 
>> what is not.
> I forgot about that point, because I created a bunch of symlinks to 
> the git repos in the parent directory
> of Haver's development directory.
>
> I also became aware, that I am looking at this layout from a different 
> perspective:
> I am thinking of distribution contained in a ZIP-file, without any 
> version controlled files.
> So yes, If you want to distribute this using git, not polluting the 
> repo with user files
> makes perfect sense.

And still I also want a good experience for people downloading the Zip 
file that GitHub generates automatically, for people who don't need or 
want git. A lot of use cases and details to keep in mind!

>>
>>> ...
>>
>> What follows is very new, and not yet documented:
>>
>> #userBaseDirectory: Directory for user generated files.
>> #cuisBaseDirectory: Usually repo. Common parent of 
>> #smalltalkImageDirectory, CoreUpdates/ and Packages/.
>> #projectBaseDirectory: #cuisBaseDirectory parent.
>>
>> #userBaseDirectory is configurable via commandline:
>>
>> No additional argument
>> DirectoryEntry userBaseDirectory. 
>> /Users/juanvuletich/Cuis-Smalltalk/Cuis-Smalltalk-Dev-UserFiles .
>>
>> -udIsBase
>> DirectoryEntry userBaseDirectory. 
>> /Users/juanvuletich/Cuis-Smalltalk/Cuis-Smalltalk-Dev .
>>
>> -ud ZZZZ
>> DirectoryEntry userBaseDirectory. 
>> /Users/juanvuletich/Cuis-Smalltalk/Cuis-Smalltalk-Dev/ZZZZ .
>>
>> -ud ../ZZZZ
>> DirectoryEntry userBaseDirectory. 
>> /Users/juanvuletich/Cuis-Smalltalk/ZZZZ .
>>
>> -ud /Users/juanvuletich/ZZZZ
>> DirectoryEntry userBaseDirectory. /Users/juanvuletich/ZZZZ .
>>
>> Packages are looked for in the #projectBaseDirectory. Perhaps we 
>> could make this configurable via cmdline argument too.
> I have seen some of these changes in Cuis 6.0, AFAIR I had to adapt 
> Haver's image saving code to it.
> I will look into this after my holiday.
> I should adapt Haver's persistent stuff, like persistent workspaces, to
> use DirectoryEntry>>#userBaseDirectory for it's OODB files.

That makes sense.

>
> One side issue: Is there any way to move UnicodeData.txt away from the 
> image directory?
> Users may be tempted to clean up their image directory and delete non 
> image/changes stuff,
> with rather disastrous results. (After some hair-tearing I created a 
> symlink to this file in Cuis' repo,
> to make Cuis work again in Haver's project directory)

I haven't found a better place... Perhaps TrueTypeFonts/ ? Mhhh...

>
>> ...
> Now that I have slept over this, I think it comes in handy
> for Haver. As mentioned in various mails, I modified OSVM's Linux version
> to handle additional mouse-buttons and some other things.
>
> I will distribute my VM version as HaverVM.app, using
> the MacOS APP directory layout.

Makes sense. Check the Info.plist file, where there is a line that 
references to 'CuisImage/Cuis6.1.image'. This is used to find the image 
file if you just click on the .app "file" on a Mac. You'd need to change 
this to point to the Haver image. So, calling it Haver.app or 
HaverVM.app is reasonable.

BTW, in an older experiment I also included the image / changes / 
sources as part of the .app structure, like Squeak's All-In-One. Played 
with that and didn't like the image and chages to be so "hidden". But a 
single structure for the included VMs is something I do like.

>> .
>> ...
>
>
> Best Regards,
>
> Gerald

Cheers,

-- 
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