As this suggestion has been thoroughly discussed at this point, i'll update this as development continues with new features and thoughts!
Props to Brian for this structure idea
Some minor modifications might be made, but the meter will most likely look something like this:
Code: Select all
[MeterVector]
Meter=Vector
Shape=Rectangle: 0,0,200,200 | OutlineWidth: 5 | FillColor: 255,255,255 | OutlineColor: 0,0,0
Shape2=Rectangle: 10,10,80,80 | OutlineWidth: 3| FillColor: 255,0,0 | OutlineColor: 0,0,255
Shape3=CustomShape | OutlineWidth: 3| FillColor: 255,0,0 | OutlineColor: 0,0,255
Shape4=CustomShape | OutlineWidth: 10| FillColor:0,0,0 | OutlineColor: 0,0,255
CustomShape = LineTo: 20,20 | ArcTo:45,45,Xradius, Yradius | LineTo: 100,100
A shape is currently defined as either a Rectangle, Circle, Arc, Curve or Custom, and then some options that defines how the finished shape will look.
When choosing the shape, you will need to apply different options to this specific shape, this happens right after the Type is specified, example: Rectangle: X, Y, W, H or Circle: X, Y, Radius
These are dependent on the shape that is chosen.
You would then add options to define how the shape would look, this includes the fill color, outline color, the width of the outline, gradients, offset to the shape, Clip size and possibly other options too (None of the options named are certain to make it into the meter either. They are no promise, but more a goal)
The custom shape lets you refer to another option where the definition of the shape lies. Here is it possible to create any geometry possible using a command based system. You start at a specified point, lets say 0,0, and by using commands like LineTo, ArcTo and CurveTo, is it possible to draw your own custom shapes. This behaves much like drawing in real life, where if you want one continuous shape, you'll have to draw the shape without lifting the pencil.
How each of these commands will work will be specified later, as i can't really tell how they will work at this time (Even though i have a general idea, can't i claim it is possible in code)
There will also be some additional options to the meter:
All general meter options works, except MeasureName! ( If anyone could find a use for it, that'd be awesome )
CombineMode, which lets you define the way Shapes will interact when overlapping. (This might be implemented as a Shape Option!)
You can look at this as a reference:
There might be more options, but i either can't remember them, or i haven't found them yet
I hope that this is a good and understandable description of how the meter should work, and i thought it'd be a good idea to collect it all in one place. This way we can better see how the meter could work as a whole!
----------------------------------------------------------------------------------------------------
Original Post:
Hey, i have another suggestion
I'll split this suggestion into two parts, function and why i think this meter is useful.
Function:
I've was researching how to do this and found this: https://msdn.microsoft.com/en-us/library/windows/desktop/ee264309(v=vs.85).aspx#render_the_path_geometries_onto_the_display
Originally thought of something like a vertex array, but i actually find the path geometry more fitting for rainmeter because it preserves most of the general meter options like SolidColor, Gradients and Padding. I'm not really certain how Measures could be tied into this, but this would be more a drawing meter tbh.
Since the path geometry works with points, have i found two ways for the meter to work. Either by using Point1=X1,Y1, Point2=X2,Y2, etc, similar to how the TransformationMatrix, padding and cropping works, and this is the way i prefer because X, Y, W and H could be used to offset the geometry inside the skin window, similarly to how the roundline meter works. If the meter exceeds the specified width or height it would work similar to the text meter, where it would basically just be cut.
The other way would be using X1=X1, Y1=Y1, X2=X2, Y2=Y2, etc, but this would require more options and would be confusing if there should be an offset if you don't use something like OffsetX and OffsetY. It'd also make it hard to limit the width of the meter, since there are never any width specified. I honestly think the first option is the best, even though it deviates somewhat from the norm of how meters currently works. (This also deviates somewhat, but looks more similar in my opinion)
It would also be possible to add a custom option to decide the type of path, since there are multiple types of geometry that could be added, examples are Bezier, Arcs and simple lines, but i'm not really certain of a good way to implement this yet. The only way i can currently think of is to make a meter only have one type, which could work.
I'll include an example of how the meter could look:
Code: Select all
[MeterGeometry]
Meter=Geometry
X=20
Y=20
W=200
H=200
Point1=111, 17
Point2=80, 32
Point3=56, 0
Point4=156, 95
Point5=190, 95
LineColor=255, 255, 255
Why i think this meter would be useful:
The way of drawing custom shapes currently is using the image meter, which doesn't really scale well. This is a way for skin creators to create custom shapes and geometry that can work on all screens, even 4k resolution without really overloading the cpu trying to load a 5-6+ mb file, which most modern computers can handle, but if a user has multiple skins or skins using DynamiVariables it'll quickly add up.
Another reason is that there are a few requests to be able to draw lines, which this will solve.
One drawback with this meter is that it is quite complex, and it might be difficult for new users to wrap their head around, but i have simplified what's actually in the meter as best i could.
There might also be more drawbacks, since i haven't tried making this meter myself, but i'm willing help and/or make myself if this is something that i know will be an accepted meter. I personally think that this meter would be a great addition to the group of current meters, but i'm looking for the opinion of others.
This shouldn't break any earlier skins, and i think it'd be a great addition to Rainmeter v 4.0
From what i can see does it support the way Rainmeter currently render the meters, so i don't think that it should be a problem to implement.
I hope that the meter doesn't create too much scepticism, but i'm looking forward to see others opinion
~ theAzack9