Re: XCB support in cairo phased out?
On Mon, 2011-03-21 at 16:09 +0100, Julien Danjou wrote: > On Mon, Mar 21 2011, Uli Schlachter wrote: > > > https://bugs.archlinux.org/task/20960 > > (I just noticed that I got one of the bug numbers in the list of dupes > > wrong, > > whoops) > > Closing that bug by quoting RedHat bug report. > > Priceless. > Arch's general policy is not to enable/support experimental code (except for exceptional cases like mplayer/ffmpeg). That's why on the one hand some software is versions ahead of most other distros, but software which spends a lot of time in Beta/RC (firefox4, gnome) actually tends to lag behind some other distros. I use awesome on Arch, from the AUR. We're pretty DIY in any case (not compared to the gentoo crowd though) so its not really a big deal. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Twinview, separate X-screens, moving apps, and locking mouse
On Sat, 2011-03-12 at 09:03 +0100, Uli Schlachter wrote: > > 3. Does awesome support 'locking' the mouse on a single screen in a > > twinview configuration (which to all extents and purposes is identical > > to the normal xrandr multi-screen configuration)? > In X11 you can tell the X server "alyways keep the mouse pointer inside of > some > window". With "seperate X-screens", each screen gets its own root window, so > keeping the mouse pointer in that should do what you want. > However, with Xinerama there is only one big root window which covers both > screens, so this doesn't work here. > So, I think polling is the only way to do this. I'm interested in the 'always keep the mouse pointer inside of some window' bit. Could I be pointed to some documentation on that? I've tried hacking away at some code based on the C++ interface to X11 before but haven't seen that. In TwinView as well I think there's only one big root window (I think). Creating a transparent window of the same size as the monitor would work though I think. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Twinview, separate X-screens, moving apps, and locking mouse
Hi all, I'm using nvidia, where you can use Twinview, separate X-screens, or Xinerama for dual-screen. Twinview and Xinerama accomplish pretty much the same thing, apps can move between monitors, as can the mouse. Separate X-screens does it differently, apps can't move between monitors, the mouse can (unless the location of the X screens has a gap). The main reason I used to use separate X-screens was because a small app named mouse-wrapscreen allowed moving the mouse from screen to screen, turning the app off would 'trap' the mouse in one of the screens. Handy for playing full-screen games on one screen while leaving the other to display something else (a chat window or something like that), as you can imagine. After a while, however, the lack of moving apps between screens (and the resulting difficulties in opening URLs etc.) meant I moved to Twinview. All this was before I started using Awesome, so I've only known Awesome with twinview. So, after that long intro, here's my questions:- 1. Is it possible to use separate-X with awesome (will I have to start two instances of awesome)? Will keyboard shortcuts collide? 2. Does awesome make it possible to move apps between monitors with separate-X? (highly unlikely, worth asking though). 3. Does awesome support 'locking' the mouse on a single screen in a twinview configuration (which to all extents and purposes is identical to the normal xrandr multi-screen configuration)? A 'yes' to question 3 would be the ideal solution I think. I know of mousejail, but it runs by polling, and the mouse pointer actually escapes the window most of the time (it's just pulled back to the limit the next time the app polls). Thanks for reading this long mail. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: titlebar on gimp toolbox
On Sun, 2011-03-06 at 11:14 +0100, Massimiliano Brocchini wrote: > Thanks a lot! > You can also try running single-window mode, it really works quite well (though it doesn't save over executions yet) -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: libreoffice on dual-screen causes other screen to switch on scroll/menu
On Fri, 2011-02-25 at 08:22 +0100, Torsten Andre wrote: > Am 25.02.2011 01:46, schrieb Ng Oon-Ee: > > Hi all, > > > > Using libreoffice 3.3.0.4 on Arch Linux 64-bit, awesome 3.4.9 > > > > If you have a dual-screen, open libreoffice on the 2nd screen, on a > > different tag from whatever is on your first screen (try tag 1 on screen > > 1, tag 2 on screen 2) > > > > Scroll or click on the menu bar in openoffice. The first screen will > > jump to tag 2 (or whatever tag libreoffice is on on the 2nd screen) > > > > This does not happen when libreoffice is on the 1st screen. > > > > Is this (presumedly) a libreoffice bug? What sort of behaviour in an app > > could cause awesome to behave in this way? > > > > > > I may confirm that I have exactly the same problem with OpenOffice > (including floating and non-floating behavior): > > OpenOffice.org 3.2.1 > OOO320m19 (Build:9505) > ooo-build 3.2.1.4, Ubuntu package 1:3.2.1-7ubuntu1.1 > > Torsten > http://openoffice.org/bugzilla/show_bug.cgi?id=96684 This bug is claimed to be fixed in latest developmental version (nov 2010) I have filed a similar bug linking to above in the freedesktop tracker. https://bugs.freedesktop.org/show_bug.cgi?id=34701 -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: libreoffice on dual-screen causes other screen to switch on scroll/menu
On Thu, 2011-02-24 at 22:17 -0300, Tomás Solar Castro wrote:
> Did you try with a floating window?
With a floating window scrolling does not trigger the switch, but
clicking on the menus still does.
It seems the soffice binary creates a WM_CLIENT_LEADER window, I presume
this window must technically be on the first desktop. Here's the xprop
for the client leader window (ID extracted from xprop of libreoffice
window)
WM_CLASS(STRING) = "soffice", "Soffice"
WM_COMMAND(STRING) = { "soffice" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x5a2
WM_CLIENT_LEADER(WINDOW): window id # 0x5a1
_NET_WM_PID(CARDINAL) = 12105
WM_LOCALE_NAME(STRING) = "en_US.utf8"
WM_CLIENT_MACHINE(STRING) = "ngoonee-laptop"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 10 by 10
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS,
_NET_WM_PING
WM_ICON_NAME(STRING) = "LibreOffice 3.3"
_NET_WM_ICON_NAME(UTF8_STRING) = "LibreOffice 3.3"
WM_NAME(STRING) = "LibreOffice 3.3"
_NET_WM_NAME(UTF8_STRING) = "LibreOffice 3.3"
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: libreoffice on dual-screen causes other screen to switch on scroll/menu
On Thu, 2011-02-24 at 22:00 -0300, Tomás Solar Castro wrote: > > Ng Oon-Ee escribió: > > >Hi all, > > > >Using libreoffice 3.3.0.4 on Arch Linux 64-bit, awesome 3.4.9 > > > >If you have a dual-screen, open libreoffice on the 2nd screen, on a > >different tag from whatever is on your first screen (try tag 1 on > >screen > >1, tag 2 on screen 2) > > > >Scroll or click on the menu bar in openoffice. The first screen will > >jump to tag 2 (or whatever tag libreoffice is on on the 2nd screen) > > > >This does not happen when libreoffice is on the 1st screen. > > > >Is this (presumedly) a libreoffice bug? What sort of behaviour in an > >app > >could cause awesome to behave in this way? > > Did you try it with a maximized window? > The same occurs whether the window is maximized or not (the tag I typically put my documents on is set to maximized layout in any case, and I tested in another tag which has a tiled layout) -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
libreoffice on dual-screen causes other screen to switch on scroll/menu
Hi all, Using libreoffice 3.3.0.4 on Arch Linux 64-bit, awesome 3.4.9 If you have a dual-screen, open libreoffice on the 2nd screen, on a different tag from whatever is on your first screen (try tag 1 on screen 1, tag 2 on screen 2) Scroll or click on the menu bar in openoffice. The first screen will jump to tag 2 (or whatever tag libreoffice is on on the 2nd screen) This does not happen when libreoffice is on the 1st screen. Is this (presumedly) a libreoffice bug? What sort of behaviour in an app could cause awesome to behave in this way? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Problems with not closing java windows
On Wed, 2011-02-09 at 11:40 +0100, Torsten Andre wrote: > Hey group, > > I really really really love awesome, but the issues with Java are kind > of annoying :( The FAQ has stuff about java, did you follow the instructions there? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: GNOME shell + awesome
On Tue, 2011-02-08 at 21:42 +, Skjddsjkkj Kjdsjksdkjsd wrote: > Thanks for your answers. > > Yes, I have gnome-settings-daemon running. > > Strange > thing is that transparency, volume OSD and nm-applet icon are all gone > when using awesome as my shell. They re-appear once I replace the > default gnome shell. > > - No transparency. > - Normal volume OSD replaced by > http://img810.imageshack.us/img810/4342/screenshotcq.png > - nm-applet running but not appearing in the system tray. > - nm-applet notifications not showing normal theming. > - No ALT+F2 run command. > > Maybe I'm missing a component I need to run? Please bottom-post. And I think you just have awesome running (it doesn't support transparency without some other compositing manager like xcompmgr). That would also explain the lack of ALT-F2. Most of us use awesome (perhaps with gnome-settings-daemon or gpm), not awesome on top of gnome-shell. Awesome will replace all the WM parts, and possibly some of the other functionalities as well. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: can't assign matlab figure to certain tag.
On Mon, 2011-01-31 at 19:21 +0100, Uli Schlachter wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Am 31.01.2011 18:43, Piter_ wrote:
> [...]
> > { rule = { class = "sun-awt-X11-XFramePeer"},
> [...]
> Either
> { rule = { class = "sun%-awt%-X11%-XFramePeer"},
> or
> { rule = { class = "sun--awt--X11--XFramePeer"},
>
> Cheers,
> Uli
Neither of those work for me. Piter, did you get it working?
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Some Wine apps auto-float, unable to toggle floating off
On Fri, 2011-02-04 at 21:22 +0100, Uli Schlachter wrote: > > I'll presume you meant me to check the xsession errors (I'm running > > through gdm). Nothing related to awesome there when I start up the wine > > app, just a common wine-related error (missing winemenubuilder.exe) > > which is not related. > [...] > > Hm, I was wrong, awesome ignores this "transient for" property. So dunno :( > Well, from my POV it does seem that the 1-pixel size 'parent' window is what is causing the issue. Any ideas from anybody what else I can do to debug? My 'workaround' at the moment is to just send the app to another tag, but that's only acceptable at the moment because I use multiple monitors and still can do side-by-side without proper tiling on one screen -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Some Wine apps auto-float, unable to toggle floating off
Hi Uli, thanks for following up on this. On Wed, 2011-02-02 at 15:22 +0100, Uli Schlachter wrote: > > > > So it seems there's an unmapped parent window with a 1x1 pixel size. How > > would this affect tiling? > > This is IMHO an ICCCM violation which states[1]: > > "Clients should not rely on transient windows being available to the user when > the transient owner window is not in the Normal state." > > The transient owner window is unmapped which means that awesome isn't managing > it which in turn means that it is in the "withdrawn" state. From my reading of > ICCCM this means that awesome is free to hide that e-Sword window. > > Now for what actually happens: I haven't verified yet, but it looks like this > case triggers a bug and awesome aborts half-way through making that window > visible. Could you check if you get any error messages on awesome standard > error > output? E.g. on Linux: > > ls -l /proc/$(pidof awesome)/fd/2 > > If that points to some file, error messages end up in that file. If this > points > to e.g. "tty1" then error messages are sent to the tty where awesome was > started. > > Cheers, > Uli > > [1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4 I'll presume you meant me to check the xsession errors (I'm running through gdm). Nothing related to awesome there when I start up the wine app, just a common wine-related error (missing winemenubuilder.exe) which is not related. I read through the link you provided, but nothing there seems to me to indicate that awesome should be treating the child window according to the state of the parent window. I can bring this issue back to the wine forum, but first I'd like your confirmation on what exactly is 'wrong' with the current behaviour. If someone with the knowledge volunteers to test the app out I can compress the .wine folder so that it can be run on any machine with wine installed, no setup required. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Some Wine apps auto-float, unable to toggle floating off
On Tue, 2011-02-01 at 21:07 +0100, Uli Schlachter wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am 01.02.2011 08:39, Ng Oon-Ee wrote: > > After some more testing (with other apps as well), it seems the > > 'offending' hint is this one (from xprop):- > > > > WM_TRANSIENT_FOR(WINDOW): window id # 0x5a1 > > > > How does awesome handle this particular hint/ > > I can't find anything in the C core actually using this, except for the > stacking > order (client's are above the window for which they are transient). > It's available to lua via c.transient_for. The only thing that uses this is > awful.tag. When a new client with a transient_for hint appears, it gets the > same > screen and tags as its transient for client. > > So, that shouldn't have anything to do with this. > > Cheers, > Uli Hmm, just retested, while yesterday I could not find the parent window today I can. Here's xwininfo -id 0x561 (which is the ID currently under WM_TRANSIENT_FOR for the app. xwininfo: Window id: 0x561 "e-Sword" Absolute upper-left X: 640 Absolute upper-left Y: 400 Relative upper-left X: 640 Relative upper-left Y: 400 Width: 1 Height: 1 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 1 Class: InputOutput Colormap: 0x481 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsUnMapped Override Redirect State: no Corners: +640+400 -1917+400 -1917-621 +640-621 -geometry 1x1+640+400 So it seems there's an unmapped parent window with a 1x1 pixel size. How would this affect tiling? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Some Wine apps auto-float, unable to toggle floating off
On Tue, 2011-02-01 at 21:07 +0100, Uli Schlachter wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am 01.02.2011 08:39, Ng Oon-Ee wrote: > > After some more testing (with other apps as well), it seems the > > 'offending' hint is this one (from xprop):- > > > > WM_TRANSIENT_FOR(WINDOW): window id # 0x5a1 > > > > How does awesome handle this particular hint/ > > I can't find anything in the C core actually using this, except for the > stacking > order (client's are above the window for which they are transient). > It's available to lua via c.transient_for. The only thing that uses this is > awful.tag. When a new client with a transient_for hint appears, it gets the > same > screen and tags as its transient for client. > > So, that shouldn't have anything to do with this. > > Cheers, > Uli Thanks Uli. I've tested four different Wine apps, the two that worked (tiled) both did not have this, the two that didn't had the hint. Additionally, the window id pointed to for both of them does not exist. Probably pointing towards the splash screen or something of that nature. Any ideas what else I should try? The other hints are just about identical... -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Some Wine apps auto-float, unable to toggle floating off
On Tue, 2011-02-01 at 00:01 +0800, Ng Oon-Ee wrote: > On Mon, 2011-01-31 at 16:43 +0100, Uli Schlachter wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am 31.01.2011 04:36, Ng Oon-Ee wrote: > > > E-sword is a free app which exhibits this behaviour. On startup it is > > > floating, and I can't seem to get it to unfloat no matter what I do. > > > Some other wine apps work however (utorrent is one that does on my > > > system). > > > > > > I've took the xprop output for both in the hope that it is useful. > > > > > > http://pastebin.com/cYCEm5DK is for utorrent which works > > > http://pastebin.com/KAqE8PeP is for e-sword which doesn't (can only > > > float) > > > > Hi, > > > > could this be FS#345? Could you grab xwininfo output for one of those > > windows, too? > > > > Alternatively, could you try unminimizing e-sword? As your xprop output > > says, it > > is maximized: > > > > _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, > > _NET_WM_STATE_MAXIMIZED_HORZ > > > > Cheers, > > Uli > > > > https://awesome.naquadah.org/bugs/index.php?do=details&task_id=345 > > Hi Uli, thanks for your response. > > Here's xprop for non-maximized - http://pastebin.com/wDG2wWqD > > The window still cannot be un-floated. > > And the xwininfo doesn't show Override as yes, pasted below. > After some more testing (with other apps as well), it seems the 'offending' hint is this one (from xprop):- WM_TRANSIENT_FOR(WINDOW): window id # 0x5a1 How does awesome handle this particular hint/ -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Twinview, Awesome, and dynamic switching
On Mon, 2011-01-31 at 16:48 +0100, Uli Schlachter wrote: > > One question: Do you have a floating layout in awesome after the restart? If > no, > then obviously the selected layout should move the window to its correct > place. > If no, then the following snippet in the default rc.lua should make the window > visible: Yes, that was it. I was using the default config, have now set a tiling layout as default and that does not happen. What occurs is that awesome restarts when the resolution changes, hence going back to the default layout rather than the one which was previously active. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Some Wine apps auto-float, unable to toggle floating off
On Mon, 2011-01-31 at 16:43 +0100, Uli Schlachter wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am 31.01.2011 04:36, Ng Oon-Ee wrote: > > E-sword is a free app which exhibits this behaviour. On startup it is > > floating, and I can't seem to get it to unfloat no matter what I do. > > Some other wine apps work however (utorrent is one that does on my > > system). > > > > I've took the xprop output for both in the hope that it is useful. > > > > http://pastebin.com/cYCEm5DK is for utorrent which works > > http://pastebin.com/KAqE8PeP is for e-sword which doesn't (can only > > float) > > Hi, > > could this be FS#345? Could you grab xwininfo output for one of those > windows, too? > > Alternatively, could you try unminimizing e-sword? As your xprop output says, > it > is maximized: > > _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, > _NET_WM_STATE_MAXIMIZED_HORZ > > Cheers, > Uli > > https://awesome.naquadah.org/bugs/index.php?do=details&task_id=345 Hi Uli, thanks for your response. Here's xprop for non-maximized - http://pastebin.com/wDG2wWqD The window still cannot be un-floated. And the xwininfo doesn't show Override as yes, pasted below. xwininfo: Window id: 0x3aa "e-Sword - the Sword of the LORD with an electronic edge" Absolute upper-left X: 11 Absolute upper-left Y: 30 Relative upper-left X: 11 Relative upper-left Y: 30 Width: 1272 Height: 773 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 1 Class: InputOutput Colormap: 0x341 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +11+30 -1275+30 -1275-219 +11-219 -geometry 1272x773+11+30 -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Some Wine apps auto-float, unable to toggle floating off
E-sword is a free app which exhibits this behaviour. On startup it is floating, and I can't seem to get it to unfloat no matter what I do. Some other wine apps work however (utorrent is one that does on my system). I've took the xprop output for both in the hope that it is useful. http://pastebin.com/cYCEm5DK is for utorrent which works http://pastebin.com/KAqE8PeP is for e-sword which doesn't (can only float) -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Twinview, Awesome, and dynamic switching
Hi all, I use a laptop which sometimes has an external monitor connected. I have a shortcut key bound to the auto-disper utility, which itself calls the disper utility based on some presets. disper is sort of a simplified commandline interface to nvidia-settings, sort of like using xrandr (different syntax/capabilities). So anyway, if I currently have the external monitor connected and window A on the laptop screen, window B on the monitor, then when I disconnect the external monitor and run auto-disper, I'm left with one laptop screen showing window A. Window B shows on the switcher, but I need to switch tiling layouts at least once to get it to show on the laptop screen (it seems to still have the old coordinates, so exists beyond the laptop screen). Is this sort of behaviour expected? What's the best way to work around it? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
