[openbox] New user - openbox 3.4 - two questions

[Russell Dickenson]

On Fri, Jun 12, 2009 at 11:01 AM, Anthony
Thyssen<A.Thyssen at griffith.edu.au> wrote:
> On Thu, 11 Jun 2009 16:20:06 -0600
> "David Feldman" <wb0gaz at hotmail.com> wrote:
>
> | I'm using Openbox 3.4 with xorg and have a couple of basic questions.
> | My project involves manually controlling the layout of the display
> | screen so that every program runs with -geometry specification.
> |
> | 1. Openbox is re-positioning a window of one application (xv) where I
> | specified in the -geometry parameter (of xv) that the window would be
> | along the top of the X display area (that is, -geometry +400+0, for
> | example, where +0 means "top"). The window ends up maybe 20 pixels
> | down from the top of the screen - it initially starts at the top of
> | the screen, then seems to be immediate relocated vertically down this
> | way. I can start xterm displays successfully this way (aligned to the
> | top of the screen) but with xv I get this unexpected repositioning. I
> | tried editing ~/.config/openbox/rc.xml, to change the section
> | <resize><popupShow> from Nonpixel to Never, but that was basically a
> | guess and it didn't help.
> |
> As a Openbox user (and formally a CTwm user) and a long time XV user I
> can pretty well say that XV is its own worse enemy with regards to image
> placement.
>
> Every time the XV program resizes its displace window, it attempts to
> 'correct' its window placement on screen.   The result is a slight shift
> of the window by a couple of pixels generally downward and either left
> or right each an every time the size of the image being displayed
> changes.
>
> Of course once it hits the left or bottom edges (ignoring any panels or
> other 'fluff') it also automatically adjusts the position to keep the
> image on screen, by resizing to absolute maximum and forcing the window
> manager decorations OFF SCREEN.  It is the XV programs handling of the
> window manager decorations that it stuffs up, and causes the position
> shift.
>
> I myself find this VERY annoying, but I know it is not the fault of
> Openbox.  On the other hand the openbox decoration from the 'theme' does
> effect the amount of this slow window shift.  You can minimize the
> movement by
>
>  1/ Adjust the theme to minimise "border.Width" though removing the
>     border width entirely is not a good idea.
>
>  2/ Remove decorations from the 'XVroot' window in your openbox
>     "rc.xml" file.
>
>        =======8<--------
>        <!-- Remove decorations from XV root window -->
>        <application class="XVroot">
>          <decor>no</decor>
>        </application>
>        =======8<--------
>
>     To move the window afterward use the 'Alt-mouse' window grab to
>     re-position window.
>
> I have been wanting to dig into the XV source code to fix this, but have
> yet to do so.   But somehow fixing the XV code is the best way of fixing
> the problem.  Either by getting it to never re-position, or only it if
> it really has to, to fit the image on screen.
>
> You or someone else is welcome to have a go.  See if you can find a XV
> forum or something to forward the problem on to.
>
> I am not a stranger to XV source code having previously supplied a patch
> to make the code easier to modify to adjust the XV thumbnail size,
> initial tiling array size, and maximum number of browser windows.  This
> was incorperated into the 2007 jumbo patch.
>
> I have also worked out a patch to fix the 'slideshow' time handling
> and add a 'Wait/Resume' key for the slideshow (though it probably should
> change the mouse pointer or something to indicate it is paused).
>
> See my XV mod notes
>   http://www.cit.gu.edu.au/~anthony/info/graphics/xv_mods.hints
>
> | 2. I am interested in finding a task bar or similar utility to use with
> | openbox. I'd like to find something that lets me navigate among open windows
> | by a mouse click, rather than alt-TAB which I'm now using. The catch is I'm
> | looking for something that avoids library dependencies to the extent
> | possible - several such utilities I tried had unresolved (.so) dependencies
> | and in my application, I'm trying to minimize these dependencies because
> | they can lead to "dependency hell" where I am chasing for too long various
> | libraries-needed-by-other-libraries and such. Any suggestion?
> |
> Sorry, I use Gnome with Openbox at this time, for its panels and file
> browser.  though I do plan to explor other posibilities.
>
>  Anthony Thyssen ( System Programmer )    <A.Thyssen at griffith.edu.au>
>  -----------------------------------------------------------------------------
>    It's always the details that get you in trouble.
>                                   -- Rick Cook, "Wizardry Cursed"
>  -----------------------------------------------------------------------------
>     Anthony's Home is his Castle     http://www.cit.gu.edu.au/~anthony/
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>

Regarding point 2 - taskbar - you might look at the following because
they're all quite light (in terms of resources and dependencies) -

tint2 - Under active development
http://code.google.com/p/tint2/

SuxPanel - not sure if it's still under development
http://suxpanel.berlios.de/

Light-monitor - not sure if it's still under development.  It looks to
have the fewest dependencies.
http://www.dixsous.org/Light-monitor/

BMPanel - Under active development.  Possibly the heaviest in
dependencies but it looks good.
http://nsf.110mb.com/bmpanel/

BarPanel - Under active development.
http://www.ossproject.org/projects/barpanel


Regards,

Russell Dickenson
Australia