<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">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 <ul> <li>a different order of menu items in the preference menu (trivial to fix)</li> <li>font loading, the <tt>TrueTypeFonts</tt> directory is not found in my setup (easy to fix) </li> </ul> For the remainder, please see my inline comments. Best Regards, Gerald On 12/22/23 1:30 PM, Juan Vuletich wrote: </div> <blockquote type="cite" cite="mid:65858148.9040904@cuis.st">Hi Gerald, On 12/22/2023 6:44 AM, Gerald Klix via Cuis-dev wrote: <blockquote type="cite">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. </blockquote> 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. </blockquote> 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 <tt>UsersPrefs.txt</tt>. The later serves as a flag, that means: Ignore every other setting in <tt>UserPrefs.txt</tt> and stick to the settings that are already persistent in the image. <blockquote type="cite" cite="mid:65858148.9040904@cuis.st"> <blockquote type="cite">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. <blockquote type="cite"> <blockquote type="cite">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 ;-} (<a class="moz-txt-link-freetext" href="https://lists.cuis.st/mailman/archives/cuis-dev/2023-October/008099.html">https://lists.cuis.st/mailman/archives/cuis-dev/2023-October/008099.html</a>) </blockquote> 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. </blockquote> IHMO it will make sense for non version controlled Cuis distributions, like CuisUniversity or Haver. </blockquote> Sure. Their maintainers are welcome to do so. </blockquote> Please see below, keyword 'Image management application' <blockquote type="cite" cite="mid:65858148.9040904@cuis.st"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">... </blockquote> 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. </blockquote> 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) </blockquote> 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. </blockquote> 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. </blockquote> 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! <blockquote type="cite" cite="mid:65858148.9040904@cuis.st"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">... </blockquote> 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. </blockquote> 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. </blockquote> 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! </blockquote> IC. <blockquote type="cite" cite="mid:65858148.9040904@cuis.st"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">... </blockquote> 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. </blockquote> 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. </blockquote> That makes sense. </blockquote> I will look at these options, when I fix Haver's font loading issues. <blockquote type="cite" cite="mid:65858148.9040904@cuis.st"> <blockquote type="cite"> 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) </blockquote> I haven't found a better place... Perhaps TrueTypeFonts/ ? Mhhh... </blockquote> 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) <tt>UnicodeData.txt</tt> 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 <tt>userBaseDirectory</tt>. The TrueTypeFonts directory seems to be already relative to the <tt>userBaseDirectory</tt>, which is, IHMO, is the best solution. <blockquote type="cite" cite="mid:65858148.9040904@cuis.st"> <blockquote type="cite"> <blockquote type="cite">... </blockquote> 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. </blockquote> 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. </blockquote> </body> </html>