-
-
Notifications
You must be signed in to change notification settings - Fork 620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
positioning enhancement #906
Comments
Forgot to mention, a ${read x,y} to find out where the coordinate currently points would be about as good for accuracy, although it wouldn't stop change cascades. |
I think this is asking for the same as #450. $goto already allows us to do absolute horizontal positioning and $alignr does it from the right. Adding a vertical version (e.g. $vgoto to stay consistent with $voffset) would complement that. |
Whatever mechanism results in the least amount of work to implement is the preferred option! Anything to allow the script(er) to KNOW where the vertical position currently resides, or to SET where the vertical position is. I have implemented a few complicated scripts over the years that the 'cascade' effects have driven me near to distraction - for example one had me inserting elements into a background picture of an airplane cockpit (redefining what the 'glass panels' show, and showing the clock as a digital readout, and putting weather on the "stormscope" etc. TGhere was massive use of negative {voffset}s, and a tweak one place caused need for more tweaks in 4 or five others. Another script has different 'views' flipping into sight depending on elapsed time since refresh, and again there is no simple way to ensure that text will appear where you want it when a new view flips in. You can see what I mean with a look at https://vimeo.com/373829842 - the problem was the location ID text at the bottom left of each panel - if too low took out the NEXT flip page! |
I know your problem. It's what made me write a layout engine for Lua widgets (polycore). It does away with the issue for anything rendered by Lua. Unfortunately, cairo's font rendering isn't as good as conky's, so for plain text I'm still relying on good old |
This issue is stale because it has been open 365 days with no activity. Remove stale label or comment, or this issue will be closed in 30 days. |
This issue was closed because it has been stalled for 30 days with no activity. |
I don't think there's a fundamental reason not to do this. However, this is indeed a duplicate of #450. |
Duplicate of #450. |
I'll be damned if I can get GH to show a "marked as duplicate" event. |
Issue
Conky must internally maintain a 'position' coordinate from which ${voffset} and ${goto} are derived. Access to this position would simplify life considerably, as currently a change in one place propagates throughout a script. Using an object with a -px,y capability is fine - but then where you 'are' is difficult to know - and can lead to hard-to-find 'bugs' (such as writing text slightly out of the window confines - causing weird reactions in subsequent sections.
My suggestion, if easy to implement, would be an object to ${set x,y} as needed as you go - perhaps by script "code section" - both to limit the cascading reactions effect, and to accurately place text where you intend it to go.
Of course there are other methods of achieving the same thing (creating a text object with coords) but I suspect they would be more involved/expensive to implement - whereas this set x,y would be used only when needed and would use the already existing internal mechanisms.
I'd be interested to hear why this wouldn't work, if it wouldn't... but I would love to see it implemented!
freebird54
The text was updated successfully, but these errors were encountered: