Re: [PATCH] placement: centerx and centery
At 1252846427 time_t, Cedric GESTES wrote: Pushed, thanks! Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala. signature.asc Description: Digital signature
Re: [PATCH] runorraise
At 1252812066 time_t, Cedric GESTES wrote: I like the concept of run or raise, but your implementation. It seems there's too much duplicate with awful.rules. I guess this should be just a function and a matter of applying rules. What do you think? Cheers, -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // My root password is signature.asc Description: Digital signature
Re: Plan E (was: [RFC] Titlebar code)
This will allow a maximum of flexibility. We can regroup two or more clients into a wibox and arrange it with a layout, this is simple sublayout. Titlebar can be heavily customised. This solution seems very flexible to me. I love it :-) On Mon, Sep 14, 2009 at 3:48 PM, Julien Danjou jul...@danjou.info wrote: At 1252935073 time_t, Uli Schlachter wrote: What happens with xinerama/no-xinerama? It's just a special case, where (with 2 screens): screen[1].root == screen[2].root is true So then you just play with geometry() to set it to the screen you want. Am I answering your question, or not? 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) It can, but it's identifiable without any problem. AFAIK. So a wibox' .widgets property disappears? Yes (and I'm happy! :). 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? There's 2 options: 1. add .layout as you say. 2. Let Lua handle that. The layout function is just a function we call to rearrange wibox/widgets on certain events. Like we do with client-layout. So this can probably be done totally in Lua-land. If it's not, go back to option 1. Advantages: This solves the problem of unique widgets like systray very well. It's no longer a special case! Sheldon's voice Oh yes yes yes, and you know what? I though we could built a 'systray' object (per root window) which would be some sort of special object you can reparent too! That'd be awesome! :-) /Sheldon's voice 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... You mean using screen[N] objects? Yeah why not. That would probably be better. So we can do obj.parent = screen[N] and map .screen to be a synonym of .parent so its backward compatible. 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. Hum that's a special case. I think c.parent = nil would not be possible. mywibox.parent = nil is just a matter of destroying the wibox. But destroying a client is not something nice usually. :-) 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's not possible currently, but you know that nothings is impossible. We're are far from that. We're at the nexus between the Possible and the Impossible. We are at the Possimpible! ...well, sorry for the disgression. I'm not sure its worth adding full inherit system into the luaobject system I built between 3.3 and 3.4, but having a common structure with common code is probably the best option. That's what you describe. 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...) Yes. We may even add some EWMH things on wiboxes, like I did earlier for strut handling... 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. ;) Yes. There's a change we're talking about a major break. Maybe a major release? We'll see, stay tuned. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // And thinking so much differently. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkquSaMACgkQpGK1HsL+5c0DhACfQ/VfL+i6TptzuXmx4WHSWlJe XXUAn0brFO+oXfpxoAJ+Qvyv+TAkQA1H =cii8 -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] rules: placement and geometry
At 1252937539 time_t, Cedric GESTES wrote: placement.get_percentage(value, min, max) ? And probably a set_geometry_percentage also? :) -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Don't give up. signature.asc Description: Digital signature
Re: Plan E (was: [RFC] Titlebar code)
On Mon, 14 Sep 2009 15:48:19 +0200 (CEST) Julien Danjou jul...@danjou.info
wrote:
There's 2 options:
1. add .layout as you say.
2. Let Lua handle that.
The layout function is just a function we call to rearrange
wibox/widgets on certain events. Like we do with client-layout. So
this can probably be done totally in Lua-land. If it's not, go back to
option 1.
2. - that would need the .widgets table where you would set the layout, which
you (jd) want to remove. IMHO, you should have this information anyway, either
only as an array in C that would list all child widgets belonging to the parent
widget, and probably also as a read-only table in LUA. You need this in the
layout function and maybe for other things too. The child list would be
maintained by setting the .parent to the child. As it should be read only (or
should it?) in lua, you'd need to go the 1. way anyway :)
I think it would be good to have the layouts written in C, although it may be a
bit harder to write them, but it will be faster, and there is no other reason
to have them in lua? (except someone would wanna write his own, but it should
not be needed :)
Also, note that since you remove the nested tables in .widgets, you'll need to
nest widgets to create complex layouts, eg. a window with a titlebar:
window = wibox{ parent = screen[1].root, layout = topdown }
titlebar = wibox{ parent = window, layout = leftright }
icon = wibox{ parent = titlebar }
title = wibox{ parent = titlebar }
...
c = client{ parent = window }
Here, the titlebar widget is just a container for the pieces... I guess its ok.
(btw, .layout on widgets without children should be ignored, thats ok too I
think)
Lastly, if clients and widgets have common properties inherited from
windows, how will these properties be handled on, for example, the icon
widget in the example above, ie. in a widget inside a widget? Seems like a bit
of an inconsistency here (maybe top-level widgets should be differentiated
after all... we could call them... a wibox, maybe? :D).
Oh, and regarding screen[N] objects versus fake root windows to handle
Xinerama, it all boils down to handling the offsetting ourselves or let
reparenting do it, right? I'd say for better backwards compatibility screen[N]
would be better, but for consistency with .parent being a window to which
something is reparented, the fake (but I don't see it as fake, really)
objects would be better. Also, jd, which one would be better to handle screen
configuration changes more gracefully than restart() as someone just asked in
the ML? (probably both the same, hehe)
Anyway, I love the idea! I'm looking forward to it :) btw, I've been messing
with the layouts that Gregor sent, now I'm not sure I should go on, as it seems
it will be replaced soon now, and the basic layouts are working anyway..
I really need to go to sleep, hope I'm making some sense and its gonna be
useful to somebody :)
Cheers!
lukash
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #621 - Tab completion is slow
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#621 - Tab completion is slow User who did this - Nelson A. de Oliveira (naoliv) -- Just a comment. With the 3.3 series, while it was a little annoying to have unsorted results, there was no delay in switching to the next option. -- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=621#comment1408 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #622 - Awesome keeps loading default theme (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Nelson A. de Oliveira (naoliv) Attached to Project - awesome Summary - Awesome keeps loading default theme Task Type - Bug Report Category - Lua libraries Status - Unconfirmed Assigned To - Operating System - Linux Severity - Low Priority - Normal Reported Version - 3.4-rc1 Due in Version - Undecided Due Date - Undecided Details - Hi! Or I am needing to sleep or awesome isn't properly setting my wallpaper. While starting or restarting awesome, I can see that my background is applied and then, very fast, awesome's default background appears. My background only works when I receive: === Something went wrong while setting the wallpaper. Run 'feh --bg-scale /usr/share/awesome/themes/default/background.png' from an xterm to find out what. === What could be wrong, please? Both my rc.lua and theme.lua are attached. Thank you! Best regards, Nelson One or more files have been attached. More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=622 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
