Openbox & dropshading with xcompmgr

Howdy,
I am working on configuring the urxvt terminal so that it is transparent and appears to be "writing to the wallpaper." I have been following the instructions at the end of the arch openbox wiki (http://wiki.archlinux.org/index.php/Openbox).
I have followed the instructions and then made some minor tweaks of my own and everything seems to be working perfectly except...
There is a nice shadow around the perimeter of the window.  While this is a very nice feature and is the exact reason I have xcompmgr configured and running it does take away from the "effect" that the terminal is "writing to the wallpaper."
What I am wondering is if anyone knows how to get xcompmgr to stop the dropshading for a specific window or set of windows or if any one knows a cleaver way of getting openbox to work around this.
Thanks much for your help.
jash

SOLVED
A bit late now, but if anyone turns this up searching, I have now used hsetroot in my autostart.sh to set the background colour to black:
hsetroot
(Hmmm, complex eh?)
and my desktop is black. Just like I always wanted.
Last edited by m3tr0g33k (2009-02-15 18:55:52)

Similar Messages

  • Urxvt won't get transparent with openbox, rgba and xcompmgr

    Hello!
    Yesterday I had a nice working openbox setup with real transparency in urxvt using
    Urxvt*background: rgba:0000/0000/0000/bbbb
    in ~/.Xdefaults.
    Then I did some fiddling around with vga boot options to get a nicer console, and realized the terminals in openbox was not transparent anymore. I thought of it as a framebuffer issue with the nvidia driver, and set everything back to normal again. That did nothing however, the urxvt was still not transparent.
    Reinstalled arch this morning for the sake of it, but I still can't get urxvt transparent with xcompmgr. Compositing seems to work with drop shadows and transset, but not when using rgba for urxvt.
    Any ideas what I've done wrong?
    My Xorg.0.log shows no errors.

    Ah, thank you!
    I forgot to change it back after I did some troubleshooting...it's all working now!

  • Video tearing with xcompmgr and mplayer

    Hello, recently I've noticed a lot of tearing when playing movies with xcompmgr loaded. When i kill xcompmgr it goes away (almost) completely and when I enable it again the tearing starts to reappear. I'm running kernel 2.6.29, xorg 1.6 and the latest nvidia beta.
    I run into this tearing no matter what video output i select, xv, vdpau or gl, it doesn't matter, video still tears.
    Since I really like the effects of xcompmgr + openbox (fast but still reasonably looking) and don't really want to do without xcompmgr, I was wondering if anyone here have experienced the issue and came up with some kind of solution to this issue.
    Thanks, GBG-Johan.
    I forgot to mention that the video tearing still occurs when i use xine-ui instead of mplayer, so I guess it's not an issue related to which player i use.
    Last edited by göteborg-johan (2009-04-18 21:46:59)

    System info :
    Dell Studio 14z
    NVidia 9400 M
    built-in monitor and Sharp 1080p TV connected via HDMI
    KDE 4.4
    X.Org version: 1.7.5
    NVidia Driver Version: 190.53
    uname -a :
    Linux shinny 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 9 15:12:10 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz GenuineIntel GNU/Linux
    I am experiencing video tearing when using  VDPAU output with mplayer.  If I use XV output instead, there is no tearing.  If I use Dragon Player (which doesn't support VDPAU) there is also no tearing.  Playing around with the VSync option in nvidia-settings only has an effect if I'm using XV.
    On my other box running Funtoo, I had experienced the same issue.  After some searching on the Web, I found that someone suggested to add :
    Section "Extensions"
    Option "Composite" "Disable"
    EndSection
    to /etc/X11/xorg.conf.  On my Funtoo system this fixed the issue.  However, doing the same on my Archlinux Studio 14z didn't fix the problem.
    I also tried recompiling mplayer (as if that would change anything...) to no avail.
    The issue also occurs even if I use the laptop screen without any external monitor connected.
    Does anyone have a clue of what else I should try?  The suggestion to use only XV is not suitable because I have some 1080p content that I can not decode fast enough using only the CPU.
    Another test I might try is to run my Funtoo on my laptop.  This will tedious and it might not be exactly the same, since the kernel on my Funtoo machine is custom built with only the drivers for the hardware in that box.
    Last edited by Prozzaks (2010-02-19 03:28:19)

  • Problem with xcompmgr and i3 window manager

    Hey guys,
    Had a hard time trying to search for this problem. and nothing came up for the exact problem I was having. Anyways this is my problem. with xcompmgr is that it doesn't seem to be refreshing or something. it leaves trails of previous windows for some reason. not sure why. Anyone have this problem or someone know how to fix it??!?
    Here is a link to show you what i mean.
    http://oi45.tinypic.com/2nlaghy.jpg
    Thanks in advance for your kind and prompt attention.
    Sincerely,
    Sicariuxs

    Wow psychadelic!
    I found xcompmgr to be rather buggy when I used to use it. Try xcompmgr-dana (dcompmgr I think)  or Compton. I used to use Compton and it worked pretty well.
    I stopped using real transparency in favor of pseudo-transparency because I sometimes use the tabbed mode on multiple terminals... tell me how awesome it is to read three terminals stacked on each other

  • How to integrate OpenBox menu with Tint?

    Having tint shorter than screen width is not an option, because it looks terrible.
    Any ideas?

    Could you explain a bit more what it is exactly you're trying to accomplish.  How are you trying to integrate the openbox menu with tint?
    For example: right-clicking free space on tint panel brings up OB menu.
    Current workaround works (tint not stretched to screen width - I'm clicking empty space on sides of tint panel) but I was hoping for more "elegant" solution.
    According to tint manual:
    "3.7 Mouse
    customize mouse action with : none, close, toggle, iconify, shade, toggle_iconify
    mouse_middle = none
    mouse_right = close
    mouse_scroll_up = toggle
    mouse_scroll_down = iconify"
    Why not just use the hotkey to bring up the openbox menu?
    Not being able to do everyday tasks efficiently with a mouse is a big no-no.
    Besides that, combo of OB + Tint + Trayer is great.
    Last edited by mute (2008-10-10 22:42:56)

  • No drop shadow for Opera under Pekwm with xcompmgr-dana.

    Hi,
    I'm running Pekwm with xcompmgr-dana and tint2. It works great except for one thing: There's no drop shadow on Opera windows. All other windows (except a couple of terminal emulators) have drop shadows. Any idea why there's no drop shadow for Opera, and if there's anything I can do to fix it?
    I am running fully updated Arch x64 on a laptop with Intel graphics.

    No the culprit is not urxvt, I think. I tried today 'terminal' from xfce4 and it too don't have shadows...
    Someone can reproduce this with any other terminal?
    Uhh, one more question of the people having or not the problem what is set the color depth of  X, I think that fglrx only support >16 but I can't make it work with 32 (using 24) someone can run at 32 and see with you get or not shadows?
    EDIT
    Ok, I think I found the culprit: ARGB visual (or RGBA visuals...) if a program use it shadows don't work. Try emesene it have a config to use or not rgba visuals,  If you set it (in .config/emesene*/*****) you don't get shadows if don't set you get shadows.
    I think this explain the dual transparency/shadow... When I gonna investigate it more but now I have a homework of QFT to do...
    Last edited by kazuo (2008-03-22 20:48:30)

  • SMplayer becomes invisible with xcompmgr-git and xmonad

    I encountered a very weird problem.
    My X desktop is based on xcompmgr-git (20080703-1) and xmonad (0.7-1)
    If I launch SMPlayer (0.6.1-1) ) from dmenu, the window becomes completely invisible, or I should say it becomes 100% transparent. SMPlayer becomes visible and runs great after I killed xcompmgr.
    The weird part is that this problem is gone if I launch SMPlayer from a console (urxvt).
    Can some one explain to what went wrong with the transparency setting of SMPlayer.
    Many thanks

    yackeroeni wrote:
    Hi,
    I've been trying to get games to work on my new setup and have problems running games in fullscreen mode.
    I can hear the sound of the game, but am unable to see it or, as far as I know, interact with it
    Literally using Xmonad for the first time and I experienced some game issues with fullscreen. Specifically when running CS:GO I had a problem where the resolution was native to my monitor (1920x1080) it was running windowed and I couldn't find a way to resize it unless moving it to a blank workspace (so other windows don't infere with the mouse hook) and your then able to drag the window by xmonad commands:
    mod-button1
    Set the window to floating mode and move by dragging
    mod-button2
    Raise the window to the top of the stack
    mod-button3
    Set the window to floating mode and resize by dragging
    yackeroeni wrote:(running steam games) launching dota 2 with the '-windowed' flag works fine.
    Correct me if i'm wrong, but I believe the linux native games on steam use the concept of '-windowed' by default.

  • Good file-manager for OpenBox? (with icons)

    I tried rox with the magickthumbnails and videothumbmails, but havent got it working yet.
    I am now trying thunar, but it has dull generic icons.  Everything looks like a piece of paper.  I'm sure it'd look good if I was running XFCE.
    Is there a standard/common file-manager for use with openbox?  Preferably one with icons for different file-types.

    DonVla wrote:
    hi,
    i also recommend rox. fast and the drag'n'drop functionality is brilliant.
    the default layout is truely ugly. but you can change everything.
    i've changed the rox icons by hand:
    in my ~/.gtkrc-2.0.mine:
    # rox-filer toolbar icons
    pixmap_path "~/.icons/panel_icons/icons_2"
    style "normal" {
    stock["gtk-close"] = {{"close.png"}}
    # stock["gtk-close"] = {{"exit.png"}}
    stock["gtk-go-up"] = {{"1uparrow.png"}}
    stock["gtk-home"] = {{"gohome.png"}}
    stock["gtk-refresh"] = {{"redo.png"}}
    stock["gtk-zoom-in"] = {{"add.png"}}
    stock["gtk-zoom-fit"] = {{"stop.png"}}
    stock["gtk-jump-to"] = {{"bookmarks.png"}}
    # stock["gtk-sort-ascending"] = {{"bottom.png"}}
    # stock["gtk-help"] = {{"help-icon.png"}}
    stock["rox-show-hidden"] = {{"filter.png"}}
    stock["rox-show-details"] = {{"view_tree.png"}}
    # stock["rox-select"] = {{"select-icon.png"}}
    widget "*" style "normal"
    it's quite self explanatory .
    vlad
    ps:
    and that's what it looks like:
    http://img206.imageshack.us/img206/2949 … 24aak4.png
    That's a pretty cool setup u got there. Is that conky in the top centre? If so, mind sharing your .conkyrc.
    What Icon theme are u using? is that panel-thingy AWN?
    Could u also elaborate this line < pixmap_path "~/.icons/panel_icons/icons_2" > ?

  • [SOLVED] openbox margins with dual monitors

    Hi community,
    I have stumbled to a nasty problem on my first incursion to dual monitors in openbox.
    I'm using xrandr with this command (which works just fine BTW):
    xrandr --output LVDS --mode 1280x800 --primary --output VGA-0 --mode 1280x1024_60.00 --gamma 1.0:1.4:0.85 --right-of LVDS
    and have set a Virtual screen in xorg.conf of 2560 x 1024 pixels.
    But, my laptop monitor only handles 1280x800, while my external LCD monitor has 1280x1024, so there is a virtual area under my laptop screen which i'm not using, but i dont really care about that.
    The problem is that when I'm setting screen margins, so that maximized windows will respect the panels in the bottom (tint2), in rc.xml (or by obconf) the margins are applied to the virtual screen and only are practical on the external monitor wich has more pixel height.
    I'm really missing some kind of per monitor margin settings in openbox, maybe there is and i haven't found it? It makes me wonder because openbox can maximize windows to a single monitor, even if the whole layout it's treated like a virtual screen, so it has some way of distinguishing between them.
    I would appreciate any suggestions, thanks.
    Last edited by andreamer (2010-07-26 18:32:15)

    TL;DR - I'm not aware of any acceptable solution at the moment.
    Basically, what you're having problems with, is the "dead area." It can really be quite a pain in the butt if window managers or other screen aware applications don't anticipate it properly. To my knowledge, Openbox doesn't support margins on a monitor-by-monitor basis. In reality, you shouldn't need to be setting margins anyway. Tint2 should be reporting itself as a taskbar, and Openbox should be respecting that.
    I have dead area too, with multiple monitors, and Openbox respects both of the KDE taskbars I have running (one on each monitor). (I use KDE and simply replaced Kwin with Openbox.) This tells me that tint2 should be able to cooperate with Openbox. I remember trying tint2 a while ago, and didn't fine it adequate in a dual monitor environment (it was probably a year ago or so). tint2 would need to be setting the _NET_WM_STRUT_PARTIAL hint, and I'm not sure if it is (or if it's doing it properly). See http://standards.freedesktop.org/wm-spe … #id2507618
    Also, I do know that the developer for Openbox recently got a dual monitor setup, and she's been adding additional support for dual monitors a little at a time. Hopefully with 3.5, there will be a lot more support. (Margin support for multiple monitors would be great, because it could be a good utility knife for applications that don't care about multi-monitors setups and don't set the proper hints.)
    If you're capable of modifying tint2, my course of action would be to try something that works (like the KDE taskbars) and record the hints being set there. Then compare them with tint2 and try to mirror KDE's setup. (If you're a programming lacking experience with X and related nonsense, I'd be more than willing to offer what guidance I have.)
    Also, I developed a panel myself (and got pretty far along) using the PyGTK toolkit... But I can't remember if I solved this problem or not. I'll try to check it out and get back to you. (I got as far as implementing a widget system that includes a task list, system tray, clock, menus... It just isn't polished very well. My original intention was for it to be a more robust PyPanel with dual monitor support.)
    Last edited by BurntSushi (2010-07-24 22:46:23)

  • Openbox alternative with tiling builtin?

    Hello, I am using LXDE right now until I can switch over to a qt-desktop (once it's stable), and I'd like to find another floating window manager that can do tiling. Particularly, I want to be able to set a keybinding to have windows move to take up the left/right half of the screen and possibly quarters of the screen. I'm aware that there are many tiling wms out there, but I was hoping for a floating wm that works like openbox, but has that tiling ability built into it. My first attempt was pekwm, but unless I missed something, it couldn't do tiling like I wanted. I do like the look of it much more than openbox though. I've also heard that openbox has a plugin thing to get tiling, but I'd rather experiment with an alternative wm.

    If you don't need continuous tiling, I heartily recommend FVWM because it gives you a lot of freedom in your configuration. I have this functionality bound to drag gestures initiated by the right mouse button on the titlebar.
    Drag left to fill the left half of the screen.
    Drag up and left to fill the top left quarter of the screen.
    Drag left, then up to fill the first 1/8 of the screen (1/4 width, 1/2 height)
    Drag up, then left to fill the second 1/8 of the screen.
    Drag left, then right, to fill the left 3/4 of the screen
    and so on.
    You can bind whatever to whatever, including keychains and buttons that do dozens of different things depending on mouse button and modifiers keys used; you can also put buttons wherever you want and aren't restricted to traditional panels or window borders. FVWM is a lot more powerful than Openbox, can mimic it so well you won't notice the difference if that's all you want, and still plays in the same weight class.
    The configuration syntax isn't quite as straightforward though, and outside tool to add functionality to window managers didn't always behave as nicely for me.

  • Openbox / Lxde with twinview

    As a long time Xfce user i decided to give Openbox (standalone and w/ Lxde) a try. First impression is pretty good, although it seems to have trouble detecting my twinview layout, addressing it as a single big desktop instead (i know it's supposed to be a big desktop, but panels and stuff should adhere to monitor boundaries ofcourse). I don't know if this is an xrandr thing which Xfce somehow circumvents, but are there any fixes for this on Openbox/Lxde?
    I don't want to use separate X screens.

    the issue is the library that lxpanel uses to address window locations, it doesn't see the separate "screen areas" that twinview presents to X
    i don't know what lxpanel uses, but i do know that libnetk (what xfce-panel 2.2 and below use) doesn't detect twinview regions properly. the xfce team are switching to libwnck for xfce 2.4. wnck is the library that gnome-panel uses, and detects twinview regions properly, so at least we'll have two working twinview panels soon
    of course, this all has to do with the obfuscated output the nvidia binary driver passes, and could be improved upon if nvidia would open their drivers, but that's another story (me? bitter? never )

  • Strange backdrop on transparent windows with xcompmgr and i3

    Hi there! I have disabled title bars in my i3 config, and I use xcompmgr for a little transparency. However, in the space where the title bar would be, garbage is visible behind the transparent backround of some windows.
    Any ideas? I tried a few other compositing managers and the problem was reproducable on several.

    Wow psychadelic!
    I found xcompmgr to be rather buggy when I used to use it. Try xcompmgr-dana (dcompmgr I think)  or Compton. I used to use Compton and it worked pretty well.
    I stopped using real transparency in favor of pseudo-transparency because I sometimes use the tabbed mode on multiple terminals... tell me how awesome it is to read three terminals stacked on each other

  • Gnome killed after power outage

    While using Gnome, the power to my apartment blinked out. I don't have a UPS, so this caused my computer to shut down.
    Upon restarting, all of Gnome's default icons were replaced with the little paper, all of my Applications menu was gone, and only a few options remained on my other menus. I tried running as a different user, and this gave no luck, so it's not configuration. I've tried removing and reinstalling Gnome via Pacman with pacman -R gnome and pacman -S gnome, I've tried replacing the icons by hand. None of this has been successful. I've run fsck.
    I've had this happen before on crash; none of these solutions worked and at that point I hadn't tried Ubuntu, so I blew my Arch away to give that a go. I'm hoping I don't have to resort to that again.
    All help is appreciated.
    Last edited by cookiecaper (2007-09-22 12:31:19)

    cookie, by chance were you running Compiz Fusion before this happened?
    I just removed all my Compiz Fusion stuff (since I'm back to Openbox/GNOME with Xcompmgr) and my desktop is doing the exact thing as yours--lots of broken icons and my GNOME menu is all but missing. 
    So far, I have:
    * removed nesl247's repos from pacman.conf
    * uninstalled compiz-fusion-git
    * removed libx11 (1.1.3-4) found in [testing] (which is the version you are running now)
    * installed the stable libx11 (1.1.3-1) found in [extra]
    One of the above packages must have left behind some settings that are no longer compatible.
    --- edit ---
    The Compiz Fusion wiki called for this command to fix the fusion-icon after installation:
    gtk-update-icon-cache -f /usr/share/icons/hicolor
    Could this have anything to do with these problems?
    Last edited by thayer.w (2007-09-23 21:15:45)

  • Xcompmgr messing with openbox windows (conky and kde apps only)

    here's the involved packages:
    openbox 3.4.7.2-1
    nvidia 177.82-1
    xorg-server 1.5.3-3
    xcompmgr 1.1.4-1
    kdelibs3 3.5.10-2
    conky 1.6.1-2
    now the issue is primarily with xcompmgr.  when it's running (default options or the whole -cCfF... stuff doesn't make a difference).  i have the following:
    whenever a kde apps window opens.  (i.e. i start amarok or k3b; k3b opens new windows during burn start/stop process) my conky will disappear only to flicker and reappear a few seconds later. (this only happens with kde apps)
    when i'm tweaking my conky i will often `pkill conky; sleep 3; conky` to see my changes.  when i kill conky, ALL of my active windows on the current desktop disappear and only reappear if a) they are redrawn because of an update to their contents on their own accord, or b) (kinda the same thing) i grab a window and drag it all over the screen resetting whatever i pass over to it's correct visual state.  (this only happens when killing conky)
    this is annoying me, i love the shadows/fading from xcompmgr but this flickering makes my whole experience feel unstable and i have to turn it off after a few minutes.  turn off xcompmgr and it's rock solid just as before... snappier too i think.
    this behavior started immediately after the recent xorg update (i saved that for last because i know were all sick of _that_).  i changed nothing, but for the -Syu when this happened.
    anyways, your thoughts and help is much appreciated.

    so i'm resurrecting this thread because i hoped, and  prayed, that xorg 1.6 in testing would fix this problem.  i've been working my ass off to keep my system back in xorg 1.4.  my desktop just looks so oldfashioned w/o shadows and transparency. 
    ok so to re-outline, i'm running:
    pacman -Q stuff
    xorg-server 1.6.0-1
    nvidia 180.29-3
    openbox 3.4.7.2-1
    xcompmgr 1.1.4-1
    with this gpu:
    hwd -s | grep video
    Video : GeForce 7150 / nForce 630i server: XFree86 (vesa)
    i created a minimal xorg.conf via nvidia-xconfig an added a few suggested options (although they _really_ don't seem to affect this bug...):
    cat /etc/X11/xorg.conf
    # nvidia-xconfig: X configuration file generated by nvidia-xconfig
    # nvidia-xconfig: version 1.0 (buildmeister@builder62) Thu Feb 5 00:08:50 PST 2009
    Section "ServerLayout"
    Identifier "Layout0"
    Screen 0 "Screen0" 0 0
    EndSection
    Section "Monitor"
    Identifier "Monitor0"
    VendorName "Unknown"
    ModelName "Unknown"
    HorizSync 28.0 - 33.0
    VertRefresh 43.0 - 72.0
    Option "DPMS"
    EndSection
    Section "Device"
    Identifier "Device0"
    Driver "nvidia"
    VendorName "NVIDIA Corporation"
    Option "NoLogo" "True"
    Option "RenderAccel" "True"
    Option "TripleBuffer" "True"
    Option "BackingStore" "False"
    Option "DamageEvents" "True"
    EndSection
    Section "Screen"
    Identifier "Screen0"
    Device "Device0"
    Monitor "Monitor0"
    DefaultDepth 24
    SubSection "Display"
    Depth 24
    EndSubSection
    EndSection
    now, here's what happens:
    i startx, .xinitrc or autostart.sh bring up xcompmgr, bmpanel, and conky
    if i open amarok or k3b, conky and bmpanel (both using transparency) vanish while the splash screen(s) show.
    when i burn something with k3b (and new windows appear) i see similar behavior
    sometimes it's just for a sec and then it's back, sometimes conky comes back with part of itself missing
    also, if you execute `pkill conky` from an xterm, all windows are 'destroyed' until you [blindly] grab that xterm window and move it about your desktop 'revealing' the desktops contents.  please see this screenshot for this in action.
    killing xcompmgr fixes all this... but it's so ugly.  the problems go away if i downgrade to xorg-server 1.4 (and also adjust any related/dependant packages to match).
    please please, tell me i'm not alone!  a fix would be nice too .
    thanks in advance... again
    Last edited by brisbin33 (2009-03-05 01:30:10)

  • Transparency (true) with transset and xcompmgr

    Could someone please point me to a script or tell me have to achieve true transparency in Openbox with xcompmgr and transset (or transset-df)?
    I have it working to where you can set them each individually, but I want it set automatically when I start X.  I've also tried a couple other things such as the perl script on the transset-df page, but Ihaving gotten something working full proof.  Does anything know of something that will help?

    What do you mean by "set automatically"?
    If you want to have xcompmgr started with X you should add it to your .xinitrc file.
    If you want some per app settings, it will be difficult. There's transd but it didn't work for me. I was playing with xcompmgr only for a short time and I used the following script to make urxvt windows transparent.
    urxvtc &
    sleep 1
    transset-df --id `xprop -root | grep "_NET_ACTIVE_WINDOW(WINDOW): window id # " | grep -o -E -e 0x[a-z0-9]+` 0.65 &> /dev/null
    I use urxvtd deamon and every new window is a client (urxvtc). The script just starts new window, waits a second, then finds an ID of active window (which should be the urxvtc window opened just before) and sends that ID to transset-df. It's just a quick hack but maybe useful for you.

Maybe you are looking for