stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] [RESEND] [PATCHES]


From: Shawn
Subject: Re: [STUMP] [RESEND] [PATCHES]
Date: Fri, 17 Oct 2008 02:01:19 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Michael Raskin <address@hidden> writes:

> Shawn wrote:
>>> I never got any reaction beyond "Oh, they got forgotten" when I
>>> reminded about these patches, so I send them once more...
>> I'm sorry.
> That's OK.
>
>>> Subject: [PATCH] Adding redisplay functionality from ratpoison 
>>> (refresh+occupy entire frame) and refresh command (just resize a step down 
>>> and a step up to make application repaint its window). Binding from 
>>> ratpoison: l is redisplay. 
>> We talked about the redisplay/refresh patch on irc. The problem is
>> that the maximize function depends on the current size for windows
>> with resize increment hints. So changing the window size and calling
>> maximize causes emacs windows (this is the window I noticed the
>> problem on) to be set to incorrect sizes.
>>
>> I like the idea. So if you can fix that, I have no problem adding it
>> to stumpwm.
>
> The problem seems to be the following: for windows like QEmu nothing can
> be done anyway; xterms are already set to wrong sizes by simple frame
> splitting. So having some corner case incompatile redisplay
> functionality seems better than nothing - there are many windows that
> make it useful and a few which get minor glitches.

No I think the problem could be fixed by resizing windows with resize
hints by multiples of those hints. Then everything should be fine.

> I would like to just rewrite all that parameter handling to something
> nicer. Afterwards both patches can be made much cleaner. Do you have
> objections?

Improving the command line argument parsing code sounds fine to me!

>>> Subject: [PATCH] Added commands to save/load placement information using 
>>> window properties. Good when restarting stumpwm..
>> 
>> This is a great idea, but not a very good implementation of it. It
>> requires the user to manually add group & frame properties to windows
>> when it should be automatic.
>> 
>> Also, the group is already stored as a _NET_* property (is it
>> _NET_DESKTOP or something?) so you don't need to set that.
>
> Well, automatic save is good unless you do something that confuses it.

Wouldn't that be considered a bug? :)

> It works, but not for me, because I recreate a few window groups in
> configuration (so hints are lost).

The rc file is loaded before windows are processed and stumpwm already
automagically places existing windows in existing groups based on
their DESKTOP property. And, actually, it already puts them in
existing frames based on their location, too. So..I'm sort of not sure
if the frame property is needed at all!

> Also I sometimes (rarely) want to test something with frame
> splitting or to pull a few windows in a temporary group, and then
> restore original placement. Restoring frame layout is usually quick
> and easy, but checking that all windows are on their places
> sometimes takes time.

If there is a bug in the dump/restore code, then it should be
addressed directly.

-Shawn




reply via email to

[Prev in Thread] Current Thread [Next in Thread]