Skip to content
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

Closed
54freebird opened this issue Nov 18, 2019 · 9 comments
Closed

positioning enhancement #906

54freebird opened this issue Nov 18, 2019 · 9 comments
Labels
question Issue where reporter seeks information Stale Issue/PR that requires attention because it hasn't been updated in over a year

Comments

@54freebird
Copy link

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

@54freebird
Copy link
Author

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.
fb

@lasers lasers added the question Issue where reporter seeks information label Nov 18, 2019
@philer
Copy link

philer commented Dec 2, 2019

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. ${set x y} would then be slightly more verbose with ${goto x}${vgoto y}.

@54freebird
Copy link
Author

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!
Sure would appreciate SOME mechanism for avoidance - so far I have found lua beyond me.. :)
freebird

@philer
Copy link

philer commented Dec 3, 2019

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 conky.text… With $vgoto I could at least use my layout engine to automatically position that text.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale Issue/PR that requires attention because it hasn't been updated in over a year label Apr 29, 2023
@github-actions
Copy link

This issue was closed because it has been stalled for 30 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 29, 2023
@bi4k8
Copy link
Collaborator

bi4k8 commented May 29, 2023

I don't think there's a fundamental reason not to do this. However, this is indeed a duplicate of #450.

@bi4k8 bi4k8 reopened this May 29, 2023
@bi4k8
Copy link
Collaborator

bi4k8 commented May 29, 2023

Duplicate of #450.

@bi4k8 bi4k8 closed this as completed May 29, 2023
@bi4k8
Copy link
Collaborator

bi4k8 commented May 29, 2023

I'll be damned if I can get GH to show a "marked as duplicate" event.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Issue where reporter seeks information Stale Issue/PR that requires attention because it hasn't been updated in over a year
Projects
None yet
Development

No branches or pull requests

4 participants