Conky looks different on autostart than with manual start using XFCE #218
Comments
|
I'm just some random person- but it's possible that your resolution changes in some way after conky is loaded. You could try adding sleep 5; or something before the command in xfce, but I don't know how xfce loads, so that could delay everything instead of just conky. |
|
Well yes, it actually does work to change I tried rearranging the order in my If the order of This also works: But these orders don't and this This seems to indicate, that one of these two are the reason: I fairly doubt it's As the problem doesn't appear on consecutive refreshs the bug should be inside some initialization routine of conky. Btw: Everything, Slim, Virtual terminals, should have 1920x1080 pixel, so I don't think this is a problem with changing resolution. |
|
Hmm~. Personally, I have conky in my i3 startup config with no delays, and it works fine. Does SLIM have the correct resolution and everything? Meaning having it the same as your login. |
|
Of all the bugs I encounter daily since switching to Linux, this is one of the least obnoxious ones :). But thank you for your empathy. Other bugs like having to append 'i915.modeset=0' in GRUB every time I boot, or In order to not let this go offtopic I did some tests, too: diff --git a/src/fonts.h b/src/fonts.h
index 00b2265..017c4da 100644
--- a/src/fonts.h
+++ b/src/fonts.h
@@ -57,12 +57,13 @@ struct font_list {
#ifdef BUILD_XFT
-#define font_height() (use_xft.get(*state) ? (fonts[selected_font].xftfont->ascent + \
- fonts[selected_font].xftfont->descent) \
- : (fonts[selected_font].font->max_bounds.ascent + \
- fonts[selected_font].font->max_bounds.descent))
-#define font_ascent() (use_xft.get(*state) ? fonts[selected_font].xftfont->ascent \
- : fonts[selected_font].font->max_bounds.ascent)
+/* Changing this to e.g. 10 will only result in smaller conky window, but the
+ * text and graphs are rendered correctly, especially with the correct distance
+ * from each other, meaning only things down will not be displayed ... */
+#define font_height() 11
+/* Changing this to e.g. 8 will affect the spacing between lines. Even if
+ * those lines contain graphs. It's comparable to \baselineskip in LaTeX */
+#define font_ascent() 8
#define font_descent() (use_xft.get(*state) ? fonts[selected_font].xftfont->descent \
: fonts[selected_font].font->max_bounds.descent)But this is weird, because
So I added some debug printfs and I changed my autostart command to On a manual start the output is this: Actually it turns out There is no error about "font couldn't be opened". In both cases the font is loaded by the same line: fonts[i].xftfont = XftFontOpenName(display, screen, fonts[i].name.c_str());In both cases the parameters given seem to be similar, except the display pointer, but the display size which was returned by that display object is the same,... Still the returned font has a different The display is set by static void init_X11()
{
if (!display) {
const std::string &dispstr = display_name.get(*state).c_str();
// passing NULL to XOpenDisplay should open the default display
const char *disp = dispstr.size() ? dispstr.c_str() : NULL;
if ((display = XOpenDisplay(disp)) == NULL) {
throw std::runtime_error(std::string("can't open display: ") + XDisplayName(disp));
}
}The display pointers changes on every manual start, so I don't think it matters much if they are different. |
|
Looking over everything I could grasp, it seems like something is changing how X FreeType responds to conky in the initial stages of launching. Because with a bit of a delay it does this less often, yes? I'm not sure what that grub line does, but I've had no such issue. Might be distro specific. You can also just append that line directly to /boot/grub/grub.cfg in the place that looks the same as where you normally add it, then it should show up when you boot, thus preventing you from having to manually append it. Personally, I use i3wm, and manually close the majority of my programs before shutting down each day, and haven't noticed such an issue. I assume that's for performance, as people would get annoyed if xfce took forever to logout. I might suggest closing them manually, or writing your own script that closes them all, then executes the logout command. I'll try doing some edits to my conkyrc, test your conky rc file, and see if I get any similar issues at all. |
|
With delay conky works (I currently have 1s delay).
|
|
In your config, you have use_xft to true. If you set this to false, can you reproduce the issue? If you can't, that would tell us it has more to do with libxft than anything, yes? Glad the delay works for you. It might not be relevant, but out of curiosity, what graphics driver are you using? I'm running nvidia, so there could be a difference there as well. Though it'd be kind of odd if that caused it, it doesn't seem impossible to me. |
|
Wow thanks for mentioning of the public IP! I noticed that sometimes conky seemed to never load or takes a very long time. But the bug was so unspecific I couldn't open an issue.
With Also I'm using the NVIDIA proprietary drivers: |
|
Glad my comment helped. xP Alright. I only have a singular libxft package, so I wasn't sure. To be fair, I'm also not compiling conky from source. I agree completely that the fonts aren't nearly as pretty. I tried the option and instantly changed it back. However, that does give us way more certainty that the interaction with xft is the issue. As your nvidia driver is the same as mine, and I don't experience the issue, I'll say that's not it. Now, there's a few questions I have. For example: Why does the 1s delay fix the issue? I realize these seem pretty irrelevant to the issue we've pinned down, but as the 1s delay helps, it might be worth testing to see if we can find out "why" it helps. |
|
As for the different desktop environments and window managers. I could try this in some days, currently this is too much time. This 1s offset also intrigued me, that's why I did try to get some info about started process order with |
|
That's interesting. I actually use override, as i3WM otherwise completely fucks conky and makes it into a cute little window that gets in my way. I don't have any issues with transparency, either. Wonder what the difference is. Might be something else in my config. That's fine, it was just a suggestion worth testing. I'd assume something is being done in the first second, and using a different desktop environment might do it faster, and thus not display the issue. I'm not sure the test will give us any valuable data beyond that, though. You could try disabling a bunch of other startup stuff, and see if you find something specific. But I believe you mentioned you tried setting conky to start last, and it still had the issue sometimes. I can't think of anything else at the moment. I believe most, if not all, of the information needed to debug the issue should be somewhere in this issue now, though, so hopefully the dev will take a peek. Good luck with your other bugs! |
|
2 years 6 months passed. Can you determine if you're still having this problem today on |
|
I think this issue is probably happening to me too (macOS). The weird thing is that if you kill conky and run it again it shows up correctly. (The second time is always correct.) |
|
To make things a bit easier, the diff between @mxmlnkn's debug printfs is... diff --git a/mx-a b/mx-b
index 93734ea..00c346b 100644
--- a/mx-a
+++ b/mx-b
@@ -5,9 +5,10 @@ Init X11
update_workarea
init_windowupdate_workarea
[load_fonts] use_xft.get(*state) == true
-[load_fonts] fonts[0].xftfont = XftFontOpenName( display=0xad1700(display_width=1920, display_height=1080), screen=0, fonts[0].name.c_str()=Droid Sans:size=8 );
-[load_fonts][a] fonts[0].xftfont->ascent = 9
-[main_loop] font_ascent() = 9, font_descent() = 2, font_height() = 11
+[load_fonts] fonts[0].xftfont = XftFontOpenName( display=0x1efa700(display_width=1920, display_height=1080), screen=0, fonts[0].name.c_str()=Droid Sans:size=8 );
+[load_fonts][a] fonts[0].xftfont->ascent = 10
+[main_loop] font_ascent() = 10, font_descent() = 3, font_height() = 13
+[load_fonts] use_xft.get(*state) == true
[load_fonts] use_xft.get(*state) == true
[load_fonts] use_xft.get(*state) == true
[load_fonts] use_xft.get(*state) == trueNoticing
I wonder what happen when you edit the config to force conky reload, does it give you correct output this time or do we explicitly have to |
|
Hello everyone. Can you try this again on |
|
The issue still exists on Ubuntu 22.04 with Conky 1.12.2. A sleep in the startup script fixes the font issue. |
|
Yes, interestingly I started seeing this bug after the upgrade from 20.04 to 22.04. |
|
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
bot
added
the
Stale
|
This issue was closed because it has been stalled for 30 days with no activity. |
I added conky in
xfce4-session-settings-> Application Autostart add withconky -c /home/mxmlnkn/etc/conky.conkyrcWhen logging in to XFCE using e.g. slim login manager (I think it shouldn't matter), then conky looks different than when starting conky manually with the above command.
One frame was made with the autostarted version of conky, which was already running more than a day. The other frame was made 3 seconds later after
pkill conky; conky -c /home/mxmlnkn/etc/conky.conkyrc.Differences in the manually started version:
fs_barstatements instead of 0 pixelscpu_graphsin the CPU-section have a overlap of 4 pixels instead of being a perfect fit (the lower 1px border of the upper graph lies on top of the 1px upper border of the lower graph, resulting in a perfect 1 px border between the two graphs)Also there is something I never noticed, but I guess this is a different bug:
This bug could be related to #199
This is my conkyrc:
The text was updated successfully, but these errors were encountered: