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).dunbarx wrote: ↑Tue Mar 02, 2021 7:32 pmBeen a long time since I used the "idle" message, but might this do: in the card script:This does nothing for you if you merely want to glance at the contents of the SE as opposed to actually working there.Code: Select all
on idle if the mouseLoc is within the rect of this cd then showYourPlugIns else hideYourPlugIns end idle
Craig
Hide custom plugins opening Script Editor
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 121
- Joined: Thu Mar 27, 2008 10:19 am
Re: Hide custom plugins opening Script Editor
Re: Hide custom plugins opening Script Editor
Hi Paul,paulclaude wrote: ↑Thu Mar 04, 2021 10:13 ami 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
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
- Attachments
-
- Tdz_revexample.rev.zip
- modified revExample IDE plug-in
- (4.83 KiB) Downloaded 151 times
Last edited by Thierry on Thu Mar 11, 2021 5:47 pm, edited 1 time in total.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
-
- Posts: 121
- Joined: Thu Mar 27, 2008 10:19 am
Re: Hide custom plugins opening Script Editor
Hi Thierry,Thierry wrote: ↑Thu Mar 04, 2021 1:41 pmHi Paul,paulclaude wrote: ↑Thu Mar 04, 2021 10:13 ami 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
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
your plugin seems not able to intercept suspending or resuming of Script Editor. I've used revResumeStack with openStacks to trap it (post #5).
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Hide custom plugins opening Script Editor
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
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
Craig
-
- Posts: 121
- Joined: Thu Mar 27, 2008 10:19 am
Re: Hide custom plugins opening Script Editor
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.dunbarx wrote: ↑Sat Mar 06, 2021 5:52 pmI 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?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
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9856
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Hide custom plugins opening Script Editor
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:
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.
https://developer.apple.com/design/huma ... ws/panels/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.
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Hide custom plugins opening Script Editor
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
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
-
- VIP Livecode Opensource Backer
- Posts: 7258
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Hide custom plugins opening Script Editor
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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Posts: 121
- Joined: Thu Mar 27, 2008 10:19 am
Re: Hide custom plugins opening Script Editor
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
Re: Hide custom plugins opening Script Editor
Sorry for the delay...paulclaude wrote: ↑Sat Mar 06, 2021 3:28 pmyour plugin seems not able to intercept suspending or resuming of Script Editor.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.
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
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
-
- Posts: 121
- Joined: Thu Mar 27, 2008 10:19 am
Re: Hide custom plugins opening Script Editor
Hi Thierry,Thierry wrote: ↑Thu Mar 11, 2021 5:20 pmSorry for the delay...paulclaude wrote: ↑Sat Mar 06, 2021 3:28 pmyour plugin seems not able to intercept suspending or resuming of Script Editor.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.
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
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