[awesome bugs] #1271 - Placment rule for xcalc only obeyed some times
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - David Fabijan (McLenin)
Attached to Project - awesome
Summary - Placment rule for xcalc only obeyed some times
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - 3.5.5
Due in Version - Undecided
Due Date - Undecided
Details - I'm using the rule
{ rule = { class = XCalc },
properties = { floating = true , x = 100, y = 100 } },
and xcalc always obeys the floating part, but only occasionally the x,y part.
On some restarts of awesome the postioning works, while on others it just
always positions a new xcalc window at x=0, y just below the awesome bar. Not
sure how to diagnose the problem more specifically.
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1271
You are receiving this message because you have requested it from the Flyspray
bugtracking system. If you did not expect this message or don't want to
receive mails in future, you can change your notification settings at the URL
shown above.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1272 - Conky Crashes With own_window_transparent yes
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - AwesomeBug (AwesomeBug)
Attached to Project - awesome
Summary - Conky Crashes With own_window_transparent yes
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - git/master
Due in Version - Undecided
Due Date - Undecided
Details - Hello,
Specs:
Slackware 14.1 x86_64
xorg-server-1.14.3
Awesome 3.5.5
Nvidia GTX660M - 331.67 drivers
Conky 1.9.0
I've been told this might be a conky bug, but I've never had crashes with conky
ever and this script runs fine in other DE/WM; KDE, Gnome, Xfce, Openbox.
This is my script
-
background yes
use_xft yes
xftfont aller:size=9
xftalpha 0.8
out_to_console no
update_interval 3.0
total_run_times 0
draw_shades no
own_window yes
own_window_type desktop# normal /override /desktop
own_window_transparent yes
own_window_hints undecorate,sticky,skip_taskbar,skip_pager,below,sticky
minimum_size 1920
maximum_width 1920
double_buffer yes
default_color e3412c
color1 DDBBAA
alignment top_middle
gap_y 5 #vertical
#gap_x 0 #horizontal
no_buffers yes
TEXT
${alignc}${color}CPU1: ${color1}${cpu cpu0}% \
${color}CPU2: ${color1}${cpu cpu1}% \
${color}CPU3: ${color1}${cpu cpu2}% \
${color}CPU4: ${color1}${cpu cpu3}% - ${freq}MHz - ${platform coretemp.0 temp
1} °C \
${color}GPU: ${color1}${execi 100 nvidia-settings -q gpucoretemp -t | head -1}
°C \
${color}RAM: ${color1}${mem} - $memperc% \
${color}SSD: ${color1}${fs_free /} free \
${color}LAN: ${color1}${addr eth0} - ${downspeed eth0} kb/s down - ${upspeed
eth0} kb/s up \
${color}POWER: ${color1}${acpiacadapter AC0} - Battery: ${battery_percent
BAT0}% ${battery_time BAT0} \
${color}UP: ${color1}$uptime
#|--Battery-OSD
${execi 70 ~/.conky/scripts/battery_notify.sh}
-
And when I try running conky this is the ouput I'm getting;
Conky: forked to background, pid is 7423
Conky: desktop window (289) is root window
Conky: window type - desktop
Conky: drawing to created window (0xc1)
Conky: drawing to double buffer
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Serial number of failed request: 237
Current serial number in output stream: 238
I've tried several options and the only thing I can get to work is with
override, but I like using compton and this draws shadows around it.
I've been testing conky without compton running, this is why I didn't list it
for 'specs'
Thank you! :)
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1272
You are receiving this message because you have requested it from the Flyspray
bugtracking system. If you did not expect this message or don't want to
receive mails in future, you can change your notification settings at the URL
shown above.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1272 - Conky Crashes With own_window_transparent yes
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1272 - Conky Crashes With own_window_transparent yes User who did this - AwesomeBug (AwesomeBug) -- I ran for debug; conky -DD -c horizontal.orange Here's ouput; DEBUG(0) [conky.c:5338]: reading contents from config file 'horizontal.orange' DEBUG(1) [core.c:1225]: no templates to replace DEBUG(1) [core.c:354]: Adding $cpu for CPU 0 DEBUG(1) [core.c:354]: Adding $cpu for CPU 1 DEBUG(1) [core.c:354]: Adding $cpu for CPU 2 DEBUG(1) [core.c:354]: Adding $cpu for CPU 3 DEBUG(0) [linux.c:1058]: parsed platform args: 'coretemp.0' 'temp' 1 1.00 0.00 Conky: forked to background, pid is 10053 Conky: desktop window (289) is root window Conky: window type - desktop Conky: drawing to created window (0x121) Conky: drawing to double buffer X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 2 (X_ChangeWindowAttributes) Serial number of failed request: 349 Current serial number in output stream: 350 -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1272#comment4075 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1272 - Conky Crashes With own_window_transparent yes
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1272 - Conky Crashes With own_window_transparent yes User who did this - AwesomeBug (AwesomeBug) -- I noticed now if I disable compton and use these options below conky runs ok and transparent, but I can't use compton still. own_window no own_window_class Conky own_window_type normal# normal /override /desktop own_window_transparent yes own_window_hints undecorate,sticky,skip_taskbar,skip_pager,below Again I've been told this might be a conky bug but I've never had a problem ever running Conky under several different desktops and window managers in about five years till now. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1272#comment4076 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1273 - WeeChat Window Getting Destoryed With ModM Basic Actions... (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - AwesomeBug (AwesomeBug) Attached to Project - awesome Summary - WeeChat Window Getting Destoryed With ModM Basic Actions... Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To - Operating System - Linux Severity - High Priority - Normal Reported Version - 3.5.5 Due in Version - Undecided Due Date - Undecided Details - Hello, Specs: Slackware 14.1 x86_64 xorg-server-1.14.3 Awesome 3.5.5 Nvidia GTX660M - 331.67 drivers rxvt-unicode-9.20 WeeChat 0.4.3 In rc.lua I'm starting WeeChat as such; WeeChat, urxvt -geometry 120x25 -e weechat Then many times, if I use ModM and make the window larger or run ModM again and make it smaller the WeeChat window will get messed up. I'm attaching a screen shot for you to see called; weechat.jpg Also just doing basic random things in Awesome, like changing the desktop windows from floating to tile on another desktop, then changing them back, or just moving back and forth across the desktop and then returning to where weechat is, I've noticed sometimes these slightest things have an effect also on the window becoming messed up, but not like the screen shot I'm attaching. What I've noticed also is you're not suppose to be able to mouse wheel scroll in weechat, but Awesome is creating this, it's the other effect I meant it also going on. The windows only scroll up and down with key shortcut PgUp PgDn, but Awesome messes up the window and the mouse actions can be used. I also had WeeChat get messed up, again by just doing basic things on the desktop(s) and the WeeChat one time, I couldn't copy and paste, and then when I dragged the mouse to copy, instead it would cause weechat to change windows. In some strange way, when WeeChat is suppose to be a key shortcut driven application like Awesome, Awesome is messing this up somehow and allowing it to use the mouse and then screwing up WeeChat actions and windows. One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1273 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1274 - Restarting or Changing Windows - ModM Not Working Correct? (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - AwesomeBug (AwesomeBug) Attached to Project - awesome Summary - Restarting or Changing Windows - ModM Not Working Correct? Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To - Operating System - Linux Severity - High Priority - Normal Reported Version - 3.5.5 Due in Version - Undecided Due Date - Undecided Details - Hello, Specs: Slackware 14.1 x86_64 xorg-server-1.14.3 Awesome 3.5.5 Nvidia GTX660M - 331.67 drivers I'm reporting this as a bug, it's my understanding this is not how the ModM feature of making a window small and larger is suppose to work. I noticed as an example, even with a stock rc.lua file, if I do 'Mod Enter' and the terminal opens I can then do ModM and maximize the window, then do ModM again and make it the default size when it was first opened. Typically what I've noticed is most windows need to be maximized for this to happen, but on occassion I've also noticed it doesn't matter. Then when I do either action, restart Awesome, or with only this one window open on a desktop, click the box next to the clock to scroll through the various tile features, and then put it back to the default I had it on, the box with the blob lower left, then I try ModM again, with the window maximized, it only moves up and down about 1/4 from the bottom. I press ModM and the bottom of the window moves up 1/4 and then there's a gap at the bottom. I press ModM and the bottom moves down 1/4 of an inch, this time resting on the top of the taksbar. And many times also, after the restart, or scrolling through tile functions, the window has the gap at the bottom in a maxmized size, then I try ModM again, and the bottom moves down, and then I try ModM again, but the window just sits there and flickers and doesn't even move anymore, not even the slighest movement in size, just flickers. The ModM function of making the window small like the default size when opening the window for the first time, going from maximize to small again never works, after a restart or scrolling through the tile options, and isn't it suppose to maximize and then go back to the default small size? I'm attaching a screen shot called gap showing the gap that is first created from the restart or tile function change on a maximized terminal or window. One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1274 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1275 - Unwanted accidental screen changes caused by bogus xcb_generic_event
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Emmanuel Lepage Vallee (Elv13) Attached to Project - awesome Summary - Unwanted accidental screen changes caused by bogus xcb_generic_event Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - git/master Due in Version - Undecided Due Date - Undecided Details - Ok, that one was long to debug... Long story short, I open firefox on screen 1, it flicker then move on screen 2, in the selected tag instead of the www one. Great... Why? After much foobar-ism, I managed to track this down to withcurrent being called by an xcb_generic_event at #3 0x00412e1a in event_handle_configurerequest (ev=0x1d93bd0) at /home/kde-devel/kde/src/awesome/event.c:345 if added this to client_resize_do printf(\n WINID %d From resize %d %d x %d %d w %d %d\n,c-window,screen_get_index(c-screen),screen_get_index(new_screen),old_geometry.x,geometry.x,old_geometry.width,geometry.width); and got: HERE C Mozilla Firefox TAG Internet WINID 41943231 From resize 1 1 x 1920 1920 w 1918 1918 WINID 41943231 From resize 1 1 x 1920 1920 w 1918 1918 TSTBrowser::restoreTree level = 1 tabsToRestore = 1 WINID 41943231 From resize 1 1 x 0 1920 w 1918 1918 WINID 41943231 From resize 1 2 x 1920 0 w 1918 1918 TSTBrowser::restoreTree level = 1 tabsToRestore = 1 TSTBrowser::restoreTree level = 1 tabsToRestore = 64 restoring member tabs = 64 HERE WITHCURRENT INVALID SCREEN CHANGE! sorry for all the prints with useless names, but at some point, you can see that the screen change when firefox restore the session do you think we should first check that in event.c before calling resize to prevent accidental screen changes? Or is it better to add a request::screen as suggested before to avoid this situation? More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1275 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
