It is currently March 28th, 2024, 11:32 pm

second/third screen preview box

Get help with creating, editing & fixing problems with skins
Akallabethuial
Posts: 2
Joined: November 12th, 2015, 8:33 am

Re: second/third screen preview box

Post by Akallabethuial »

Thank you very much dgrace and jsmorley, both plugins work great for what I needed. Significantly better than trying to get a window into fullscreen blindly and having to go into the other room to check lol. Would've responded sooner but I honestly didnt expect such a rapid reply and solution. I'll be sure to bring more challenges to the community here :)
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan

Re: second/third screen preview box

Post by dgrace »

Cheers, I think this one sets the record for fastest turnaround on a custom plugin, but I'd just written something pretty similar so it was easy to modify for what you needed. Happy it works!

dave
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: second/third screen preview box

Post by jsmorley »

An observation that I have:

My gut reaction to this was; why in the world would I ever want this? Ok, the guy with a second monitor in a different room, or otherwise out of direct sight, makes sense, but that is a pretty niche case. I can't imaging why I would want a "preview" of a monitor screen that is right in front of me.

Then something dgrace said caught my eye. Creating a "magnifier" skin. Where you could have for instance a 200 X 200 skin, and what it does is capture 100 X 100 of what is under it, and stretch that to the 200 X 200, thus "magnifying" part of the screen. That might be of some interest for fine tuning skin cosmetics and such.

However, it can't really work can it? Since you get an endless "regression", where the skin itself and what it is displaying becomes part of the captured image / frame, It very quickly zooms out to displaying one pixel at 200 X 200. Not sure I see any way of fixing that, unless you could somehow have the plugin "ignore" its own skin when capturing...

I was thinking I might replace this, which is actually a very useful little utility:

http://magnifier.sourceforge.net/
1.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: second/third screen preview box

Post by jsmorley »

Ah, you actually sorta can, just not "real time"...

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[MeasureScreen]
Measure=Plugin
Plugin=ScreenShot
ScreenX=(#CURRENTCONFIGX# + 50)
ScreenY=(#CURRENTCONFIGY# + 50)
ScreenW=100
ScreenH=100
ImageName=#CURRENTPATH#frame.bmp
DynamicVariables=1
UpdateDivider=-1

[MeterBack]
Meter=Image
W=204
H=204
SolidColor=0,0,0,255

[MeterScreen]
Meter=IMAGE
ImageName=#CURRENTPATH#frame.bmp
DynamicVariables=1
AntiAlias=1
X=2
Y=2
W=200
H=200
MouseLeaveAction=[!Hide][!UpdateMeasure MeasureScreen][!UpdateMeter *][!Redraw][!Show]
1.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5384
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: second/third screen preview box

Post by eclectic-tech »

I was hoping you might demo this... thanks Jeff!

I added a few features I wanted to your example:
Set skin to top position, disable SnapEdges and KeepOnScreen.

Variable magnification: scroll the mouse up will increase the magnification factor X2, X3, X4, and X8, scroll down to reduce.

Transparency and selection meters that show on mouse over:
  • transparent background
  • center point
  • capture area
  • and current magnification.
Click to animate image:
mag8.gif
Thanks again Jeff, and Dave!

Code:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
OnRefreshAction=[!ZPos 1][!SnapEdges 0][!KeepOnScreen 0]

[Variables]
MagX=100

[MeasureMag]
Measure=Calc
Formula=Round(200/#MagX#)
DynamicVariables=1

[MeasureScreen]
Measure=Plugin
Plugin=ScreenShot
ScreenX=(#CURRENTCONFIGX# + #MagX#/2)
ScreenY=(#CURRENTCONFIGY# + #MagX#/2)
ScreenW=#MagX#
ScreenH=#MagX#
ImageName=#CURRENTPATH#frame.bmp
DynamicVariables=1
UpdateDivider=-1

[MeterScreen]
Meter=IMAGE
ImageName=#CURRENTPATH#frame.bmp
AntiAlias=1
X=2
Y=2
W=200
H=200
ImageAlpha=255
MouseOverAction=[!SetOption #CurrentSection# ImageAlpha 1][!ShowMeterGroup Select]
MouseScrollUpAction=[!SetVariable MagX (Clamp(#MagX#-25,25,100))][!UpdateMeter #CurrentSection#][!Redraw]
MouseScrollDownAction=[!SetVariable MagX (Clamp(#MagX#+25,25,100))][!UpdateMeter #CurrentSection#][!Redraw]
MouseLeaveAction=[!Hide][!SetOption #CurrentSection# ImageAlpha 255][!UpdateMeasure MeasureScreen][!UpdateMeter *][!Redraw][!Show][!HideMeterGroup Select]
DynamicVariables=1

[MeterX]
Meter=Image
X=(#MagX#-3)
Y=#MagX#
W=7
H=1
SolidColor=255,0,0
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select

[MeterY]
Meter=Image
X=#MagX#
Y=(#MagX#-3)
W=1
H=7
SolidColor=255,0,0
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select

[MeterMag]
Meter=String
MeasureName=MeasureMag
X=3
Y=3
FontColor=255,0,0
Text=X%1
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select

[MeterLeft]
Meter=Image
X=(#MagX#*0.5)
Y=(#MagX#*0.5)
W=1
H=(#MagX#)
SolidColor=255,0,0
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select

[MeterTop]
Meter=Image
X=(#MagX#*0.5)
Y=(#MagX#*0.5)
W=(#MagX#)
H=1
SolidColor=255,0,0
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select

[MeterRight]
Meter=Image
X=(#MagX#*1.5)
Y=(#MagX#*0.5)
W=1
H=(#MagX#+1)
SolidColor=255,0,0
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select

[MeterBottom]
Meter=Image
X=(#MagX#*0.5)
Y=(#MagX#*1.5)
W=(#MagX#+1)
H=1
SolidColor=255,0,0
AntiAlias=1
DynamicVariables=1
Hidden=1
Group=Select
You do not have the required permissions to view the files attached to this post.
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan

Re: second/third screen preview box

Post by dgrace »

This is a case where it'd be nice to be able to control the texture sampling in ImageMeter so that you could specify whether you want it "smoothed" or just "pixel doubled" - in this case you probably don't want the default which is to do a linear interp between texels. That would be a Rainmeter code change though.

I'll also note this is another example where bitmap plugins would be the right way to do this... (inside joke for jsmorley) ;)

dave
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan

Re: second/third screen preview box

Post by dgrace »

Also it'd be nice if MOUSEX and MOUSEY were available globally, all the time, rather than only in mouse actions. Another Rainmeter code change but I don't see any downside, just parse the mouse position once per update loop and store it in a global var, rather than parsing it in the action callbacks. (unless we're letting the callbacks _set_ the mouse position, but I don't think that's happening)

dave
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: second/third screen preview box

Post by jsmorley »

dgrace wrote:Also it'd be nice if MOUSEX and MOUSEY were available globally, all the time, rather than only in mouse actions. Another Rainmeter code change but I don't see any downside, just parse the mouse position once per update loop and store it in a global var, rather than parsing it in the action callbacks. (unless we're letting the callbacks _set_ the mouse position, but I don't think that's happening)

dave
The downside in my view is that it is almost entirely impractical in any real sense. Tracking mouse movement once a second, or even once every 16 milliseconds is just hopelessly out of date by the time you react to and use the information. I know there might be some niche cases where it makes sense, but the vast, overwhelming majority of the time it is a promise that can't be kept. We have talked about it in the past, but decided against it. I could see other mouse actions, like drag events and drop events, which are a "moment in time" that has relevance outside of actual real-time, but I don't think mouse movements makes a lot of sense in our environment.

What we do now is "where was the mouse when something happened?" That makes sense. In a big loop like a Rainmeter skin, I can't see how "where is the mouse right now?" has any possible value. Any answer you get is going to be dozens or hundreds of pixels out of date by the time you can have a skin actually react to it.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: second/third screen preview box

Post by jsmorley »

dgrace wrote:This is a case where it'd be nice to be able to control the texture sampling in ImageMeter so that you could specify whether you want it "smoothed" or just "pixel doubled" - in this case you probably don't want the default which is to do a linear interp between texels. That would be a Rainmeter code change though.

I'll also note this is another example where bitmap plugins would be the right way to do this... (inside joke for jsmorley) ;)

dave
I'd be all for that. If we could have some kind of setting on an image meter that controlled how "shrinking" and "growing" was done, that would be a huge improvement over the brute force method it uses now.

This is from a little "PhotoZoom" app I use from time to time.
1.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan

Re: second/third screen preview box

Post by dgrace »

jsmorley wrote:The downside in my view is that it is almost entirely impractical in any real sense. Tracking mouse movement once a second, or even once every 16 milliseconds is just hopelessly out of date by the time you react to and use the information. I know there might be some niche cases where it makes sense, but the vast, overwhelming majority of the time it is a promise that can't be kept. We have talked about it in the past, but decided against it. I could see other mouse actions, like drag events and drop events, which are a "moment in time" that has relevance outside of actual real-time, but I don't think mouse movements makes a lot of sense in our environment.

What we do now is "where was the mouse when something happened?" That makes sense. In a big loop like a Rainmeter skin, I can't see how "where is the mouse right now?" has any possible value. Any answer you get is going to be dozens or hundreds of pixels out of date by the time you can have a skin actually react to it.
Maybe I didn't describe it clearly. I'll whip up a branch to test it and fire off a pull request so you can see what I mean.

EDIT: Ah, I see what I missed. MouseX/Y are local to the meter. I'd need to make a new global, maybe MOUSEABSX, MOUSEABSY which would be in absolute screen dimensions. Those could just be polled once each update loop (by the main application, not by a particular measure/meter). Then the value would be available for use anywhere, like SCREENAREAWIDTH. That way you could do a magnifier where the position of the meter was static but it tracked wherever you had the mouse. You would probably get some crazy feedback if you moused over the meter itself.

dave