I replaced stack memory allocations with PATH_MAX by heap memory
allocations on post-2.2 branch because PATH_MAX isn't necessary defined
according to POSIX specification. For instance GNU/Hurd doesn't have
PATH size restriction, thus doesn't defined PATH_MAX and compilation
will fail.
Signed-off-by: Julien Danjou <julien@danjou.info>
protocol to speak to them. Given a textbox widget definition like this:
textbox mail {
default = 0
}
textbox time {}
We can update the boxes individually by going:
echo 0 tell_widget mail 10
echo 0 tell_widget time 12:01
Text boxes will dynamically resize to fit their contents. A textbox can be
cleared by going:
echo 0 tell_widget name
A text-box containing no text will take up 0 space in the bar, i.e. it will not
be visible at all
Textboxes now supersede statusbar_set_text, so this call has been removed.
The big change here is that we now keep our configuration structure in a global
variable called globalconf. This radically simplifies many interfaces, since
passing awesomeconf everywhere is no longer necessary. There are also more
subtle interface effects - now we can reliably identify a screen from just a
screen ID, rather than an awesomeconf, screenid tuple.
Overall, this patch makes most of the interfaces in awesome much nicer to use -
enjoy!
Yes, this is a huge patch, but since a lot of the refactoring was done
systematically using vim macros, splitting this up would have been very hard.
Hi there.
awesome-client is now linked against the whole hog of x-related libs
that awesome depends on. These get pulled in by awesome-client using the
same LDFLAGS as awesome. Removing x-related libs from the LDFLAGS for
awesome-client is only half of the story, as it also depends on util.c
which now has a couple of x-related functions. The attached patch also
splits these functions into a separate xutil.{c,h} file pair and teaches
the rest of the files to use them. Apart from the small difference in
file size (I see a 3-3.5% decrease in file size, both for a stripped and
a non-stripped awesome-client binary), this should also somewhat reduce
the startup time (since awesome-client won't have to map all of these
libraries).
Cheers...
\n\n
Julien Danjou
Arnaud Fontaine
Nikos Ntarmos
Aldo Cortesi
daniel@brinkers.de