At 1248034560 time_t, Gregor Best wrote:
Okay, first bug reports are coming in, and I love that :) Uli reported
that awful.widget.graph and awful.widget.progressbar don't take the
layout parameter, a thing I indeed missed. A fixed version is
attached. I'm also writing a patch for konius
On Mon, Jul 27, 2009 at 11:08:10AM +0200, Julien Danjou wrote:
[...]
That one pushed.
You did not finished the other one, it seems?
[...]
Didn't have the time, sorry. I'll work on it tonight.
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
Okay, first bug reports are coming in, and I love that :) Uli reported
that awful.widget.graph and awful.widget.progressbar don't take the
layout parameter, a thing I indeed missed. A fixed version is
attached. I'm also
On Sat, Jul 18, 2009 at 04:02:13AM +0100, koniu wrote:
I've updated to see what its like and apart of my widgetbar being a
mess, but I have a problem with the naughty patch which renders it
unusable under certain condition:
W: awesome: event_handle_key:549: error running function:
Okay, first bug reports are coming in, and I love that :) Uli reported
that awful.widget.graph and awful.widget.progressbar don't take the
layout parameter, a thing I indeed missed. A fixed version is
attached. I'm also writing a patch for konius problem atm, I'll send
that later
--
GCS/IT/M d-
On Thu, Jul 16, 2009 at 10:52:36AM +0200, Julien Danjou wrote:
[...]
I don't think promptbox need a layout since there's only one widget
inside the returned table.
(same remark for the awful.widget.promptbox patch).
[...]
Well, but that poses some usability problems. If we rely on the
At 1247840226 time_t, Gregor Best wrote:
Btw.: have fun at the beach and don't let the jellyfish sting you :P
Seems I really need some beach time yeah, just got what you meant with
your explanation on IRC. Thanks for your losing your time with me. :)
I've merged the whole patchset.
Congrats,
I've updated to see what its like and apart of my widgetbar being a
mess, but I have a problem with the naughty patch which renders it
unusable under certain condition:
W: awesome: event_handle_key:549: error running function:
/usr/share/awesome/lib/naughty.lua:385: attempt to perform arithmetic
Hi Gregor,
At 1247706265 time_t, Gregor Best wrote:
Everything seems fine to me! I just have a couple of question:
for s = 1, screen.count() do
-- Create a promptbox for each screen
-mypromptbox[s] = awful.widget.prompt({ align = left })
+mypromptbox[s] = awful.widget.prompt({
Oh, I forgot to mention, the two flavors of the vertical layout have
been merged into one. The layout is now called
awful.widget.layout.vertical.flex, as that's essentially what it is (a
flex vertical layout)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+
On Mon, Jul 13, 2009 at 01:55:55PM +0200, Julien Danjou wrote:
[...]
{
layout = rightleft,
mytasklist,
}
with mytasklist.layout = flex
would not align the tasklist on the right using flex layout for all
elements?
[...]
See bottom :)
[...]
I can't see why.
If you have
At 1247583756 time_t, Gregor Best wrote:
I can provide arguments why your idea is suboptimal :) At the moment,
from the C point of view we simply have a table with, say, 20 widgets
(including things like tag- and tasklists). After calling the layout
function, the C code expects a Lua table
On Tue, Jul 14, 2009 at 05:31:35PM +0200, Julien Danjou wrote:
At 1247583756 time_t, Gregor Best wrote:
I can provide arguments why your idea is suboptimal :) At the moment,
from the C point of view we simply have a table with, say, 20 widgets
(including things like tag- and tasklists).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
On Tue, Jul 14, 2009 at 05:31:35PM +0200, Julien Danjou wrote:
At 1247583756 time_t, Gregor Best wrote:
I can provide arguments why your idea is suboptimal :) At the moment,
from the C point of view we simply have a table
At 1247485510 time_t, Gregor Best wrote:
That could be the same problem I fixed in the horizontal layouts. I'll
take a look at that.
Many thanks in advance. :)
This should be useless. As far as I understand, mytasklist[s] is a
table, which has _no_ layout. If flex is applying because
On Thu, Jul 09, 2009 at 02:03:43PM +0200, Uli Schlachter wrote:
Julien Danjou wrote:
At 1247139117 time_t, Uli Schlachter wrote:
Where exactly is that endless loop? I can't seem to find it. And
frankly said, if you use looping tables for your widgets, you shouldn't
be surprised :P
You
I noticed a few essential noops in my patch, a fixed version is attached
Yay for code-shrinkage :)
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
From
I noticed a fluke in the last patch in the current series (which adds
layout support to the titlebars). A fixed version is attached, it
removes the changeset which modifies awful.widget.layout.horizontal
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE-
Man, by the time these goddamn features land in master, they'll be bug
free at this rate! What the heck are you doing?!
Honestly: the Awesome project's code review system is much more
extensive than any software company I've worked at. Cut it out you
guys, you're making everyone everywhere look
At 1247090952 time_t, Gregor Best wrote:
It does, because it removes the calculation of the actual text position
from C. Without that, widget_geometries isn't fully functional, as text
doesn't get drawn where the layout function decides it should.
Okay.
Premature optimization is the root of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
Once again, I'm very thankful for every little bit of advice, so please
review :)
From a93c80d17c649446b2d80477db8b1dfa7cece886 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Fri, 29 May 2009
At 1247096479 time_t, Gregor Best wrote:
The layouts now
use the bounds parameter only to determine the available width and
height they can put their widgets into, the X and Y coordinates are
modified by the calling functions. (A much cleaner approach, why didn't
I think of that? :)
Don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Julien Danjou wrote:
At 1247096479 time_t, Gregor Best wrote:
The layouts now
use the bounds parameter only to determine the available width and
height they can put their widgets into, the X and Y coordinates are
modified by the calling
At 1247134192 time_t, Uli Schlachter wrote:
I guess the flex layout needs the bounds and since one can nest layouts, the
other ones have to keep that bounds table up-to-date, too... I guess
Make sense.
I take back what I said. It's fine finally. :)
--
Julien Danjou
// ᐰ jul...@danjou.info
At 1247130536 time_t, Julien Danjou wrote:
--- a/widgets/graph.c
+++ b/widgets/graph.c
@@ -148,13 +148,13 @@ graph_plot_get(graph_data_t *d, const char *title)
}
static area_t
-graph_geometry(widget_t *widget, screen_t *screen, int height, int
width)
+graph_geometry(widget_t
On Thu, Jul 09, 2009 at 10:53:52AM +0200, Uli Schlachter wrote:
[...]
Uhm... I'll do in the beginning of a commit message? Copypaste is nice, but
don't forget grammar and context. :P
[...]
In my defence: It was late at night :)
[...]
+-- we are only interested in tables and widgets
On Thu, Jul 09, 2009 at 11:08:56AM +0200, Julien Danjou wrote:
At 1247096479 time_t, Gregor Best wrote:
The layouts now
use the bounds parameter only to determine the available width and
height they can put their widgets into, the X and Y coordinates are
modified by the calling functions.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
On Thu, Jul 09, 2009 at 10:53:52AM +0200, Uli Schlachter wrote:
Where exactly is that endless loop? I can't seem to find it. And
frankly said, if you use looping tables for your widgets, you shouldn't
be surprised :P
You
At 1247139117 time_t, Uli Schlachter wrote:
Where exactly is that endless loop? I can't seem to find it. And
frankly said, if you use looping tables for your widgets, you shouldn't
be surprised :P
You get what you deserve.. ok, you win
Clearly. Somehow I wonder if luaA_isloop() is even
At 1247137243 time_t, Gregor Best wrote:
But how would we then implement things like the flex layout or the
rightleft layout? Those two absolutely need to know the available space,
and IMHO it's the job of the widget layout to partition the available
space among the widgets it contains.
Yeah,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Julien Danjou wrote:
At 1247139117 time_t, Uli Schlachter wrote:
Where exactly is that endless loop? I can't seem to find it. And
frankly said, if you use looping tables for your widgets, you shouldn't
be surprised :P
You get what you deserve..
On Tue, Jul 07, 2009 at 11:38:25AM +0200, Julien Danjou wrote:
[...]
-y = area.y + (ctx-height - ext-height + 1) / 2 + margin-top;
+y = area.y + margin-top;
/* only honors alignment if enough space */
if(ext-width area.width)
I don't think this belongs to this
At 1246495186 time_t, Gregor Best wrote:
diff --git a/widget.h b/widget.h
index f2ca048..e9d9e7e 100644
--- a/widget.h
+++ b/widget.h
@@ -73,7 +73,7 @@ struct widget_node_t
widget_t *widget_getbycoords(orientation_t, widget_node_array_t *, int, int,
int16_t *, int16_t *);
void
I suggest being consistent with the other code and push the geometry
to lua with borders included. Like the client code does, or change
that, at least be consistent.
Maarten.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
On Tue, Jul 07, 2009 at 02:56:04PM +0200, Maarten Maathuis wrote:
I suggest being consistent with the other code and push the geometry
to lua with borders included. Like the client code does, or change
that, at least be consistent.
Maarten.
Good call, sounds totally reasonable. I guess
At 1246971364 time_t, Maarten Maathuis wrote:
I suggest being consistent with the other code and push the geometry
to lua with borders included. Like the client code does, or change
that, at least be consistent.
Well, I suggested to not push any geometry, which seems far better. No?
:)
I just saw a fragment of code in my mailbox, if jd has a better
suggestion, then by all means go ahead.
Maarten.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
I just noticed a little glitch in patch #10, a fixed version is
attached.
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
From d4e448cc139887c5dc8fad59aa01c6314aced2ad Mon Sep 17
At 1245973156 time_t, Gregor Best wrote:
I just found a place where it makes sense to have non-integer keys in
the widget table: the titlebars. Rewriting those to make use of integer
keys will be quite hard, as they make excessive use of integer keys and
it will make the code even less
Excerpts from Gregor Best's message of Thu Jun 25 19:39:16 -0400 2009:
I just found a place where it makes sense to have non-integer keys in
the widget table: the titlebars. Rewriting those to make use of integer
keys will be quite hard, as they make excessive use of integer keys and
it will
I forgot to mention, the patches apply onto latest git master
--
GCS/IT/M d- s+:- a--- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- O M-- V PS+ PE- Y+ PGP+++ t+ 5 X+ R tv+ b++ DI+++ D+++ G+
e- h! r y+
Gregor Best
pgpE9i3MF3sxp.pgp
Description: PGP signature
This is review of patch #3.
At 1245932662 time_t, Gregor Best wrote:
-- vim:
filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
diff --git a/lib/awful/widget/init.lua.in b/lib/awful/widget/init.lua.in
index 6d4b51c..ae0cfb2 100644
---
On Thu, Jun 25, 2009 at 02:48:57PM +0200, Julien Danjou wrote:
[...]
+for _, k in ipairs(util.table.ikeys(widgets)) do
I did not dig too far, but isn'y ipairs enough?
[...]
Nope, because ipairs stops when it encounters a nil value. The following
table would be iterated over
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All of the following stuff are proposals and small comments. Don't take me too
seriously and feel free to disagree wherever you disagree.
Gregor Best wrote:
Okay, I attached all patches I wrote so far (quite a few :).
Subject: [PATCH 01/12]
At 1245936340 time_t, Gregor Best wrote:
Nope, because ipairs stops when it encounters a nil value. The following
table would be iterated over completely:
I got that, but why would you have nil value?
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6
On Thu, Jun 25, 2009 at 03:26:48PM +0200, Uli Schlachter wrote:
[...]
Subject: [PATCH 01/12] wibox: rebuild table at every draw
diff --git a/wibox.c b/wibox.c
index eb092b2..30c85b2 100644
--- a/wibox.c
+++ b/wibox.c
@@ -541,9 +528,12 @@ luaA_wibox_invalidate_byitem(lua_State *L,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gregor Best wrote:
On Thu, Jun 25, 2009 at 03:26:48PM +0200, Uli Schlachter wrote:
Subject: [PATCH 07/12] invaders: add support for widget layouts
diff --git a/lib/invaders.lua.in b/lib/invaders.lua.in
+
At 1245947013 time_t, Gregor Best wrote:
Subject: [PATCH 10/12] systray: don't crap up on odd-sized windows
diff --git a/widgets/systray.c b/widgets/systray.c
index 0504be8..bd53ef6 100644
--- a/widgets/systray.c
+++ b/widgets/systray.c
@@ -32,32 +32,27 @@
#define
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Julien Danjou wrote:
At 1245947013 time_t, Gregor Best wrote:
Subject: [PATCH 10/12] systray: don't crap up on odd-sized windows
diff --git a/widgets/systray.c b/widgets/systray.c
index 0504be8..bd53ef6 100644
--- a/widgets/systray.c
+++
At 1245952537 time_t, Uli Schlachter wrote:
You could cast the height to (void*) and... *duck*
Please, recall me, where did you say you were living already?
--
Julien Danjou
// ᐰ jul...@danjou.info http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Don't give
On Thu, Jun 25, 2009 at 10:07:50AM +0200, Julien Danjou wrote:
At 1245885960 time_t, Gregor Best wrote:
→ Now, only widgets residing at integer indexes are supported, so you
can't do stuff like w.widgets[bar] = foo, they'll simply get ignored.
I did that because IIRC, the order of
After a long time without updates (my apologies for that), I finally got
most of the stuff needed done. Nested layouts are now handled correctly,
the systray now works a bit better and I think it's quite usable. I
threw away my idea of inventing a crazy algorithm for finding free space
in a list
Hi Gregor,
At 1237584486 time_t, Gregor Best wrote:
As every time, I'm eager to receive feedback :)
First my apologies for getting back to you so late, but I'm a bit
overbooked by real life theses days.
I took some time in the train to review your branch. I did some test,
and I was not able to
At Thu, 26 Mar 2009 14:03:06 +0100
Julien Danjou wrote:
Hi Gregor,
At 1237584486 time_t, Gregor Best wrote:
As every time, I'm eager to receive feedback :)
First my apologies for getting back to you so late, but I'm a bit
overbooked by real life theses days.
I took some time in the
At 1238077385 time_t, Gregor Best wrote:
was just created (with a nil reference as its wibox table) or whether the
widgets table was emptied with foo.widgets = { }. I don't really like my
solution because it still allows doing things like foo.widgets = nil, so I
think I'll remove that thing
Hi again from the land of widget layouts :)
I pushed another update onto git://git.mercenariesguild.net/awesome
widget-layout, this time with a little more bugfixes:
→ Wiboxes attached to the side of the screen (left / right) are now drawn
correctly
→ Titlebars work (though there's a barely
At Fri, 20 Mar 2009 22:28:06 +0100
Gregor Best wrote:
Hi again from the land of widget layouts :)
I pushed another update onto git://git.mercenariesguild.net/awesome
widget-layout, this time with a little more bugfixes:
→ Wiboxes attached to the side of the screen (left / right) are now
At 1237076946 time_t, Gregor Best wrote:
I just realized that my commit history is pretty dirty on that branch (a lot
of
merges and such), so i cleaned it a bit and put that into
git://git.mercenariesguild.net/awesome widget-layout-clean
that branch has a lot cleaner history and applies onto
At 1237208479 time_t, Julien Danjou wrote:
I ran the code, and saw no error of any kind, just no tasklist at first
glance.
Err, no it's ok, I must had some bad things in my build dir that broke
it, now the default config works flawlessly.
--
Julien Danjou
// ᐰ jul...@danjou.info
Okay, i could need some help here. It looks like everytime a wibox with a
border is created (for example by naughty), the following error occurs:
W: awesome: xerror:289: X error: request=CreatePixmap, error=BadAlloc
W: awesome: xerror:289: X error: request=149, error=BadDrawable
At Sun, 15 Mar 2009 01:07:00 +0100
Gregor Best wrote:
Hi people,
again I took some time to further refine widget layouts, and I think what I
have is now quite usable.
- widget.align is no longer neccessary. Where a widget is placed is now
exclusively defined by what layout function
At Tue, 10 Feb 2009 18:09:38 +0100
Julien Danjou wrote:
At 1234284274 time_t, Gregor Best wrote:
I created a patch to achieve this, it adds an :extents() function to each
widget. It expects one argument, which is the container height. Also, if the
widget is a systray, it expects a screen
At 1235674575 time_t, Gregor Best wrote:
Okay kids, time for another update on this :)
It's been some while since I updated last, but with a little help from Julien,
I now present the first version of widget layouts in Lua I'd use myself. It's
far from perfect, but surprisingly usable. Those
At 1234284274 time_t, Gregor Best wrote:
I created a patch to achieve this, it adds an :extents() function to each
widget. It expects one argument, which is the container height. Also, if the
widget is a systray, it expects a screen number as the second argument. If
either of these is omitted,
At 1233668296 time_t, Gregor Best wrote:
I'll try to write some demo-code for that either today or tomorrow, so we
can discuss this with some real code to work on.
Okay, as promised, here is a first, simple, draft. Right now, it works as
follows:
When we want to render a wibox, we just call
As usual, i noticed an error right after sending the patch :)
The recursion doesn't work in the patch i sent, a fixed version is attached.
--
Gregor Best
From 438abd4cbd56b4a05009db5b22f5c839c1a9e1e2 Mon Sep 17 00:00:00 2001
From: Gregor Best farha...@googlemail.com
Date: Wed, 4 Feb 2009
Hi Gregor,
At 1233760478 time_t, Gregor Best wrote:
When we want to render a wibox, we just call widget_render(wibox_t *), as
usual.
So far, so good.
widget_render(wibox_t *) then calls widget_geometries(luaA_ref, area_t), which
gets a reference to the widget table of the wibox (which
Hi Gregor,
I'm happy you launch that topic!
At 1233588224 time_t, Gregor Best wrote:
a while ago, Julien mentioned widget layouts to me, i.e. deciding where to
render a widget with some lua function instead of a hardcoded calculation,
similar to how clients are laid out with lua functions.
At Tue, 3 Feb 2009 10:44:04 +0100
Julien Danjou wrote:
Well, when I though about this, I had a somewhat different approach.
Register layout function for wibox:
wibox.widgets = { widget1, widget2, layout = awful.widget.layout.foo }
Allowing such things:
wibox.widgets = { widget1,
At 1233668296 time_t, Gregor Best wrote:
Hmm, that'd be an even better idea, if we were to do it this way, we (at least
for the beginning) wouldn't have to care for the a wibox in a wibox
scenario,
as the same could be accomplished like your example.
I'll try to write some demo-code for
Hi people,
a while ago, Julien mentioned widget layouts to me, i.e. deciding where to
render a widget with some lua function instead of a hardcoded calculation,
similar to how clients are laid out with lua functions. Today, i took a few
minutes and created a first draft on how we could accomplish
71 matches
Mail list logo
