-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Julien Danjou wrote:
> Hi again,
>
> So, I've found a plan E, which seems so far the best I've in mind.
Oh noes, everybody run for their life!
> Plan E
> ------
[..]
> So the plan is:
> - Start to export "root windows" as:
> screen[N].root (lightuserdata)
> - Merge widget INTO wibox. A wibox is now a widget also.
> Since we only have 2 widget types (text/image, forget about systray for
> now), we might just remove the type={imagebox,textbox} and just add
> .text and .image properties.
> - Remove .screen property of wiboxes.
> - Add a .parent attribute to wibox. This can have values:
> - nil (not attached)
> - screen[N].root: a root window, i.e. attached to a screen (parented
> to a root window)
> - Another wibox!
What happens with xinerama/no-xinerama?
(For those that are unaware: Without xinerama you get multiple root windows,
with xinerama there is only one, big root-window)
Especially the "remove .screen property" would have weird results here. Or do
you create "fake root windows" which hide this difference? (ie. just a lua
lightuserdata which says "root window for xinerama screen 2 which is part of
real root window 1")
> Now, a widget *is* a wibox (we merge widget/wibox, remember?) so each
> wibox/widget is a X window and has its own set of events like mouse
> enter/leave, etc, directly handled by X itself. How convenient. :-)
Yay, that sounds good.
Will parent wiboxes also get the events of their child? (I don't know X handles
this, but I guess awesome could try to implement this differently again)
> With that we can build anything, like a good old notification:
>
> notify_box = wibox{ parent = screen[1].root }
> text_box = wibox{ text = "Hello world!", parent = notify_box }
> icon_box = wibox{ image = image("/home/foo/bar.png"), parent =
> notify_box }
So a wibox' .widgets property disappears? How does one set widget layouts with
this? Add a new wibox property .layout? Does awesome ignore the .layout of
non-top-level wiboxes and the widget layouts only care about those?
> Limitation:
> This drops the current possiblity to have one widget into several
> wiboxes. But who cares about that?
Advantages: This solves the problem of "unique widgets" like systray very well.
It's no longer a special case!
> How that solve titlebar? Well, kinda easy:
> We add a .parent attribute to client objects, which is by default the
> root window of the screen they are. (we could even removed the .screen
> attribute since it's the same identification).
Or not. :P
Thinking about the "root window" objects again, I think that instead of adding a
new kind of objects we could just re-use the existing screen objects. That also
hides away xinerama...
> As for wibox, the .parent can have values which are nil/root
> window/wibox. So the client becames a "widget" (child) of a wibox,
> like can be.
So setting a client's parent to nil has the same effect as setting .visible to
false? Oh, wait, .visible doesn't overwrite the .parent.
[...]
> Then, the awful code which basically uses only client.get() to retrieve
> visible client and arrange them into a layout will have to be modified,
> as many other functions. Why? Because if a client is reparented, we
> probably don't want to move the client inside its titlebar-window-wibox
> but we want to move the wibox attached to the root window.
> Probably a screen[1].root:get_windows() or something should be added,
> returning a table of all objects (wiboxes, clients) attached to the root
> window.
I think it would be a pretty good idea to document the common functions /
properties of clients and wiboxes. Can we somehow use some kind of OOP to make
"wibox" and "client" both "inherit" from some common code? "window" objects? On
the C side, window_t could have the common stuff for clients and wiboxes (eg. we
save the geometry of the window both for clients and wiboxes)
> That leaves us with the problem of tags. Currently, the wiboxes do not
> have tag. That's something we should add. Top-level objects (object
> where .parent == root window) should be able to get tags. So we can (C
> side) map/unmap top-level objects based on their tags.
Add tags to "windows" insetad of "clients". ;)
Or we could make wiboxes default to .sticky = true (another property that would
then be common between clients and wiboxes...)
> What do you think, guys?
> Feel free to ask questions if I'm not clear. This might even
> raise a few problem that I did not think of. :-)
Sounds like a good idea, jd++.
You get another "jd++" for implementing this since it will be a lot of work. Oh
and people will hate you for breaking their configs. ;)
Looks like next will be interesting again.
Uli
P.S.:
Read this mail again. First I notice that xinerama might be a problem and then I
accidentally find a solution for that problem. I love problems which solve
themselves. :)
- --
"Do you know that books smell like nutmeg or some spice from a foreign land?"
-- Faber in Fahrenheit 451
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBCAAGBQJKrkWgAAoJECLkKOvLj8sGPWUIALCUX2ClpETp8YAtUWIj2GP+
g3Bu3ghXsqwgs/2pRYo4zd0ooEynpED1zhSaOGV0/IJHxDO0V3mAcK3z4Axx6yq6
Wl2g5ijpdlAyft9UHnQETQON76ZuvvWWkDPs7ZNVHhHEMyyEB2sb92Z0H+i3N9lq
asOoz3iM6fBTIECYH+utKrwuoBsh1qC4uLvK7KvgT305WdEpLvH4ifbbZ9ZHl6ei
IIhDyehh18U5tO9bIkzPQ3UamDLowxmdX0EbKE7lRJ3UM8TiJk0Vc3O7GX8JCYYT
TLTuu27YH9ssqKIWFkk5ZOhe3AFJ/PaqfUOqdEXzNZctNA+/OjBv7Oe+58gziYA=
=qJ9S
-----END PGP SIGNATURE-----
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
