It is currently July 20th, 2019, 6:14 am

Changes to ClipString

Changes made during the Rainmeter 2.5 beta cycle and earlier.
User avatar
jsmorley
Developer
Posts: 19295
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Changes to ClipString

jsmorley » January 28th, 2013, 12:55 pm

~Faradey~ wrote: i've already mentioned this (way back earlier), but i wish you would have a some kind of list of future ideas and other stuff what's being planned on future, so people could know ;(... but it's no biggie...
I understand how this would be nice, but the team just doesn't work that way. It is a very informal "project", with folks stepping in to make improvements as they have time, when the mood hits them, and on things that for whatever reason catch their interest.

It would really be impossible, and probably somewhat destructive of the team dynamic, to try and make future commitments. There are lots of things we "talk about" that just never happen, and lots of things that just happen in a very dynamic way as folks are messing around with the code or get an idea based on some forum post / question from users. Marijuana use may play a role...

So saying "we are planning to do this or that" would be kinda pointless. Things on the list could happen sooner, later, or never, and there is nothing that says that just because something isn't on the list it can't happen tomorrow.

While I'm not sure I would run the IT department of a banking system this way, (well, you could, but the world would quickly be back to a barter system involving small rocks) it works for Rainmeter. There is a lot of freedom, folks can jump in when they have both an idea and time, and hey... Surprises are fun for everyone...
User avatar
Brian
Developer
Posts: 1879
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Changes to ClipString

Brian » January 28th, 2013, 5:33 pm

moshi wrote:now the nitpicky part (which you probably should ignore, as it is really almost invisible):
the metrics part is not really fixed, but the Meter:H/number-of-lines ratio is wrong the other way round now.
Right, I forgot to mention why this happens. The GDI+ function that calculates the height of a string returns the height as a floating-point number. Since the height of a container can only be a integer (no decimals), the height is rounded. While displaying a large number of lines, the height can be up to a couple of pixels off.

I believe ClipString=1 behaves this way as well.

-Brian
User avatar
moshi
Posts: 1851
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

moshi » February 1st, 2013, 3:12 pm

Untitled-1.jpg
what i do not like is the vertically clipped text one gets when using H= or ClipStringH=.

it's all fine if it's a fixed height, then it can be adjusted. as soon as the height is calculated with a formula with section variables or screen height it becomes difficult to solve, especially as the height of the string meter is not linear (see above post).

now, i could maybe solve the scenario in the screenshot with some math, but i am wondering if it couldn't be part of Rainmeter to avoid such clipping if there is not enough height for another line.
You do not have the required permissions to view the files attached to this post.
User avatar
smurfier
Moderator
Posts: 1937
Joined: January 29th, 2010, 1:43 am
Location: Willmar, MN

Re: Changes to ClipString

smurfier » February 1st, 2013, 3:51 pm

moshi wrote:what i do not like is the vertically clipped text one gets when using H= or ClipStringH=.

it's all fine if it's a fixed height, then it can be adjusted. as soon as the height is calculated with a formula with section variables or screen height it becomes difficult to solve, especially as the height of the string meter is not linear (see above post).

now, i could maybe solve the scenario in the screenshot with some math, but i am wondering if it couldn't be part of Rainmeter to avoid such clipping if there is not enough height for another line.
This has been considered a feature in the past, and I remember at least one skin that uses it as such. Changing it would be a backwards compatibility issue unless a new option was added.
GitHub | DeviantArt | Tumblr
This is the song that never ends. It just goes on and on my friends. Some people started singing it not knowing what it was, and they'll continue singing it forever just because . . .
User avatar
moshi
Posts: 1851
Joined: November 13th, 2012, 9:53 pm

Re: Changes to ClipString

moshi » February 1st, 2013, 4:29 pm

smurfier wrote: This has been considered a feature in the past, and I remember at least one skin that uses it as such. Changing it would be a backwards compatibility issue unless a new option was added.

i can see how this can be a desired visual effect that could be achieved with ClipString=1, but for ClipString=2 it does not really make sense.
User avatar
Brian
Developer
Posts: 1879
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: Changes to ClipString

Brian » February 3rd, 2013, 3:56 am

Alex, I agree with you that the new ClipString=2 should only display a line of text if the entire line of text can fit vertically.

This is actually an easy fix, however the fix introduces a new problem which is if the H (ClipStringH) is a smaller value the actual height of the text, then no text is displayed at all. This is not desirable. Although this new issue can also be fixed, it introduces too much overhead for calculating and drawing text.

I think we should leave this as is for now, at least until we switch over to D2D/DirectWrite for drawing text (which is needed for how badly GDI+ fonts look on Windows 8).

-Brian
User avatar
killall-q
Posts: 285
Joined: August 14th, 2009, 8:04 am

Re: Changes to ClipString

killall-q » February 8th, 2013, 5:34 pm

Thanks so much for adding this! I had begged for this a while back, I know I was a bit of a pain in doing so.