Re: [dwm] some opinions

"Anselm R. Garbe" <arg_AT_suckless.org> wrote:
> On Fri, Oct 26, 2007 at 07:12:24PM +0200, Robert Figura wrote:
> > "Anselm R. Garbe" <arg_AT_suckless.org> wrote:
> > > I consider the idea of having a Button struct for 4.7.
[...]
> > >> How to give a client * to a handler?
>
> I'm not sure if I like the Button struct idea, because it
> has a lot of impacts which are more complicated than shortcuts.
> This is related to the fact that we need to grab/ungrab for
> button events on client windows.
>
> If it is only about defining what happens on Button1...3 press
> on the bar window or on the selected client window, we could
> think about such thing. Then I see two different structs, one
>
> Button barclick[] {...};
>
> and one
>
> Button clientclick[] {...};

Considering that i underestimated the complications and probably
overestimated the usefulness it is probably not worth the effort to put
clientclick[] into existence. For me, the puzzle remains if it could be
done in a clean way.

But i think barclick[] on the other hand may well be worth it.

> Because in any case, the focus model should not be changed. So a
> client button handler can rely on sel.

That's good news.

> > >> ... needs the only three global variables
> > >> that aren't available at the inclusion of config.h.
> >
> > Let me rephrase it. The variables ntags, seltags[] and prevtags[]
> > aren't available for extension in a .c file included from config.h. Is
> > this policy (you don't want the people to write their own view()
> > routine) or do you, as it may not be, care at all?
>
> Well, I consider moving those definitions to config.h right after
> the tags definition in 4.7, then there won't be any exceptions
> in the use of the variables and functions for any included
> patch.

That will work. I think it will yield the opportunity to implement some
of the patches as external file. I certainly feel myself better if i can
keep most of my code separate.

> > >> While testing with OJ Mixer i found something in configurerequest()
[...]
> > In short: Why shouldn't the layout react on a client changing size?
>
> Managed/tiled windows are should accept the size provided by the
> arrange() - usually tile() - algorithm. The tile() algorithm
> is not intended to provide any support for tiled windows
> requesting a different size. From this point of view
> configurerequest() works correctly. And there is no intention to
> change this, because dwm won't toggle the size of OJ Mixer as
> long as it is tiled. Hence a call to arrange would be useless,
> because dwm tells OJ Mixer in an ICCCM-conformant way that
> it doesn't accepts the configure request of OJ Mixer. If
> the mixer application behaves incorrectly in your opinion,
> than it seems to be broken. Thus I recommend you to define it as
> a floating app.

Good argument. We wouldn't be here if you hadn't sticked to the icccm
so consistently. The idea felt so natural when i found my hack that i
didn't even consider that what i had done indeed was a hack.

Quirks mode is not part of the policy and i think i should be thankful.

> > >> The other thing with resizehints is that the last client gets the
> > >> benefit from the space saved. I'd like to layout the clients in reverse
> > >> order but that'd mean more hacking than i'm currently willing to do.
> >
> > Don't know how it eluded me but clients are already doubly linked.
> > Maybe i haven't seen it because i didn't notice any code using it...
>
> Well at least detach() and focusprev() use the reverse pointers.

I definitely should try using it next time. Got to fix a bug and test an
idea now.

Regards
  - Robert Figura
Received on Sun Oct 28 2007 - 02:22:58 UTC