rowett wrote: ↑April 8th, 2024, 3:05 am
If you modify and save the pattern then the rule is maintained since it's still in the comments.
Aha, that seems like a key point. Modifying then saving a pattern seems like it will be an important use case. Persisting the rule in the comments seems to handle that.
Copying a piece out of a pattern and opening it in a new layer seems like another important use case... but there I think we might run into a problem. Copying a selection from a pattern currently doesn't copy the comments, and I'm thinking it probably shouldn't -- it's way too easy to end up propagating irrelevant information into new mostly unrelated patterns. But if the @RULE section at least doesn't copy over, then we can end up with patterns in different Golly layers that are using the same base rule name, but they're actually running different rules.
Maybe one of them will be displayed as "GenericRule_TRANSIENT" and the other one (the copied selection) will just show up as "GenericRule".
That still seems quite painful and awkward, in practice. In 99.9% of cases, "GenericRule_TRANSIENT" will in fact be identical to "GenericRule". The GUI will be drawing a distinction when in fact there is no difference -- and this is a case where it would be good for the user to know that there is no difference, and really really good for the user to be made aware that there
is a difference, in the 0.1% of cases where a local rule actually doesn't match a transient rule.
See the "
Can we give users a useful new tool?" section below for more about this.
confocaloid wrote: ↑April 8th, 2024, 2:16 am
If I understand right, it is currently impractical to reimplement support for self-contained patterns (with @RULE data appended to the pattern data, equivalent to the existing support in LifeViewer) in Golly using just a script.
It makes sense to aim for equivalent functionality in Golly and LifeViewer, whenever some functionality is supported in both.
This is also a key point, I think!
My question is, is it even theoretically possible to ever end up with equivalent functionality in Golly and LifeViewer, as far as rules are concerned?
Golly has a local rule store, so it works when there is no Internet connection. LifeViewer has no local rule store, so it depends on an external central repository for anything that isn't natively supported.
We could support equivalent functionality by taking the local rule store out of Golly. But that's a significant loss of functionality. It seems unlikely that we're going to do that... We could get close to equivalent functionality by enabling automatic LifeWiki rule lookups in Golly, whenever the Internet is in fact available -- but we'd still end up having a lot of the same tricky questions to deal with, related to the local rule store.
confocaloid wrote: ↑April 8th, 2024, 2:16 am
Hence I think it is better to admit that Golly does not currently support @RULE data appended to the pattern data, and avoid any processing of the appended @RULE data (if any). The Golly user will still be able to install the rulefile manually from the pattern comments, in those cases when they want to do so.
This is a good point about installing manually. The rule in the pattern comments is currently in a format where it can be selected and copied out of the comments, and Ctrl+Shift+O will immediately install that rule. We've been reasonably happy with that functionality so far.
However, that's definitely functionality that works fine for experts, but new Golly users tend to not know about it, and they really don't have any likely path to find out. First there's the hurdle of figuring out about opening the pattern comments in the first place, and maybe scrolling way down to find the otherwise invisible @RULE section, and knowing what it means. Then the fact that File > Open Clipboard easily installs new rules as well as opening patterns... is not at all obvious from the current GUI. To fix that we'd have to change the menu to say something like "Open Clipboard (Pattern or Rule)".
Possible side effects of transient rules
I think that the local rule store in Golly is a useful feature, so we need to keep supporting that.
I'm a bit worried that having rules start traveling with patterns more often will produce one of two unfortunate side effects:
1) if transient rules are implemented in Golly with no attempt to reconcile the transient rules with stored local rules, then that will enable the proliferation of extremely confusing rule variants, where it very quickly becomes almost impossible to figure out what is (if anything) is intended to be different between patterns that are getting shared with the same rule name.
This happened most recently with the "B-Univ" rule: b-engine made various changes to the rule behind the scenes that
broke some existing published patterns but fixed others. "B-Univ" development also brought up the tricky question of how to distinguish rules
intended to be throwaway or experimental from rules that are intended to have permanent names associated with published patterns.
There were also some really tricky maintenance nightmares back in the days of "
shapeloop rule" development. (The renaming to "shapeloop3" in the linked post was badly needed, for example, and involved a lot of confusion and mysteriously broken older posted patterns before it all got sorted out. There might still be some threads back there with patterns that no longer work as intended.)
These cases are worth thinking very slowly and carefully about, because they really did happen, and they weren't easy to fix. I agree that having the rule travel with each pattern might
theoretically solve a lot of these cases. But it still seems possible that an implementation of throwaway transient rules in Golly might make similar confusions more likely to happen in the future (because non-uniquely-named rules will be able to proliferate a lot more easily) ... even though the intention is to make confusion
less likely.
2) If we provide an option to update Golly's stored local rules using rules from pattern comments, then we're going to start being presented with choices that aren't really choices -- we'll end up getting asked something equivalent to "Do you want to replace the existing rule with the version in the [clipboard|pattern comments]?"
in the 99.9% of cases where the existing rule is identical to the "new" version.
Can we give users a useful new tool?
From the point of view of usability, it seems really important to me to reserve that "Do you want to replace..." question, for cases where the replacement actually makes a difference. Maybe we can even give users a better idea of what the difference is.
We can easily check if the rule we're proposing to replace is character-for-character identical with the new rule that we're considering replacing it with. A lot of times it will be.
In that case, there's no point in asking about replacing anything -- it works fine to just let the user know that the rule in question is already installed (probably via the status bar, without a pop-up needed). That will get rid of a lot of annoying pop-ups while giving really useful information to the user -- an ongoing confirmation that there's no possibility of rule confusion.
When there _is_ a difference between rules, the user might want the new version, or might want to keep the old version -- but they might not know which. Most commonly they won't want to lose information. They might want whichever version has more up-to-date comments, or maybe a @COLORS or @ICONS or @TREE section that the other version of the rule is missing.
In that case, a side-by-side comparison of the two rules would be extremely handy. That's something that Golly doesn't currently provide. But it might be possible to provide it, even with our current Lua-script approach -- e.g., via a three-way choice:
"Replace? Yes / No / Display comparison".