[Suggestion] GeometryMeter - For drawing simple geometry

[theAzack9]

I think I'd be opposed to breaking the .ini file format. Key=Value must be on a single line.

I had a feeling you'd say that

[theAzack9]

I think I'd be opposed to breaking the .ini file format. Key=Value must be on a single line. And with it all on a single line, I don't see any real advantage to that.

Ok, i've got another idea...

What if we merge the options into pairs, something akin to how Actiontimer works?

Something like:

Code: Select all

[VectorMeter]
Meter=Vector
VectorType=Custom
Shape1=Point1|Point2|Point3|Point4
Point1=X:Xpos|Y:Ypos|Type:Type|...AdditionalOptions...
Point2=X:Xpos|Y:Ypos|Type:Type|...AdditionalOptions...
...etc...

[jsmorley]

Ok, i've got another idea...

What if we merge the options into pairs, something akin to how Actiontimer works?

Something like:

Code: Select all

[VectorMeter]
Meter=Vector
VectorType=Custom
Shape1=Point1|Point2|Point3|Point4
Point1=X:Xpos|Y:Ypos|Type:Type|...AdditionalOptions...
Point2=X:Xpos|Y:Ypos|Type:Type|...AdditionalOptions...
...etc...

That's promising... Very promising. I'd do the "canned" ones the same way for consistency.

Just have to keep in mind that not only are Key=Value on one line, but Key must be unique in the context of a single [Section].

[jsmorley]

I like that a lot actually. Aside from being somewhat consistent with ActionTimer, It has the advantage of not being "number" driven, so you don't have to do some kind of "while 'Shape' & X do" or something. The option names can be anything. Instead of Shape1 and Shape2 a user might like RedCircle= and LineThroughRedCircle= etc...

[theAzack9]

That's promising... Very promising. I'd do the "canned" ones the same way for consistency.

Just have to keep in mind that not only are Key=Value on one line, but Key must be unique in the context of a single [Section].

I understand that a key needs to be unique, that's why i'm thinking that shape is the only one that needs to be specially named(Shape1 -> ShapeN) and the points can be called whatever, since i can get the name of the points from the Shape.

i don't really understand what you mean with the "canned", do you mean that e.g Point1=X|Y|Type|etc, because it would be nice to be able to choose the options needed, since e,g arc has quite a few possible options...

This would also make it possible to add new options later in Rainmeter without breaking backwards compability

[theAzack9]

I like that a lot actually. Aside from being somewhat consistent with ActionTimer, It has the advantage of not being "number" driven, so you don't have to do some kind of "while 'point' & X do" or something. The option names can be anything. Instead of Shape1 a user might like RedCircle= and LineThroughRedCircle= etc...

Actiontimer is kind of number driven with the ActionLists, but i was thinking the same as you i guess

[jsmorley]

Actiontimer is kind of number driven with the ActionLists, but i was thinking the same as you i guess

The number on ActionList(X) is really just to support the !CommandMeasure bang, and really isn't all that needed in this case.

Otherwise, It's sorta number driven under the covers, but not as far as option names. It just counts the "|" bar separators.

[theAzack9]

The number on ActionList(X) is really just to support the !CommandMeasure bang, and really isn't all that needed in this case.

Otherwise, It's sorta number driven under the covers, but not as far as option names. It just counts the "|" bar separators.

Not from what i understand from the source... it also uses the numbered system to find where the next shape is:

Code: Select all

size_t i = 1;
while (!action.empty())
{
...Code...
action = RmReadString(rm, std::wstring(L"ActionList" + std::to_wstring(++i)).c_str(), L"", FALSE);
}

Otherwise it would be quite difficult to differentiate the options...

[theAzack9]

Not from what i understand from the source... it also uses the numbered system to find where the next shape is:

Code: Select all

size_t i = 1;
std::wstring action = RmReadString(rm, L"ActionList1", L"", FALSE);
while (!action.empty())
{
...Code...
action = RmReadString(rm, std::wstring(L"ActionList" + std::to_wstring(++i)).c_str(), L"", FALSE);
}

Otherwise it would be quite difficult to differentiate the options...

EDIT: Ops... i replied... well...

[jsmorley]

Not from what i understand from the source... it also uses the numbered system to find where the next shape is:

Code: Select all

size_t i = 1;
while (!action.empty())
{
...Code...
action = RmReadString(rm, std::wstring(L"ActionList" + std::to_wstring(++i)).c_str(), L"", FALSE);
}

Otherwise it would be quite difficult to differentiate the options...

I'm not sure, but that may be a bit of a prehensile tail. Other implementations of !CommandMeasure, specifically InputText, use a format like [!CommandMeasure MeasureName "Execute 1"] OR [!CommandMeasure MeasureName "Execute 1-3"]. ActionTimer doesn't actually support that, and so I'm not sure what value the number brings. I would think in the context of ActionTimer, that [!CommandMeasure MeasureName "Execute Bob"] or even just [!CommandMeasure MeasureName "Bob"] would work just as well.

In any case, a minor point in the big scheme of things.