Fluxbox

On Tue, 16 Feb 2010, Mark Tiefenbruck wrote:
> Java is wonky. I've tried investigating other problems with resizing 
> windows (though I haven't heard of troubles with moving) and drove 
> myself batty. All I can say is that, in the case I investigated, it's 
> something to do with window initialization, as windows that are 
> initialized under fluxbox behave just as poorly when you switch to 
> another window manager (and so this is obviously java's fault to some 
> degree).

Yes, my experience with Java in general is that it doesn't behave nicely 
in all sorts of ways.  I'm also discovering that key clicks don't seem to 
be getting through in quite a number of situations, and I'm wondering if 
fluxbox is part of the problem.

This is becoming a bit of a headache for me, and things are much worse 
behaved under fluxbox than under, say, Gnome.  Your experience doesn't 
make me optimistic about being able to fix this, though...

> As for the keybinding that doesn't work, there's probably another 
> program running on your system that grabs the same keybinding.

Um.  That's a good thought, though I can't imagine *where* it's gone!  I'd 
kind of expected that the window manager (fluxbox) would get first pick of 
key bindings, but guess I'm not understanding that right.  Is there any 
way to discover what the existing key bindings are?

Java is wonky. I've tried investigating other problems with resizing
windows (though I haven't heard of troubles with moving) and drove
myself batty. All I can say is that, in the case I investigated, it's
something to do with window initialization, as windows that are
initialized under fluxbox behave just as poorly when you switch to
another window manager (and so this is obviously java's fault to some degree).

As for the keybinding that doesn't work, there's probably another
program running on your system that grabs the same keybinding.

  Mark

On Mon, Feb 15, 2010 at 11:19 PM, Michael Abbott
<michael@...> wrote:
> Has anybody here tried using matlab with fluxbox?  I don't know what's
> going on, but the results are pretty horrible.
>
> The most obvious and reproducible problem is trying to move windows.  If
> you have matlab (my version is pretty old, 7.0.1) then try the following:
>
> 1. Run: matlab -nojvm
> 2. Plot anything
> 3. Try to move the plotted window
>
> As I move the window with my mouse it jumps all over the place, typically
> trying to leap off the top of the screen, and if I'm unlucky it just
> disappears off the screen.  If that happens the only way to get it back
> seems to be to maximise the window (at least it still appears in the task
> bar) and try to resize it.  Unfortunately resizing also causes the window
> to leap about.
>
> The -nojvm option disables the matlab Java VM.  If I just run `matlab`
> then the windows are a bit better behaved, but still rather unpredictable:
> in this case, bringing up a plotted window involves a bit of a treasure
> hunt as the window appears and then promptly vanishes.
>
> Any suggests on the best way to investigate what nonsense is going on
> here?
>
>
> For reference, I am moving the window with this .fluxbox/keys binding:
>
> OnWindow Mod4 Mouse1 :MacroCmd {Raise} {Focus} {StartMoving}
>
>
>
> Another peculiarity on this particular system (Red Hat).  I have the
> following two further entries in my keys file:
>
> Mod4 Tab :ClientMenu (workspace)
> Mod4 Shift Tab :ClientMenu
>
> The first works perfectly well, the second does nothing.  Very odd, as
> exactly the same configuration works perfectly well on my Ubuntu system.
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> Fluxbox-devel mailing list
> Fluxbox-devel@...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>

hello,

> This patch makes a resize of the window. When moving one window to the next head
> the relative window size to the old head is adapted to the size of the new head.

understandable feature, though some folks like the current way of
putting a window onto the other head. i propose you tweak the "SetHead
<number>" and "SendTo[Next|Prev]Head <offset>" commands a bit to
accept another optional parameter called 'relative' or 'scaled' or
'keep_aspect' or whatever you can come up with.

just a minor hint: try to throw out the tabs in your code, it collides
with the way we use tabs in fluxbox.

cheers,
mathias
-- 
  [uid] mathias gumz [mail] akira at fluxbox dot org [pgp] 1024D/F6F6B18C
  [www] http://www.darkshed.net/ [irc] ak|ra (#fluxbox at freenode.org)

Yeah, the default behavior should definitely be not to resize the window.

There's a different way of approaching this that I've had on my list
of long term goals for a while. Basically, you want some windows to
have their size and/or location stored as a fraction of the head size
instead of in pixels (location should also be stored relative to a
certain corner of the screen). Other windows could keep the pixel
specification. Then, when something happens to the head size, such as
a resolution change, a rotation, changing struts, or moving the window
to another head, the window would be updated to reflect that change.

In the meantime, I'm happy to include this once the proposed changes
have been made.

  Mark

On Wed, Feb 3, 2010 at 11:07 PM, Mathias Gumz <akira@...> wrote:
> hello,
>
>> This patch makes a resize of the window. When moving one window to the next head
>> the relative window size to the old head is adapted to the size of the new head.
>
> understandable feature, though some folks like the current way of
> putting a window onto the other head. i propose you tweak the "SetHead
> <number>" and "SendTo[Next|Prev]Head <offset>" commands a bit to
> accept another optional parameter called 'relative' or 'scaled' or
> 'keep_aspect' or whatever you can come up with.
>
> just a minor hint: try to throw out the tabs in your code, it collides
> with the way we use tabs in fluxbox.
>
> cheers,
> mathias
> --
>  [uid] mathias gumz [mail] akira at fluxbox dot org [pgp] 1024D/F6F6B18C
>  [www] http://www.darkshed.net/ [irc] ak|ra (#fluxbox at freenode.org)
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Fluxbox-devel mailing list
> Fluxbox-devel@...
> https://lists.sourceforge.net/lists/listinfo/fluxbox-devel
>