Tooltips don't work if the stack is not active?

[jacque]

I found it more interesting that you can right click on a mainstack, and change it to any other type, but you can't do the same in reverse if it is a palette heh.

Show contextual menu in run mode:

Code: Select all

Mac	command+shift+control+click
Windows	control+shift+right click

Works on any stack mode.

[mwieder]

Code: Select all

linux    Nope

[bogs]

@ Jacque - Hee hee, I'm sorry, I probably should have written that a LOT more clearly Jacque

I was referring to the dev environment, in browse mode, i.e. -

Browse mode right click and....

...where as with a stack you have just changed to a palette, such as this, you could right click till your finger drops off....

Wait for it...wait...oh darn!

and nothing happens, nor did I expect it too. There are, of course, a few different ways to do it, and yours is as good as any of the others, unless you're a 'nixer (like Mark or myself)

[jacque]

Code: Select all

linux    Nope

Oh you Linux guys. Sorry about that. But I'm glad it brought Bogs back out of the shadows.

I know zero about Linux except what I've read here, but maybe the behavior would depend on the window manager you're using? If that's a stupid question then feel free to laugh.

[mwieder]

Not at all. Correcting myself, shift-control-alt-right-click on linux does indeed bring up a contextual menu for stacks in run mode. I was previously testing that out on a palette stack that explicitly prevented that combo.

[bogs]

But I'm glad it brought Bogs back out of the shadows.

Heh, not so much was in the shadows, just under a heavy school workload and moving a LOT of stuff around. Not quite back yet, but at least I have time to look once in a while now, and thank you for being glad

Want to say thanks to Richmond as well, while I'm thinking about it, had a very nice note from him while I was buried

shift-control-alt-right-click on linux does indeed bring up a contextual menu for stacks in run mode.

maybe the behavior would depend on the window manager you're using? If that's a stupid question then feel free to laugh.

Not stupid at all, and a lot can depend on the Wm and Dm your using in 'nix world. Things that I can never get to work work fine for Mark, mostly because I use XFCE and or MATE (among others), and I don't believe he does. I will *not* use Gnome anymore, even though it was my primary desktop for many years before the last iteration. Same for KDE, but for different reasons.

In any case, the basic command structures, where it relates to key strokes and mouseclicks *do* tend to be the same for the most part**.

**YMMV, DON'T drink the kool aid, pay your taxes where applicable, don't feed the bears, and as far as I know, no spotted owls were harmed during the creation of this post

[Monox18]

I want to close the original question that I asked saying that is true that tooltips don't work in a window (stack) that is not active. They only work in the current active Window. What is also true is that you have some degree of control over which window is active.

The way I understood window activity by default was only with mouse clicks. This was before asking the question and reading some of the answers specially FourthWorld's insight about the mode system. Now from further testing I saw that window activity is also changed by script (which is mostly unexpected to me).

To figure out who is the active window and when does it changes, I used loging functions in the command ResumeStack and command suspendStack. Opening and closing a stack changes the activeness. I didn't expect that but it does make sense after thinking it for a while. Hiding/Showing a stack or setting it's visible property ON/OFF also changes the activeness. That's definitely not logical to me. Maybe there are other commands that change the activeness as well. Anyway, that's how the engine works I guess.

The way to recover the focus back on the main window (the stack where the script called and manipulated the palette substacks) was to put a callback (send "MyCommand" to me in X milliseconds) with the line:

Code: Select all

go to me

As redundant as it sounds, it works. It returns the focus back to the caller script without triggering any card navigation or message. Also be aware that if you are in a mode where the window title is visible (I suppose menubar in Mac) there will be some subtle flashing from active to inactive and back to active. But it doesn't affect the User Experience so it's fine. Also this is not visible if you are in full screen mode or title decorations are off. I suppose this will be also fine for mobile.

In conclusion, even if the default LC behavior is occasionally a bit unexpected, it can be tweaked enough to make it work as expected which is really good.