On 18.9.2009 10:24:33 Julien Danjou wrote:
> > which
> > handles the geometry of the parent wibox,
>
> ?
> It does nothing at all.
Ok, this one does nothing, the rest do.. I was just trying to make clear
the difference between the 2 kinds of layouts.
> Yes, but not if the client is fullscreen or
At 1253216762 time_t, lukk...@email.cz wrote:
> It seems to me you are talking about awful.layout.suit.floating,
Yes I am.
> which
> handles the geometry of the parent wibox,
?
It does nothing at all.
> while I'm talking about
> awful.widget.layout.* layouts, which should handle the geometry of
On Thu, 17 Sep 2009 10:15:33 +0200 (CEST) Julien Danjou wrote:
> There can be no layout (floating is "no layout at all") so you can't
> rely on the layout to resize things. This is what things like fullscreen
> and all were handled totally C side.
It seems to me you are talking about awful.layout.
At 1253170826 time_t, lukash wrote:
> Just a note, most probably you won't want to set the geometry of the
> client itself, but set parent.fullscreen = true and let the layout
> handle the resizing of its children.
There can be no layout (floating is "no layout at all") so you can't
rely on the la
On Wed, 16 Sep 2009 16:54:10 Julien Danjou wrote:
> Attached is a small patch demonstrating the idea.
> It's not fully fonctionnal (does not handle un-fullscreen, but that's
> just a matter of adding some more line (i'm lazy)).
+client.add_signal("new", function(c)
+c:add_signal("request::full
At 1253110983 time_t, Julien Danjou wrote:
Attached is a small patch demonstrating the idea.
It's not fully fonctionnal (does not handle un-fullscreen, but that's
just a matter of adding some more line (i'm lazy)).
--
Julien Danjou
// ᐰhttp://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C
At 1253030983 time_t, Julien Danjou wrote:
> Currently unresolved issue:
> - How to handle EWMH request, like fullscreen, sticky, etc?
I've though about that. The solution I've is the following:
- When a client/wibox request a special operation like fullscreen, maximized,
sticky, etc emit a requ
On Tue, 15 Sep 2009 14:34:13 +0200 (CEST) Julien Danjou
wrote:
[...]
Ok, I surrender :) I know I know nothing...
Just keep it awesome! :)
thanks
lukash
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Hi again,
I've started to dig further into this plan, and will add a number of
ideas/concepts/how-it-will-be things. Feel free to discuss.
- We cares about tags only on top level object in the hierarchy:
+--+
| root win |
+--+
At 1253017547 time_t, lukk...@email.cz wrote:
> Except for less extendability (I think it is :) it brings speed.
Speed? Why do you want to bring speed? Is it currently slow?
Speed for speed brings nothing.
> I'm not sure if
> you have any experience with lua speed in awesome, I just found this:
>
On 15.9.2009 10:47:47 Julien Danjou wrote:
> It'd be nice if your MUA can wrap lines at ~72 chars. :)
Yes, I'll try :) I'm sorry
> Having layout written in C is just more limiting than having them in Lua
> and brings nothings but less extendability (is this a word?).
Except for less extendabili
Hi lukash,
It'd be nice if your MUA can wrap lines at ~72 chars. :)
At 1252965979 time_t, lukash wrote:
> 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 w
On Tue, 15 Sep 2009 00:06:19 +0200 (CEST) lukash wrote:
> 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
On Mon, 14 Sep 2009 15:48:19 +0200 (CEST) Julien Danjou
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 probabl
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 wrote:
> At
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 pa
-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 (ligh
Hi again,
So, I've found a plan E, which seems so far the best I've in mind.
Plan E
--
This plan is a bit heavy, redesign a part of the wibox/widget API and
will probably simplify a lot of code path currently buggy. So you might
hate it and like it at both times. That's part of its beauty.
A
18 matches
Mail list logo
