Skip Navigation
Perchance - Create a Random Text Generator @lemmy.world starrymoonbow @lemmy.world

[Help] plugin conflict between locker and tooltip

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!

8
8 comments

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

    • right, but i found that this runs into another problem: any randomized features within the locked selection remain randomized and can change upon update attempts, rather than being properly locked.

      i've made a second generator to showcase this in action: https://perchance.org/locker-tooltip-conflict-example-two#edit

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

8 comments