[Suggestion] GeometryMeter - For drawing simple geometry

[theAzack9]

Interesting observations. I think any way we do this, things other than simple shapes like a line or square or rectangle or circle or triangle are going to be complex.

The advantage I see to SVG (assuming it can even be done without having to re-invent the wheel) is that it is both very robust, and is a well-documented format that while not trivial, is something that anyone who has done a fair amount of HTML coding is going to be able to wrap their head around.

The pre-defined shapes in SVG like <circle .. /> are really just shortcuts for common shapes. SVG also allows you to use the <path .. /> form to literally draw any path you want, and it is quite powerful.

I think that the ability in SVG to have several shapes or paths in the same meter is a strong selling point. Having to create 10 complicated meters to "build-up" a complex shape made up of 10 shapes or paths seems horrid to me.

As to a single string or separate elements as separate options on the meter, I'm torn. I can see dgrace's point of view, and having the option of loading a .svg file or download a .svg image from the web has a lot of charm, but I can see a single option string that needs to build multiple shapes or paths, using complicated mathematical formulas in it, would quickly get so large and unreadable that it would be a nightmare. It would really almost force you to a Lua solution, where you would use the "programming" capabilities of Lua to define the elements of the option string, and then send the final result to the skin with !SetOption.

Of course all of that is predicated on being able to get SVG into D2D capabilities without having to write it from scratch. I think that would just be the Manhattan Project, and I'd recommend against it. If we are going to have to "roll-our-own", then just get as "close to the metal" as you can and start with what D2D can do. That, I suspect, is what you are suggesting.

One solution, which imo isn't probably the best, is to split the meters into either two meters, or two parts of one meter. (kind of similar to how the image meter works)

It is possible to load a custom file(svg, if possible) using a VectorName option (or similar, basically what image does), and then it is possible to define a custom shape the way it currently is, by using options. This way you can create simple animated shapes using points, and if you want static complex vector shapes (which can be animated similarly to how you animate an image, by creating multiple of them / by manually editing the file).

This seems to be the most useful and user friendly option imo.

EDIT:

Seems that the .svg file is just a custom xml format, so any xml parser should be able to parse that kind of file too

[jsmorley]

Having said all that, there is another observation about how the Rainmeter project works that might be useful.

With the project consisting of a very small team with lots of competing priorities, what gets implemented is often based on who wants to "step up" and actually get something done. Actually providing something that works and meets a need can go a long way in the decision making process. A bird in hand and all that...

Doesn't mean that just any 'ol thing that someone comes up with will get into the build however. We look at all proposed changes with some criteria in mind:

1) Is this something that is really needed and / or wanted, or it it being done just because it can be?
2) Is this 100% certain to have no backwards compatibility implications? We will not budge on this.
3) Is this 100% consistent in behavior, reliable and stable? Things either work as expected 100% of the time, or they don't work at all. Crashing Rainmeter, no matter what error the "user" makes, won't be allowed.
4) What is the impact on Rainmeter resources. This is primarily CPU, but certainly memory should be considered.
5) Does this fit into the underlying structure / architecture of Rainmeter? We don't want bags on the side of the machine.
6) Is this consistent with how Rainmeter works from a user point of view? Remember, Measures measure stuff, and Meters display stuff. That's all Rainmeter is at the end of the day. Rainmeter is very "deep", but not "wide". It's easy to wrap your head around it at a 10,000 foot level. InputText is an example of something that doesn't meet this criteria, and we regret allowing it to be done the way it was. We won't do it again.

Guess what I'm saying is that if you have something that you think works, passes all those criteria, and you are happy with the result, let's see it. I can easily do a "pre-pre-alpha" build of Rainmeter and we can let folks play with it with the understanding that this is proposed and not in any way final or even certain.

[theAzack9]

Having said all that, there is another observation about how the Rainmeter project works that might be useful.

With the project consisting of a very small team with lots of competing priorities, what gets implemented is often based on who wants to "step up" and actually get something done. Actually providing something that works and meets a need can go a long way in the decision making process. A bird in hand and all that...

Doesn't mean that just any 'ol thing that someone comes up with will get into the build however. We look at all proposed changes with some criteria in mind:

1) Is this something that is really needed and / or wanted, or it it being done just because it can be?
2) Is this 100% certain to have no backwards compatibility implications? We will not budge on this.
3) What is the impact on Rainmeter resources. This is primarily CPU, but certainly memory should be considered.
4) Does this fit into the underlying structure / architecture of Rainmeter? We don't want bags on the side of the machine.
5) Is this consistent with how Rainmeter works from a user point of view? Remember, Measures measure stuff, and Meters display stuff. That's all Rainmeter is at the end of the day.

Guess what I'm saying is that if you have something that you think works, passes those criteria, and you are happy with the result, let's see it. I can easily do an "pre-pre-alpha" build of Rainmeter and we can let folks play with it with the understanding that this is proposed and not in any way final or even certain.

I went into this project with most of these points already in mind, why include something that there isn't any demand for, right

I have personally tried to answer most of these criteria's before even thinking about doing anything with it :P I have also been asking a bit over at the extremely quiet Discord channel for Rainmeter, and most of them seemed pretty positive for a possibility to create scale scalable art. I have also seen complaints from 4k screen users that skins aren't really working for them, since images scaled to this size looks really blurred.

@theAzack9 If the actually add that to rainmeter im going to have to rewrite all my skins...

I constantly try to make this as close to the way the other meters works using principles i've created looking at other meters.(Trying to reuse existing options instead of creating new ones)


The meter is currently being stress tested by me to see how viable it is as a meter (i can't do this in my head, sadly) and it seems that it doesn't create any bigger load than the image does, but i still have a lot to test before i can say this for certain.

I use the same rendering system Rainmeter does, so it should be compatible with all existing computers using Rainmeter. I only really had to add to the current way of rendering, and with the underlying structure, it was really easy tbh

It should be 100% backwards compatible (I'm not ballsy enough to say that It is 100% backwards compatible...)

I can't even create a list of all the things that could be possible with this meter, custom graphs, the millions of different vector creations that could be made etc

The last point is really the one i'm struggling the most with, but not in the way you described. I wan't to find a way for it to be more similar to how other meter's work, while still being as powerful as i imagine it being.

I was never certain that this meter would be added, but it is something i myself thought would be a great addition to the already existing meters, as it would basically be the vector counterpart to the image meter. As i continued i saw how powerful it could be if you was able to animate it, after that i was sold. In the end isn't it my decision weather this should be added or not, as i'm not even a developer for this software, i'm just a user with some opinions!

[dgrace]

From what I've been able to dig up, I don't see any existing SVG -> D2D stuff, so I'd say your current approach is probably the best call. Plus I have no time to do any work on it so take all my advice with a big grain of salt! Looking forward to playing with what you come up with, as I'm sure are a lot of folks who haven't seen the thread yet.

Kinda too bad there isn't a Plugin interface for Meters, then it'd be easy to publish a trial run without having to make a special Rainmeter build. Another feature for the wishlist.

Cheers,

dave

[theAzack9]

From what I've been able to dig up, I don't see any existing SVG -> D2D stuff, so I'd say your current approach is probably the best call. Plus I have no time to do any work on it so take all my advice with a big grain of salt! Looking forward to playing with what you come up with, as I'm sure are a lot of folks who haven't seen the thread yet.

Kinda too bad there isn't a Plugin interface for Meters, then it'd be easy to publish a trial run without having to make a special Rainmeter build. Another feature for the wishlist.

Cheers,

dave

I't would had been awesome with some kind of plugin - meter interaction, but i have no clue if would be backwards compatible...

From what i understand is the svg simply a variation of the xml format, so any xml parser should be able to parse it, it shouldn't really be difficult to use the parsed xml file to create the geometry used in D2D if there isn't already something created

[jsmorley]

At a very high-level, and from a user point of view, the main advantage to SVG that I see is that it is a well-established and well-documented format. Want to create a circle? There are a thousand sites that will give you exactly what SVG code you need to do so. Given that there are just TONS of possibilities for vector drawing, I fear that entirely rolling our own might mean we need 10 pages of documentation to support it.

Another advantage is that you can likely use one of many vector drawing applications to create your image, and then export the SVG to use in your skin. https://inkscape.org/en/develop/about-svg/

That's just one factor though, and just part of an overall balance of "functionality, ease of implementation, and ease of use".

[theAzack9]

At a very high-level, and from a user point of view, the main advantage to SVG that I see is that it is a well-established and well-documented format. Want to create a circle? There are a thousand sites that will give you exactly what SVG code you need to do so. Given that there are just TONS of possibilities for vector drawing, I fear that entirely rolling our own might mean we need 10 pages of documentation to support it.

Another advantage is that you can likely use one of many vector drawing applications to create your image, and then export the SVG to use in your skin. https://inkscape.org/en/develop/about-svg/

That's just one factor though, and just part of an overall balance of "functionality, ease of implementation, and ease of use".

Did some research, and it seems that parsing svg with a PathGeometry isn't going to be as simple as i thought (Because of how wide scoped a svg file can be... lines, rects, text, circles, ellipses etc) So i don't really know if there is a simple way to implement the svg...

I downloaded Inkscape's source and i quickly found that a lot of the codebase is simply to handle the svg file (load / save), so if i can't find a better way am i not really certain how it would work.. :/

I'm guessing you don't really want another 50-200 cpp/h files added to the source...

[jsmorley]

Did some research, and it seems that parsing svg with a PathGeometry isn't going to be as simple as i thought (Because of how wide scoped a svg file can be... lines, rects, text, circles, ellipses etc) So i don't really know if there is a simple way to implement the svg...

I downloaded Inkscape's source and i quickly found that a lot of the codebase is simply to handle the svg file (load / save), so if i can't find a better way am i not really certain how it would work.. :/

I'm guessing you don't really want another 50-200 cpp/h files added to the source...

No, and on balance I don't think it makes sense to "roll-our-own" SVG implementation that would in effect just be a layer on top of things with the only purpose to support the SVG standard for documentation purposes.

No doubt that SVG is quite robust though...

The features of SVG 1.1 include paths, basic shapes (like circles and polygons), text, fill, stroke and markers, color, gradients and patterns, clipping, masking and compositing, filter effects, interactivity, linking, scripting, animation, fonts and metadata.

[theAzack9]

No, and on balance I don't think it makes sense to "roll-our-own" SVG implementation that would in effect just be a layer on top of things with the only purpose to support the SVG standard for documentation purposes.

No doubt that SVG is quite robust though...

Would you, and the others on the team, be open to possibly include another library to make it possible to load the svg file, or is that something that's out of question? That would be the only way i'd see to be able to do this...

Even if it is possible to include the svg format, should the dynamic drawing using points be discarded or still be included somehow?

I don't really think it'd be possible to change the format dynamically, so everything loaded from an .svg file would be just static graphics, which is fine. It would be cool to be able to draw simple shapes tho...

[jsmorley]

Would you, and the others on the team, be open to possibly include another library to make it possible to load the svg file, or is that something that's out of question? That would be the only way i'd see to be able to do this...

Even if it is possible to include the svg format, should the dynamic drawing using points be discarded or still be included somehow?

I don't really think it'd be possible to change the format dynamically, so everything loaded from an .svg file would be just static graphics, which is fine. It would be cool to be able to draw simple shapes tho...

For myself, I'm not sure I see a huge benefit to loading .svg files as static images. While there may be some value in that, I think it fails a cost-benefit analysis for me. While adding the .svg format to supported image types in Meter=Image has some charm, it's almost off-topic in a way. it really isn't what this is about is it...

I think if it is not possible, or not practical from an effort standpoint to have some way to convert a meter that has SVG statements as option(s) on the meter into something that can be drawn using D2D, then I think just forgetting about SVG and going with your original idea makes the most sense. I may be missing something here though, so others can by all means weigh in.