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

[Gerald Klix]

Hi Juan,

sorry for the long delay, I caught a rather nasty cold.

First and most important:
*Thank your for your work!*

Second and less important:
Haver's image saving problems are gone with Cuis Version 6.2 and 6.3.
There are some minor issues like

  * a different order of menu items in the preference menu (trivial to fix)
  * font loading, the TrueTypeFonts directory is not found in my setup
    (easy to fix)


For the remainder, please see my inline comments.


Best Regards,

Gerald



On 12/22/23 1:30 PM, Juan Vuletich wrote:
> 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.
IC, to describe the situation in German: „Einen Tod muß man sterben.“, 
meaning you have to choose one evil.

I can only think of one – rather nifty – improvement:
Add two preference menu options like:

'Save preferences globally'
This one selects the currently implemented behavior.

'Save preferences only in image'
This one implements the old behavior.

Both will be persisted in UsersPrefs.txt. The later
serves as a flag, that means: Ignore every other setting in 
UserPrefs.txt and
stick to the settings that are already persistent in the image.
>
>> 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.
Please see below, keyword 'Image management application'
>
>>>
>>>>
>>>>> ...
>>>> 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.
Nice, I tried such a thing for two of my daughters individually and two 
of my sons.
I failed miserably.
I hope you are better at teaching, than I am!
>
>>>
>>>> ...
>>>
>>> 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!
IC.
>
>>>
>>>> ...
>>>
>>> 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.
I will look at these options, when I fix Haver's font loading issues.
>
>>
>> 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...
Suppose you want to write a maintenance application
for images – something I am contemplating for years – a straight
forward solution is to use directories in the filesystem to structure
a given set of tuples of image and change files. The current solution
forces the maintenance application to copy (or symlink)
UnicodeData.txt  and the file with the compressed sources.

How about an 'image (related) data directory', that
contains all that stuff? There should be command line options similar
to those implemented for the userBaseDirectory.

The TrueTypeFonts directory seems to be already relative to the 
userBaseDirectory,
which is, IHMO, is the best solution.
>
>>
>>> ...
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231230/0306e617/attachment-0001.htm>