i’ve discovered that, using the locker plugin and the tooltip plugin, if you attempt to update locked text that has a tooltip, the tooltip stops functioning. oddly, the mouse continues to change to the hand, implying that the tooltip should be there even though it doesn’t show up.

here is a generator i made to showcase the conflict: https://perchance.org/locker-tooltip-conflict-example#edit

are the developers of these plugins active here? it would be really lovely if this conflict could be fixed somehow :0 thank you all in advance for reading and helping!

  • VioneT@lemmy.worldMEnglish
    1·
    4 months ago

    Seems like [locker("txt", text.selectOne)] works, it still has a tooltip even after pressing the randomize button.

    Using the [locker("txt", text)] doesn’t lock the selection since you are locking a list not a single item. [locker("txt", text.evaluateItem)] seems to lock the single item, but the ‘function’ of tooltip seems to not carry over.

      • VioneT@lemmy.worldMEnglish
        1·
        4 months ago

        What is being locked is the entire ‘unevaluated’ item (since we are using .selectOne). Unfortunately, evaluating the tooltip-plugin instances seems to remove the tooltip function. Which is why most of the time we are using the .evaluateItem so that only the ‘text’ and ‘evaluated’ string is saved, no more randomization, no more perchance syntax, etc, but it doesn’t work with the tooltip-plugin.

        Some explanations which might not explain really well.

        For the first one:

        1. You are selecting one item from the indirecttext list with indirecttext.selectOne.
        2. If the item selected is the [tooltip(...)] it would lock properly. This is because the item to be saved is just that item.
        3. If the item selected is the [text.evaluateItem]. It would save the [text.evaluateItem] which would then ‘evaluate’ its text, meaning it would randomize again. Which is why it isn’t locking, since what you have locked is [text.evaluateItem] which resolves into random items from the text list.
        4. indirecttext.selectOne -> then [text.evaluateItem], is selected, then, is locked. Upon randomizing -> locker gets the locked value, which is [text.evaluateItem] -> evaluates to any of items in the text list -> shows that the item is not locked.

        The item locked is only either [text.evaluateItem] or [tooltip(...)], the lock doesn’t propagate into its items.

        For the second one:

        1. You are selecting the [tooltip(...)]. In which case the whole [tooltip(...)] is locked.
        2. It re-randomizes since you are re-calling the [tooltip(...)] which would re-evaluate it, or create the tooltip again, in which it re-randomizes the {1-5} that you have to it.
        3. [tooltip("...{1-5}", "...")] -> … (random number 3) … -> clicked randomize -> recreates the saved [tooltip(...)] which means it re-selects the {1-5} upon display, which results it in not being ‘locked’ while it is locked.

        The item locked is:

          [tooltip("this text (random number {1-5})", "This tooltip will not become inaccessible, but the field will not properly lock.")]

        However, it doesn’t appear locked since the tooltip has a ‘randomization’ with {1-5} which are evaluated after.

        • starrymoonbow@lemmy.worldOPEnglish
          1·
          4 months ago

          yes, that is what i believe is going on behind-the-scenes. neither of the lockers have the issue if the locker is calling indirecttext.evaluateItem or alttext.evaluateItem. the issue i’m having comes from the fact that currently, it seems that it’s only possible to either keep the tooltip functional, or fully lock items including further evaluation; not both at the same time. ideally the two plugins would be able to offer their individual functions together without the conflict.

          • VioneT@lemmy.worldMEnglish
            1·
            4 months ago

            One thing you might be able to do is have a variable that is locked. Then use that variable to determine the tooltip to be used, separating the value from the tooltip entirely, so you can fix the value, then determine the tooltip needed based on that value.

              • VioneT@lemmy.worldMEnglish
                1·
                4 months ago

                Here is what I’m actually suggesting. https://perchance.org/roabyow92m

                You have separated the tooltip from being locked. Instead, you have an instance of a tooltip that is outside of the locker. Then, you have the locked store the locked value in a variable. Then use that variable to toggle what tooltip is to be shown on the tooltip instance.
                OR
                You only have one list, then have the tooltip text as a property of the item that you select (so that the value is specific to that item).
                OR
                You have a ‘template’ tooltip text, then only change the part in which would say the stored value.

                Since I don’t know how you’ve coded your lists, I can only blindly suggest how you could rewrite them. But I’ve added there some examples of how you could re-write it.