LiveCode Forums.

dunbarx wrote: Tue Mar 02, 2021 7:32 pm Been a long time since I used the "idle" message, but might this do: in the card script:

Code: Select all

on idle
   if the mouseLoc is  within the rect of this cd  then showYourPlugIns else hideYourPlugIns
end idle

This does nothing for you if you merely want to glance at the contents of the SE as opposed to actually working there.

Craig

Thanks, Craig, but i just need to hide plugins when the script editor window comes to the foreground, so i need to identify the state changes of the window itself, as i tried to do in the script above (#5).

paulclaude wrote: Thu Mar 04, 2021 10:13 am i just need to hide plugins when the script editor window comes to the foreground,
so i need to identify the state changes of the window itself

Hi Paul,

Here is a plugin (actually, I did edit the revExample.rev plugin for this purpose)
which will detect if the SE is open or closed.
See bottom-left label which is red or green according to the SE state.

You'll find on top of the stack script the modifications,
plus another one in the card script.




I've done this in less than 15 minutes; so might be that I forgot something;
please, let me know if this is the case.


Regards,
Thierry

Edited: please, go there for a new version of the plugin.
viewtopic.php?f=9&t=35478&p=203119#p203119

Thierry wrote: Thu Mar 04, 2021 1:41 pm

paulclaude wrote: Thu Mar 04, 2021 10:13 am i just need to hide plugins when the script editor window comes to the foreground,
so i need to identify the state changes of the window itself

Hi Paul,

Here is a plugin (actually, I did edit the revExample.rev plugin for this purpose)
which will detect if the SE is open or closed.
See bottom-left label which is red or green according to the SE state.

You'll find on top of the stack script the modifications,
plus another one in the card script.



screenshot 2021-03-04 à 13.32.17.jpg



screenshot 2021-03-04 à 13.31.53.jpg


I've done this in less than 15 minutes; so might be that I forgot something;
please, let me know if this is the case.


Regards,

Thierry

Hi Thierry,
your plugin seems not able to intercept suspending or resuming of Script Editor. I've used revResumeStack with openStacks to trap it (post #5).

I made a stack named "seTest" with a field in it, and put this in the SE stack script: These fire. Can you make this work for your Plug-in thing?

Craig

dunbarx wrote: Sat Mar 06, 2021 5:52 pm I made a stack named "seTest" with a field in it, and put this in the SE stack script:

Code: Select all

on mouseEnter
   put "Entering SE" into fld 1 of stack "seTest"
end mouseEnter

on mouseLeave
   put "Leaving SE" into fld 1 of stack "seTest"
end mouseLeave

These fire. Can you make this work for your Plug-in thing?

Craig

Hi Craig, I don't need to detect the mouse loc: I need to hide my plugin when the script editor is the frontmost stack, and show my plugin when Script Editor is in the background.

What we still call a "palette" Apple more recently calls a "panel", and as with their older documentation with palettes, their first recommendation with panels is that we consider something else:

Consider alternatives to panels. Since panels take screen space away from content, many apps present auxiliary information and tools less intrusively using popovers, sidebars, split views, and toolbars. For example, Keynote, Numbers, and Pages include formatting panes that are attached as sidebars (which can be quickly hidden and revealed) to document windows.

https://developer.apple.com/design/huma ... ws/panels/

Of course when you truly need a palette you need a palette. But how often do we truly need a palette?

When we compare software made by xTalk users to professionally-published packages from major vendors, we find palettes used far less frequently among the pros. This is not a judgement of any particular use among our fellow community members; indeed, it would not be possible to express an opinion about any UI I've not seen. I offer that observation only in the spirit we all share, to reach inside ourselves for the best design solutions that reflect the best work we see in our industry.

Apple's note above is useful guidance. Always-on-top windows don't just obscure the Script Editor, they obscure everything. Where the functionality they provide is both immediate and frequently needed, they can be a good choice. But if not frequently accessed, the whole time they obscure the very windows we're working on with them. Compounding their inherent usability tradeoffs, palettes also have a notoriously small close box, so when you do decide to dismiss it that requires more care than for other window types.

Over the years as I became more aware of this trend to use palette alternatives among the software packages I use, I've considered and often used alternatives myself. One of the reasons I wrote my own Message Box is that I find it very useful to have open, but I want to be in control of when it's in front of what I'm working on, so I use a modeless style for that window.

Though palette is the default, LiveCode plugins can make use of all window styles. This can be set in LC's Plugins manager, creating a custom property that is persistent with the stack file so it can be reused and even shared and still retain the desired mode.

Please understand that none of this is in any suggesting palettes should never be used, or even that they shouldn't be used in the case being described here. I've not seen the plugin in question here, nor have any idea of the functionality it delivers, so AFAIK a palette mode may be ideal for it.

I offer this only as a general reminder of what Apple's and others' usability testing has shown us: palettes are great when you need them, but windows come in many styles, each has its own strengths and weaknesses, and all are supported by LC's Plugins subsystem.

Hi.

My post does not mention the "mouseLoc". It does let you know when you enter and leave the SE. I was wondering if you could use those handlers to show and hide your plug-ins.

EDIT:

Rereading, I see where you might have gotten the "mouseLoc" thing. I assumed that you use the cursor to bring the SE to the front, and the cursor yet again to bring whatever else you are working on to the front. Is this not so?

In any case, the way I presented it, those two messages are triggered more often that you might like, since there are several controls in the SE, and navigating around triggers both. This can be dealt with, assuming we are on the same page in general.

Craig

When I want a window that sort of acts like a palette but doesn't sit on top of everything, I set the stack to modeless. You don't need to track any other stacks that way. However, it won't consistently appear above other stacks either unless you click on it.

jacque wrote: Sun Mar 07, 2021 6:39 pm When I want a window that sort of acts like a palette but doesn't sit on top of everything, I set the stack to modeless. You don't need to track any other stacks that way. However, it won't consistently appear above other stacks either unless you click on it.

In the end, after some experiments (not very successful) trying to intercept the messages to the Script Editor, I believe that the solution is a modeless stack, which at least leaves the plugin usable even when you edit the other open stacks.
Thanks Jaqueline

paulclaude wrote: Sat Mar 06, 2021 3:28 pm

Thierry wrote: Here is a plugin (actually, I did edit the revExample.rev plugin for this purpose)
which will detect if the SE is opened or closed.
See bottom-left label which is red or green according to the SE state.

your plugin seems not able to intercept suspending or resuming of Script Editor.

Sorry for the delay...

First, it's not *my* plugin, but an existing one, which i did edit a bit.

And yes, as stated, it just catches opened and closed SE states
and thinking it was an answer to your subject: "Hide custom plugins opening SE".

That said, here is a quick update which will manage these 4 states:
- SE closed
- SE open and in front
- SE iconified
- SE in the background

You'll see the SE state in the message Log field.


HTH,

Thierry

Thierry wrote: Thu Mar 11, 2021 5:20 pm

paulclaude wrote: Sat Mar 06, 2021 3:28 pm

Thierry wrote: Here is a plugin (actually, I did edit the revExample.rev plugin for this purpose)
which will detect if the SE is opened or closed.
See bottom-left label which is red or green according to the SE state.

your plugin seems not able to intercept suspending or resuming of Script Editor.

Sorry for the delay...

First, it's not *my* plugin, but an existing one, which i did edit a bit.

And yes, as stated, it just catches opened and closed SE states
and thinking it was an answer to your subject: "Hide custom plugins opening SE".

That said, here is a quick update which will manage these 4 states:
- SE closed
- SE open and in front
- SE iconified
- SE in the background

You'll see the SE state in the message Log field.


Tdz_revexample.rev.zip


HTH,

Thierry

Hi Thierry,
I think your solution uses both "revEditScript" and "line 1 of the openstacks" in a "revResumeStack" handler, a bit like, less structurally, I did (see my post # 5 in this thread).
Thanks
Paul