[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 - Uli Schlachter (psychon) -- I noticed now if I disable compton and use these options below conky runs ok and transparent, but I can't use compton still. So you are now saying this a bug between compton and conky? Awesome has nothing to do with it? -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1272#comment4077 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...
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1273 - WeeChat Window Getting Destoryed With ModM Basic Actions... User who did this - Uli Schlachter (psychon) -- From the screenshot I guess this must be a problem between your terminal and weechat. Window managers only place windows, they do not influence a window's content. And since your terminal's content is still possible to draw via a terminal (e.g. no characters cut in half), I bet your terminal must be messing something up and weechat gets confused about the size of the terminal. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1273#comment4078 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?
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1274 - Restarting or Changing Windows - ModM Not Working Correct? User who did this - Uli Schlachter (psychon) -- Sorry, I am confused. Could you describe your issue in other words? Right now I feel like you are describing the same thing three times and I am not sure where the repeating part starts... All that mod4+m does is toggling maximized. When unmaximizing a window, it should get the size that it had before it was maximized? -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1274#comment4079 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. The following task has a new comment added: FS#1275 - Unwanted accidental screen changes caused by bogus xcb_generic_event User who did this - Uli Schlachter (psychon) -- 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 You mean awful.tag.withcurrent, right? So firefox gives us a specific position for its window in a ConfigureRequest, we obey and put it at that position (which happens to be on another screen than what it is on currently) and awful.tag.withcurrent gets called due to the resulting property::screen signal. Hm. Why am I not allowed to blame firefox here? :( We could change event_handle_configurerequest() to just emit request::x, y, width, height, border_width etc signals, but (a) this would mean we would violate ICCCM (we have to take special action if we ignore the configure request) and (b) I don't see how this really helps with clients moving themselves to another screen during startup. Also, I don't see *why* firefox does this at all. If it wants to restore some saved window position, then there is a proper, non-flickering approach for doing that. So it must be doing something else...? -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1275#comment4080 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] #1270 - Stacking issue with awful.layout.max + clients tagged on multiple tags
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1270 - Stacking issue with awful.layout.max + clients tagged on multiple tags User who did this - Uli Schlachter (psychon) -- Uhm. So you are just complaining about the unexpected behavior, right? You do know that we have a single, global stacking order for clients instead of per-tag local ones, right? -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1270#comment4081 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] #1270 - Stacking issue with awful.layout.max + clients tagged on multiple tags
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1270 - Stacking issue with awful.layout.max + clients tagged on multiple tags User who did this - Emmanuel Lepage Vallee (Elv13) -- Yea, my opinion is that the max (aka stack) layout should keep it's own as it is a stack. Anyway, this is more about documenting this bug than saying it is high priority. We should find a solution, eventually. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1270#comment4082 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. The following task has a new comment added: FS#1275 - Unwanted accidental screen changes caused by bogus xcb_generic_event User who did this - Emmanuel Lepage Vallee (Elv13) -- On top of that, we then ignore the x, y, width and height arguments as it is added to a tag layout and resized anyway, so the only thing that happen is the window going into a random tag with no way to enforce the rules (well, Tyrannical rules). So, the possible solutions are: 1) Add the request x, y, width and height as suggested (+ convert the x,y ones into ::screen, as they are the only ones that really affect the user of those bugus softwares) 2) Add a new client properties to disable those events, something like ignore_external_resize. This wont generally solve the problem, but there is not that many clients like that Pick one and I will send a patch. In general this should not happen, but I saw it a few time and this is the first time I digg into this. As always, my opinion is that there should be a way to prevent clients from skipping the rule system and doing whatever they want. This was the whole point of the request:: system. But leave the current behavior as the default one. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1275#comment4083 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.