On 14.01.2012 13:29, Anurag Priyam wrote:
> On Fri, Jan 13, 2012 at 10:20 PM, Uli Schlachter <psyc...@znc.in> wrote:
>> On 13.01.2012 15:17, Anurag Priyam wrote:
> [...]
>>> That essentially means awful.tooltip and awful.mouse.finder are broken
>>> (in git master). Doesn't look like it has anything to do with my
>>> particular setup. I will see if I can fix it later.
>>
>> Looking through awful.mouse.finder, I can only find one place where .screen
>> is
>> still used and that can just be dropped.
> [...]
>> local screen = c.screen or calculate_screen(c:geometry())
>>
>> (Where calculate_screen() figures out on which screen the point given by
>> arg.x
>> and arg.y is, this is just what the "old" screen property did, too)
>
> This does seem like an easy fix for now. I have attached a patch for
> review. It is not the entire series; just an implementation of
> `calculate_screen` and its use in `awful.placement.no_offscreen`.
Patch gets a NACK, see next paragraph. :-)
> I
> shamelessly copied the logic from `screen_getbycoord` in `screen.c`.
> Can't I somehow just call `screen_getbycoord` from Lua, instead of
> re-implementing it in Lua?
I actually can't see how that'd be bad, so I just did it:
commit 826861d9678f75a40a2129ec5a25b3ca5fdca299
Author: Uli Schlachter <psyc...@znc.in>
Date: Sun Jan 15 16:05:11 2012 +0100
screen: Add screen.by_coords()
This idea came from here:
http://article.gmane.org/gmane.comp.window-managers.awesome.devel/6759
Signed-off-by: Uli Schlachter <psyc...@znc.in>
> So, Xinerama treats multiple heads as one giant screen? I can't see
> how this logic could possibly work otherwise.
Yes. Awesome 3.4 supports Xinerama and Zaphod-mode (where screens are different
and e.g. windows can't be moved between screens). Git/master now requires
Xinerama (despite all the complaints from nvidia users) and that enabled lots of
code simplifications. This is one of the places where stuff got simpler (and
this is also why a drawin/wibox no longer has a .screen property. It just
doesn't make any sense with Xinerama).
> Also, would you prefer
>
> local screen = c.screen or c:screen()
>
> instead? And perhaps define `screen()` in drawin?
Nah. Utility function to make working with lua simpler belong into awful. The C
code should just contain as few stuff as possible to make awful work (and yes,
IMHO screen.by_coords() fits with this).
>> Alternatively someone could come up with a magic way to modify
>> common/luaobject.c so that lua code can add arbitrary properties to an
>> object.
>> That'd be nicer, but I don't see that happening any time soon. :-(
>
> +1. This would be super awesome. I am completely oblivious to the
> lua-C interface, but still, how do you think can one approach this?
Hm. Each object would need an "auxiliary" table. luaA_class_index() and
luaA_class_newindex (both in common/luaclass.c) would then have to re-direct the
operation to that auxiliary table instead of calling [new]index_miss_property.
I'll see if I can do this.
Cheers,
Uli
--
"Engineering - where the semi-skilled laborers execute the vision
of those who think and dream. Hello Oompa-Loompas of science."
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
