Closed awilliamson closed 6 years ago
There is already a script to convert your old conky config into >= 1.10 syntax: convert.lua but it is not flawless. There is still user interaction required. Also as you have mentioned there are some API changes. Personally i had little trouble converting my configs using that script but i heard other people did have problems.
But i agree, an extra tutorial or small explanation would be nice to clear things up. Or even update the documentation to add examples, like this: Casy's Conky Reference with examples (unfortunately this is only for Conky 1.9.1 and previous versions).
In the current status of conky a lot of the knowledge comes by digging into the code, but this is of course not possible for everyone to do (nor should it be required in the first place). At the moment i'm working on updating the wikipage to give some minimal guidelines but due to time constraints i will only be able to do the minimum "something is better than nothing". Other people currently looking at conky are more focusing on fixing bugs, which is also required (and affects user experience). But there are at the moment not enough people who can dedicate their time on conky for things like making tutorials ect. Under normal conditions i would point to existing 1.10 conky configs to learn from them but i don't know how many are already out there (I have put some basic ones on DeviantArt but i guess the absolute majority is still for conky 1.9).
This is also something the community would be able to do, on Crunchbang.org (your can still learn a lot from their conky mega threads) there was a rather active and helpfull conky community but since they moved to Bunsenlabs.org i don't know their status anymore.
(this is my personal opinion on the matter)
As for your config in particular i can not open your link, and i'm not sure i completely understand the intention of the line you gave. I guess you want something like this? (i took the liberty to use >
in the if_match
. The config was not tested.)
conky.config = {
--add your specific setting here
color0 = 'ffffff',
color1 = 'ff0000',
};
conky.text = [[
RAM ${if_match ${memperc} > 90}${color0}${else}${color1}${endif}${mem}/${memmax}
]];
Thanks @Nooby4Ever. The config you provided s/conky.config/conky.settings
and it loads fine.
First issue: Replacing color0 with #ff00ff will render the text with colour perfectly fine. However, using a variable in either the 'ffffff' format or '#ffffff' format will result in default white.
EDIT: It appears that color0 = 'ff0000'
with ${#color0}
works.
EDIT2: I lied. It comes out magenta, regardless of which colour is defined. Only way I can get accurate colour representation is by defining the colour literally. In-line with the text. ${#ff00ff}
.
Second Issue: I'm still having that alignment issue. Text RAM
is appearing underneath the variable input, not in-line.
I agree with you about the resources being available for this version. I would somewhat argue that this 1.10 release should have been kept in a branch until such a time as sufficient documentation had been creating. It is an important aspect of software development after all. That way packages reliant on this repo would not be thrown into this unknown world of new configs.
If you know of any new changes to layout and spacing, as to why it wouldn't stick to the i3-bar, feel free to let me know. I'll have a rummage and see if I can find out how to solve any of my problems.
EDIT: I did indeed try the convert.lua, obtained directly from this Repo. It royally messed up the configuration to an unreadable and syntactically incorrect state.
Unfortunately i have no experience with i3 myself. For the second issue: the only thing i can think of are maybe borders? Try to add these to your conky.config section:
border_inner_margin = 0,
border_outer_margin = 0,
border_width = 0,
Colors in conky 1.10 do not use the #
anymore but i see you have tried both.
As for the conky discussion, i understand your point of view and for regular software development you are right. The other side of the story is that conkys development was (arguably is) going very slowly (note the 3 years release period between 1.9 and 1.10) and since the release of 1.10 the number of "stars" and "watchers" on github has about doubled (to be fair not many people knew about the move to github until 1.10). Some long existing, known, bugs were solved (some are still there) and there are more pull requests as before. I was not involved with conky pre 1.10 so my info might not be accurate but that's how i experienced it. Besides, as long as 1.10 was not released people were adding features to 1.9(.1) thus further complicating the development of 1.10 due to more backlog to port (note 1.9.1 has still some more features than 1.10 but since almost no one used 1.9.1, these went almost unnoticed). Releasing 1.10 also caused more bug reports on github since there were issues and without a release it wasn't going to be tested by enough people anyway (now they were forced to, eg. when the package was updated. Might also explain the many Arch users on the github at the start, since Arch Linux updates pretty fast.). You can argue the first users of 1.10 were effectively beta testers (note we are now already on maintenance release 2! Due to the many contributers). So if anything, in my opinion, the release was a good thing. But it indeed caused some irritations amongst the users, especially the "non programmer/technical".
(again, my opinion/point of view, this information might not be complete or be a one sided story)
Hi awilliamson and Nooby! I think you guys are right: this conky update is more than just an update. On one of my boxes (a pre historic netbook whick keep for its colour... I know... I apologise... =) I noticed that conky 1.10 is using a lot more resources than the old 1.9 version did. For now I pinned it on 1.9 while figuring out how to tackle it (or whether it is me being confused). As for the lua syntax: I adapted my conkies while checking out v1.10 and found that the main difference is in the config section. I'm sure purists and tweakers will call me blasphemous, others will tell me the internal "translator" will make an old style conky work, but then again, a quick check while updating is always welcome.
I found that operators are the same, although the syntax is different. Here are my 5 cents:
--[[ ===========================================================
CONKY EXAMPLE
Your notes here
===========================================================]]
conky.config = {
alignment = 'top_right',
background = true,
border_width = 0,
cpu_avg_samples = 2,
double_buffer = true,
draw_borders = false,
draw_graph_borders = false,
draw_outline = false,
draw_shades = true,
extra_newline = false,
font = 'Ubuntu:size=8',
gap_x = 10,
gap_y = 20,
imlib_cache_size = 0,
minimum_height = 800,
minimum_width = 240,
maximum_width = 240,
no_buffers = true,
out_to_console = false,
out_to_stderr = false,
own_window = true,
own_window_argb_visual = false,
own_window_class = 'Conky',
own_window_hints = "undecorated,below,sticky,skip_taskbar,skip_pager",
own_window_transparent = true,
own_window_type = 'desktop',
text_buffer_size = 2048,
override_utf8_locale = true,
total_run_times = 0,
uppercase = false,
update_interval = 1,
use_xft = true,
xftalpha = 1,
-- Belladonna COLOUR DEFINITION Examples
default_shade_color ='190101',
default_outline_color = '828282',
default_color = 'FFFFFF',
color1 = '8C0202',-- My colour def 1
color2 = 'BE0623',-- My colour def 2
color3 = 'FF0000',-- My colour def 3
color4 = '40F80D',-- My colour def 4
color5 = 'FF0000',-- My colour def 5
color6 = 'B2BCCA',-- My colour def 6
color7 = 'D56501',-- My colour def 7
-- Belladonna TEMPLATES
template0 = '${color orange}${font Ubuntu Mono:size=12:BOLD}',
template1 = '${font}\n${voffset -9}${color2}${hr}${color}${font}${voffset -2}',
template2 = '${voffset -5}${color6}${stippled_hr}${color}',
-- More templates here if you want to
}
conky.text = [[
# Put the TEXT component of your old conky here
${color6}${hr}
${alignr}This is a new syntax conky by ${color}YOU
]]
BTW Nooby I saw your discussion on the #! forum and resulting conky 1.10 design on DeviantArt -- which was absolutely stunning and lovely! Can I ask you something about that one? I saw you used the excellent conkybanshee script by kaivalagi, but not as it was configured originally (placing scripts in /usr/bin/... /usr/share/... and so on). I found that the old kaivalagi way of making conkybanshee work doesn't work anymore with 1.10. Can you tell us what you did? I mean, I think I saw in your conky scripts that you still call conkybanshee --datatype= in conky itself, but how/ what/ where did you do with the conkybanshee scripts/ code to make it work?
@ the performance: mmmh this is certainly not desired, conky 1.10 should not be heavier as 1.9 (for the same config).
@ config: some changes are now documented on the wiki: Configuration part and Text part (feel free to expand the wiki if there is something missing, or tell me and i will do it) There is also a page dedicated to the transition from 1.9 to 1.10, if you encountered something that is not on the page please add it (or if you have a general tip/trick for other users). Convert to new 1.10 syntax
Btw: it is recommended to use [[
... ]]
with templates (see #118 ) and if your mean new line with \n
in template1
it should be escaped; aka \\n
(ps: this is also mentioned in the manual)
@ Banshee: ooh did not even know your were supposed to put them there. I just made a file with the conky (text section) code concerning the banshee script (called them .template
; they are in the script/
folder). There i use the --datatype=
ect to request values from Banshee. To let the python script fill in the values i just use: ${execp /path/to/pythonBansheeScript.py --template=/path/to/.template file}
. Note the pyhon script is for python 2.7 (i changed the extension to .py2 so it automatically executes with python 2.7 on my system). The python script wilt spit out the conky code from the .template
file with the --datatype=
replaced with the correct values from banshee. The reason i put the values in the .template
file is to allow getting multiple values from banshee with a single call to the python script since calling it is not efficient at all (the alternative would be to call the python script for every value individually).
To be honest if the banshee project was more alive(and i had more time) i would probably add this functionality to conky itself (instead of the python script), which has been done for some other media players already.
I'm not sure whether or not i have changed something in the python script but i don't think so, anyway you can download the version i use from DeviantArt.
And thanks always nice to hear! I have many more ideas to do things (and add new features) with/to conky but at the moment (and near future) no time to execute them.
There is now a rough Lua tutorial on the wiki, unfortunately i don't have time to write a "make your own conky config" tutorial but ideally the wiki should have one.
I gave the wiki an overhaul some days ago so the info on the wiki was not available when this issue was submitted, i must admit there is still A LOT of room for improvement concerning the wiki but at least there is something now.
THX for coming back and sharing what you did with the conkybanshee script. I already noted the remark you made about the template and the one vs. multiple calls. That will come in handy. I've your conky from DeviantArt, which I'll dissect, I promise ;-). I agree that it would be smashing if Banshee, like for example Audacious, MPD, was a part of conky. But then again, it'll give me something to tinker with I suppose ;-)
@ performance & resources: Yes, I was surprised too, since everybody "promised" lower and not a higher system strain. But both on the pre historic netbook, and in a VM, where I repeated it to see whether I was cross eyed, I saw conky (conky-all that is) top percentages for 1.10.1 (the one that came with my new distro) that were roughly twice those for 1.9.0-4 and 1.9.0-6 (which I had before). And this was without anything fancy, just some system basics ($kernel, $uptime $memperc, $membar, 5 tops and some net up and down stats). Then again, if I did some syntax errors (nothing did show up in CLI however), could that push system strain higher?
@ wiki: Maybe this is a small, weird difference between 1.9 and 1.10 that easily slips through but can leave some people wonder? When I translated my 1.9 syntax conky to a 1.10 one, I saw unusual frequent connection spikes very few seconds. Took me a while to figure it out: turned out that the interval unit for RSS feeds changed from minutes to seconds. So in stead of getting an update every 10 minutes, conky did it every 10 seconds. I also had some $execi wget statements to grab info, but those were still in secs I noticed, so as they were before... And another thing, since we're talking Banshee. I saw that with the *buntu 16.04 LTS releases, Banshee becomes "Main Thread" when it is running. I realise this is not a conky thing, but then again, if you want to do a ${if_running} in conky...
THX also for the pointer on the template [[ ]], \n, and the link to https://github.com/brndnmtthws/conky/issues/118. As awilliamson said, I took what little I could find, and "guestimated" the rest I'm afraid!
@ performance: possibly, can not really comment on that since i do not have a clear view on the inner workings of conky (never had a look at it).
@ wiki: Thanks for the RSS remark! I have verified your findings and indeed, it is in seconds now ( this is more consistent with other variables anyway). The current documentation was wrong, i have made a Pull Request #261. I have also updated the wiki page.
If you find any more issues/inconsitencies/trick/tips ect please let me know! (or questions)
@ if_running: yea.. basically it's a pain in the ass (for Banshee). Usually the programs have a nice name but Banshee does not. I have had issues with it too. I just tried things (eg. "Main Thread", "banshee /usr/lib/banshee/Banshee.exe --redirect-log --play-enqueued", ...) until something worked, at the moment i do not have a working version (i'm trying clementine at the moment). Also take a look at: #121 and #131
@ performance: hope it's just me being cross eyed. I suppose it jumped out at me because the netbook is sooooo pre-historic, if it would show somewhere, it is there. Like I said, have it pinned to 1.9 for now, but will revisit later if I've got more time. Will report back then...
@ wiki: yeah, that one surprised me too. But figured it out... after 3 days =0
Thanks for changing it on the wiki page!
@ if_running: But it probably isn't a Banshee thing, because both on my 14.04 and 16.04 boxes there is the same Banshee 2.6.2, and (only) on 16.04 top in CLI shows Banshee as Main Thread. Might it be the fact that Banshee is mono, which "works" differently in 16.04? I did find though that ${if running Main Thread}
did work for me. Messy, but it works... If you want the full code of what I tried and worked in 16.04 for Banshee, let me know, think I've still got it somewhere...
BTW, had same knee jerk reaction like you: looked into other players, amplified also by an "actually don't need mono" itch, but didn't like interface of any of them. Call me conservative. Was slightly charmed by Quod Libet though, even got it going in conky in a jiffy with e.g. ${execi 5 quodlibet --print-playing "<artist>"}
, but will never understand why devs always want to supply me with obligatory, huge list of gernes or radio stations, which silly people like me can't remove and might classify as screen pollution ;-). Then again, "if it's not broken, don't fix it" does still apply for (lazy old) me for now, so I'm still in tinker mode...
@ performance - additional: Had a chance today to grab and check the conky-all 1.10.2-1 version, which is in Debian testing. As before I ran it on the same system with the same configuration, and of course same conky script. In this version too I saw an increase of CPU load. It was (again) roughly twice that of the 1.9 version. It also looked like the 1.10.2 used more than the 1.10.1 version, but that could very well be random variability. I think it would be best to focus on the difference between 1.9 and 1.10, which seems obvious and significant.
Hi Nooby! I looked again at the alledged higher system load of conky 1.9 vs 1.10... and found something very weird. When I compared cpu load percentages of conky 1.9, top in CLI, and xfce-taskmanager, I saw this:
As you can see, top gives values for the same process/ PID which are roughly twice conky's values. However, doing the same with xfce-taskmanager, I saw:
... that the values of conky and xfce-taskmanager are identical. Now, I have no idea how top can give these values, or whether these are correct. It's a bit above my proficiency level I'm afraid. I haven't had the opportunity yet to repeat this with 1.10, but could it be that conky 1.10 doesn't have a system load twice that of 1.9 like I mentioned before, but that the numbers reported are the issue?
Possible and plausible, considering there is something similar going on for the memory readings (htop, conky, ... all give different values. Unfortunately i can not find that issue/discussion any more atm).
There seems to be a pattern here: this is my production machine, which is a quad core. And here top and htop report cpu values which are roughly 4 times higher than the conky (1.9) cpu values...
On this box too, xfce4-taskmanager shows values lower than htop and top, but similar to conky. If you guys are interested, I can come back with values for 1.10 when I've translated and installed.
OK, so I installed conky-all 1.10-3 on the same pre-historic netbook I mentioned earlier, and translated my previous conky config to lua syntax. Did not change any of the conky tasks or configurations, just “translated” the conky.config ={ } section, and pasted my previous conky TEXT in the conky.text = [[ ]] section. Results are:
To rule out any potential influence of weird syntax errors, or difficult, "heavy" processes, I decided to double-check with conky's own example conky. When this was run on my lovely 7 year old netbook, the cpu load with conky 1.10-3 was twice that of conky 1.9.0-6 (average 3% vs. 1.5%).
I realise these final values are small, as are the differences, so one could argue their significance. But if this is indeed a genuine, non-isolated finding, it also means that the (difference in) use of resources increases not only significantly with the use of the newer version, but also increases disproportionally for both versions with a more “sophisticated”, complex conky.
I'm afraid this all that I can do concerning this, and therefore leave it gracefully to the devs to either ignore, or act on it. m( )m
That's a rather unpleasant result although i'm afraid fixing it will not be straight forward and not done any time soon if at all.
Closing old discussions about syntax changes and issues surrounding the said changes. Thanks.
New 1.10 proves troublesome for me due to the different syntax and configuration API changes.
I've managed to figure out TEXT, but it's floating away from the bar and not aligned properly at all.
What would the be current equivalent of
I had a row of values, right-aligned, on my i3 bar, and did conditional coloring. So far I've only been able to put in basic text and command outputs.
I understand this may not exactly be an issue with the platform but rather my misunderstanding of the latest changes. But I feel this may not be an isolated incident, users ( as they start to upgrade ) will slowly begin to realise the configuration change and seek the documentation. Whilst provided, it doesn't ( in a concise way ) lay out the power of the old config, or their current alternatives.
Perhaps it could be suggested to have a simple 'common' use-case, comparing old-for-new. Making it easier for users to migrate?
I look forward to your response.