RE: remmina in awesone - Different behaviour for RDP of Windows XP and Windows 7
Thanks! I hadn't tried that - Now I have - It worked! To get it to happen automagically I added this in the signals... -- Automatically float certain windows if c.name == david2 then awful.client.fullscreen.set(c, true) end Then I realised it was my own fault as I had actually caused it myself when I'd done this some time back... -- Adjust the geometry settings so windows do not cover the tray if not (c.name == david or c.name == Guake!) then local geometry = c:geometry() if geometry.y mywibox[c.screen]:geometry().y + mywibox[c.screen]:geometry().height then geometry.y = mywibox[c.screen]:geometry().y + mywibox[c.screen]:geometry().height + c.border_width c:geometry(geometry) end end Doh! Added or c.name == david2 and it gave me what I'd expected. Thanks for the reply as it got me back on track! PS: Must investigate if fullscreen is a better choice or if the geometry idea was a good one - comments welcome! Thanks again! -Original Message- From: m...@enric.me [mailto:m...@enric.me] Sent: Wednesday, 13 February 2013 3:33 AM To: davidsorkov...@hotmail.com Subject: Re: remmina in awesone - Different behaviour for RDP of Windows XP and Windows 7 Hey David, Have you tried mod4 + f? It's the default keybinding for fullscreen. You can also setup a rule for that. Not posting to the list because i'm on my phone, and it doesn't support mailing lists. Cheers --- Original message --- From: David Sorkovsky davidsorkov...@hotmail.com To: Sent: 11.2.'13, 12:02 Hi All, I've been using an Windows XP Virtual Machine for quite a while now. I run it headless and access it through RDP using remmina, running in Awesome - All great - Especially that when I put remmina into full screen mode as it uses the entire display, completely covering the tray. Then I just use Mod 4 # to change to another Awesome pane/desktop/? and so on. Now for the strange/interesting part. I just setup a Windows 7 VM in Virtualbox but this time, running headless and using remmina to RDP in, fullscreen mode does NOT cover the entire screen, but leaves the tray (only uses the viewport?) Anyone know where I should start to look to adjust the Windows 7 VM to use the full screen rather than just the viewport? Virtualbox, virtualbox client extensions, remmina, awesome, X, other??? Thanks in advance Dave -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: theming of font attributes
On 2013-01-08, Daniel qu...@hack.org wrote: I was thinking about adding attrs_normal, attrs_focus etc to the theming. These would be appropriately passed into the span font_desc=… of (at least) taglist.lua and tasklist.lua, to allow setting different attributes (italic, underline etc) according to: http://developer.gnome.org/pygtk/2.22/pango-markup-language.html For example: attrs_normal = attrs_focus = underline='single' attrs_urgent = style='italic' I first considered font_normal, font_focus etc, but I saw that with font_desc it's only possible to set italic and bold, not underline (which is what I wanted in the first place for my focused tasks). Another idea: textformat_normal = small%s/small textformat_focus = u%s/u Any thoughts on this? I will work on a patch when I have time... No comments or ideas? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: visible attribute for wibox.widget objects in Awesome 3.5
You might find this helpful.
http://thread.gmane.org/gmane.comp.window-managers.awesome/9659/focus=9662
On Mon, Feb 11, 2013 at 1:54 PM, Jacco jacco.g...@gmail.com wrote:
Hi,
Today I ported my configuration to 3.5. I really like the changes, but I
am missing a certain feature. Previously I could turn the visibility of
a widget object on or off.
example = widget({ type = imagebox })
example.visible = false
I have yet to find an equivalent. I turn the visibility of widgets on
and off based on certain events, ie hide all mpd controls except play if
mpd isn't playing or don't show up/down rates of network interfaces that
aren't connect, this prevents my wiboxes from cluttering with pointless
information.
Short story: how to do this with wibox.widget objects? Specifically
wibox.widget.imagebox and wibox.widget.textbox.
Thanks for you help.
Regards,
Jacco
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: visible attribute for wibox.widget objects in Awesome 3.5
Hi Sean,
Thanks, I'll try it this way.
Cheers!
Jacco
Sean Goodwin sean.e.good...@gmail.com writes:
You might find this helpful.
http://thread.gmane.org/gmane.comp.window-managers.awesome/9659/focus=9662
On Mon, Feb 11, 2013 at 1:54 PM, Jacco jacco.g...@gmail.com wrote:
Hi,
Today I ported my configuration to 3.5. I really like the changes,
but I
am missing a certain feature. Previously I could turn the
visibility of
a widget object on or off.
example = widget({ type = imagebox })
example.visible = false
I have yet to find an equivalent. I turn the visibility of widgets
on
and off based on certain events, ie hide all mpd controls except
play if
mpd isn't playing or don't show up/down rates of network
interfaces that
aren't connect, this prevents my wiboxes from cluttering with
pointless
information.
Short story: how to do this with wibox.widget objects?
Specifically
wibox.widget.imagebox and wibox.widget.textbox.
Thanks for you help.
Regards,
Jacco
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
--
Jacco
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
[awesome bugs] #1112 - Notifications with icons cause awesome to block
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Uwe L. Korn (xhochy) Attached to Project - awesome Summary - Notifications with icons cause awesome to block Task Type - Bug Report Category - naughty Status - Unconfirmed Assigned To - Operating System - Linux Severity - Low Priority - Normal Reported Version - 3.5 Due in Version - Undecided Due Date - Undecided Details - If a D-Bus notification contains an image awesome blocks for a short time (less than 1 second for 128x128 images) but as images get larger, e.g. 300x300px it could block up to 20s. This happens with awesome 3.4.11 and 3.5 Related bug report: https://bugs.tomahawk-player.org/browse/TWK-1243 More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1112 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] #1112 - Notifications with icons cause awesome to block
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1112 - Notifications with icons cause awesome to block User who did this - Uli Schlachter (psychon) -- Could you launch dbus-monitor and get me the raw data for some of these? Awesome handles these notifications in lua and gets the pixel data as a string. (For 3.5) it then has to convert this pixel data into a cairo image surface and for that it does some substring-and-reverse-string-magic which can't possibly be fast. It might be possible to add a fast path if the pixel data already matches what cairo expects, but I fear that this is just way too different from what the notification spec dictates. Of course, someone has to make sure that it really is this part which is slow (dunno how I can easily generate such a notification to test), but it seems like the most likely cause to me. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1112#comment3446 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] #1112 - Notifications with icons cause awesome to block (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1112 - Notifications with icons cause awesome to block User who did this - Uwe L. Korn (xhochy) -- A simple notification using a 500x500px logo. Took 3 Minutes until it was displayed -- 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=1112#comment3447 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] #1113 - Vicious widgets stop responding to buttons (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Jonas Møller (yoanar)
Attached to Project - awesome
Summary - Vicious widgets stop responding to buttons
Task Type - Bug Report
Category - Widgets
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 3.5
Due in Version - Undecided
Due Date - Undecided
Details - awesome -v gives me v3.4.13 which i got using apt-get on Ubuntu
12.04.
The problem is that the lua widgets using vicious somehow stop responding to
mouse-events.
I know that the AwesomeMPD widget is still responding when the others aren't.
The problem doesn't _appear_ to be caused by an action, whenever i've run
Awesome for a while
they just stop responding all the sudden. It doesn't seem to require a certain
amount of presses,
it just happens at a seamingly random point. The widgets still update tho'. And
the mouse of course
functions as normal elsewhere.
Example code:
tb_volume = widget({ type = textbox, name = tb_volume, align = right })
tb_volume:buttons({
button({ }, 4, function () volume(up, tb_volume) end),
button({ }, 5, function () volume(down, tb_volume) end),
button({ }, 1, function () volume(mute, tb_volume) end)
})
I know for certain that the volume() function used in the example is not the
source of the error, because
absolutely all widgets that are constructed in a similar fasion also
experience the error.
I'm also going to attach my entire rc.lua file.
I realize i might have provided an insufficient amount of information, but i
really don't know where to start.
So if you need more info to fix the bug, just send me a message and i'll
provide it.
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=1113
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] #1082 - Resize operation does not end after unclicking (intermittent)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1082 - Resize operation does not end after unclicking (intermittent) User who did this - Timothy T (d4ft) -- I've had no issues with the default configuration file. However, the moment I add a mouse binding to 'clientbuttons', the bug surfaces. So I'm wondering whether those who have this bug also have a mouse binding, specifically in clientbuttons? I use a Logitech G700 and have many mouse bindings in 'clientbuttons' and am able to reproduce this bug with just one of my own enabled. I've bound button 12 to maximizing/restoring a window (exact code found in Modkey + M). 1. In the default layout, open any window (thunar, rxvt etc.) 2. Maximize and restore the window with the button (12 in this case) without leaving the window. 3. Now try to resize with the mod key and button 3 of your mouse In fact, this also applies to trying to move windows after the above operation is performed. After some button mashing on the mouse, I get my arrow cursor back, but maxmizing of a window does not work anymore. I suppose any weird behavior that occurs are related to mouse bindings specifically in 'clientbuttons'. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1082#comment3448 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.
