At 1226663788 time_t, Maarten Maathuis wrote:
> Let me know if/when you want the "git format-patch -M" patch.
That'd be awesome. :)
I'll try to give a try ASAP.
People are also encouraged to test it.
Cheers,
--
Julien Danjou
// ᐰ <[EMAIL PROTECTED]> http://julien.danjou.info
// 9A0D 5FD9 EB42
On Fri, Nov 14, 2008 at 12:45 AM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 11:56 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
>> On Thu, Nov 13, 2008 at 11:36 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
>>> On Thu, Nov 13, 2008 at 11:32 PM, Julien Danjou <[EMAIL
On Thu, Nov 13, 2008 at 11:56 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 11:36 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
>> On Thu, Nov 13, 2008 at 11:32 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
>>> At 1226615131 time_t, Maarten Maathuis wrote:
Last tim
On Thu, Nov 13, 2008 at 11:36 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 11:32 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
>> At 1226615131 time_t, Maarten Maathuis wrote:
>>> Last time i checked the data was malloc'ed, and the initial state
>>> really needs to be fa
On Thu, Nov 13, 2008 at 11:32 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> At 1226615131 time_t, Maarten Maathuis wrote:
>> Last time i checked the data was malloc'ed, and the initial state
>> really needs to be false.
>> But i'll double check.
>
> No, it's p_new() which is calloc() so everything
At 1226615131 time_t, Maarten Maathuis wrote:
> Last time i checked the data was malloc'ed, and the initial state
> really needs to be false.
> But i'll double check.
No, it's p_new() which is calloc() so everything is always clean.
> It's either this or a force argument to wibox_moveresize(), ch
On Thu, Nov 13, 2008 at 11:12 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> At 1226613172 time_t, Maarten Maathuis wrote:
>> A much different patch.
>>
>> Setting XCB_WM_STATE_ICONIC on ban now, since that seems to be more
>> appropriate (it seems the ICCCM definition of that was left
>> intention
At 1226613172 time_t, Maarten Maathuis wrote:
> A much different patch.
>
> Setting XCB_WM_STATE_ICONIC on ban now, since that seems to be more
> appropriate (it seems the ICCCM definition of that was left
> intentionally vague).
Ok.
> Note the wording "to indicate that a window would not be vis
On Thu, Nov 13, 2008 at 7:25 AM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 12, 2008 at 10:07 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
>> On Wed, Nov 12, 2008 at 6:56 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
>>> At 1226511972 time_t, Erik Garrison wrote:
As discussed
On Wed, Nov 12, 2008 at 10:07 PM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 12, 2008 at 6:56 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
>> At 1226511972 time_t, Erik Garrison wrote:
>>> As discussed in the EWMH, the window manager is given discretion in how
>>> it manages offscree
On Wed, Nov 12, 2008 at 6:56 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> At 1226511972 time_t, Erik Garrison wrote:
>> As discussed in the EWMH, the window manager is given discretion in how
>> it manages offscreen client windows [1]. They may be unmapped (as in
>> the definition of iconified f
At 1226511972 time_t, Erik Garrison wrote:
> As discussed in the EWMH, the window manager is given discretion in how
> it manages offscreen client windows [1]. They may be unmapped (as in
> the definition of iconified found in the ICCCM) or managed via some
> system of virtual root windows. Probl
On Wed, Nov 12, 2008 at 03:48:14PM +0100, Maarten Maathuis wrote:
> On Wed, Nov 12, 2008 at 3:27 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> > At 1226499132 time_t, Maarten Maathuis wrote:
> >> I have one more question, are you oposed to this in a "i will never
> >> change my mind" way, because
On Wed, Nov 12, 2008 at 3:27 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> At 1226499132 time_t, Maarten Maathuis wrote:
>> I explained this once already, keeping windows mapped means their
>> content remains available when composite is active, which means near
>> instant tag switches (ignoring la
At 1226499132 time_t, Maarten Maathuis wrote:
> I explained this once already, keeping windows mapped means their
> content remains available when composite is active, which means near
> instant tag switches (ignoring layouts that do bad stuff).
I got that, but that's not really on my concern as I
On Wed, Nov 12, 2008 at 2:25 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> At 1226495402 time_t, Maarten Maathuis wrote:
>> This one should be better, but still needs real life testing ofcource.
>> It handles titlebars and also discards any events generated by
>> titlebars (based on client banned
At 1226495402 time_t, Maarten Maathuis wrote:
> This one should be better, but still needs real life testing ofcource.
> It handles titlebars and also discards any events generated by
> titlebars (based on client banned status)..
I'm still totaly unconvinced about the goodness of this patch, but w
On Wed, Nov 12, 2008 at 1:44 AM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 12, 2008 at 12:53 AM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
>> This should be ICCCM compliant, and definately has the desired near
>> instant tag switching speed.
>>
>> The change is that windows are no
On Wed, Nov 12, 2008 at 12:53 AM, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> This should be ICCCM compliant, and definately has the desired near
> instant tag switching speed.
>
> The change is that windows are now mapped once and unmapped when they
> are unmanaged
>
> The outstanding questions
This should be ICCCM compliant, and definately has the desired near
instant tag switching speed.
The change is that windows are now mapped once and unmapped when they
are unmanaged
The outstanding questions are, should (more of)
event_handle_clientmessage() be shielded off.
expose, configure, lea
20 matches
Mail list logo
