From stettberger at dokucode.de Sun Jul 13 14:41:31 2014 From: stettberger at dokucode.de (Christian Dietrich) Date: Sun, 13 Jul 2014 14:41:31 +0200 Subject: [PATCH] xrandr: subscribe to RRScreenChange event Message-ID: <87lhrxig78.fsf@dokucode.de> When Xrandr is available at compile and at run time, herbstluftwm subscribes to the screen change events. These events are send, when configuration of the monitors changes. The event is propagated to all herbstclients via the hook. randr_screen_change 4108552 1497 724 An additional script can listen to those events and can start the reconfiguration of the herbstluftwm monitors. This is especially useful for using herbstluftwm within a virtual machine, whose screen size can change quite often. --- Hopefully my mail client didn't fuckup the patch. config.mk | 7 +++-- doc/herbstluftwm.txt | 5 +++ src/main.c | 41 +++++++++++++++--------- src/randr.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++ src/randr.h | 17 ++++++++++ 5 files changed, 142 insertions(+), 17 deletions(-) create mode 100644 src/randr.c create mode 100644 src/randr.h diff --git a/config.mk b/config.mk index 2890dfb..d00645a 100644 --- a/config.mk +++ b/config.mk @@ -6,8 +6,11 @@ X11LIB = /usr/X11R6/lib XINERAMALIBS = `pkg-config --silence-errors --libs xinerama` XINERAMAFLAGS = `pkg-config --exists xinerama && echo -DXINERAMA` +XRANDRLIBS = `pkg-config --silence-errors --libs xrandr` +XRANDRFLAGS = `pkg-config --exists xrandr && echo -DXRANDR` + INCS = -Isrc/ -I/usr/include -I${X11INC} `pkg-config --cflags glib-2.0` -LIBS = -lc -L${X11LIB} -lXext -lX11 $(XINERAMALIBS) `pkg-config --libs glib-2.0` +LIBS = -lc -L${X11LIB} -lXext -lX11 $(XINERAMALIBS) ${XRANDRLIBS} `pkg-config --libs glib-2.0` ifeq ($(shell uname),Linux) LIBS += -lrt @@ -24,7 +27,7 @@ VERSIONFLAGS = \ -D HERBSTLUFT_VERSION_MINOR=$(VERSION_MINOR) \ -D HERBSTLUFT_VERSION_PATCH=$(VERSION_PATCH) CPPFLAGS ?= -CPPFLAGS += $(INCS) -D _XOPEN_SOURCE=600 $(VERSIONFLAGS) $(XINERAMAFLAGS) +CPPFLAGS += $(INCS) -D _XOPEN_SOURCE=600 $(VERSIONFLAGS) $(XINERAMAFLAGS) ${XRANDRFLAGS} CPPFLAGS += -D HERBSTLUFT_GLOBAL_AUTOSTART=\"$(CONFIGDIR)/autostart\" LDFLAGS ?= -g DESTDIR = diff --git a/doc/herbstluftwm.txt b/doc/herbstluftwm.txt index 409a43b..7c6b0db 100644 --- a/doc/herbstluftwm.txt +++ b/doc/herbstluftwm.txt @@ -1521,6 +1521,11 @@ rule 'NAME' 'WINID':: A window with the id 'WINID' appeared which triggerd a rule with the consequence hook='NAME'. +randr_screen_change 'TIMESTAMP' 'WIDTH' 'HEIGHT':: + When the xrandr extension was available at compile time and the X server does support it, this + hook is emitted, when the screen configuration has changed. This hook can be used to rearrange + the herbstluftwm monitors. + There are also other useful hooks, which never will be emitted by herbstluftwm itself, but which can be emitted with the *emit_hook* command: diff --git a/src/main.c b/src/main.c index 7d42c2e..257de1b 100644 --- a/src/main.c +++ b/src/main.c @@ -20,6 +20,7 @@ #include "stack.h" #include "object.h" #include "decoration.h" +#include "randr.h" // standard #include #include @@ -765,22 +766,24 @@ static HandlerTable g_default_handler = { static struct { void (*init)(); void (*destroy)(); + bool (*xevent)(XEvent *); } g_modules[] = { - { ipc_init, ipc_destroy }, - { object_tree_init, object_tree_destroy }, - { key_init, key_destroy }, - { settings_init, settings_destroy }, - { floating_init, floating_destroy }, - { stacklist_init, stacklist_destroy }, - { layout_init, layout_destroy }, - { tag_init, tag_destroy }, - { clientlist_init, clientlist_destroy }, - { decorations_init, decorations_destroy }, - { monitor_init, monitor_destroy }, - { ewmh_init, ewmh_destroy }, - { mouse_init, mouse_destroy }, - { hook_init, hook_destroy }, - { rules_init, rules_destroy }, + { ipc_init, ipc_destroy , 0}, + { object_tree_init, object_tree_destroy , 0}, + { key_init, key_destroy , 0}, + { settings_init, settings_destroy , 0}, + { floating_init, floating_destroy , 0}, + { stacklist_init, stacklist_destroy , 0}, + { layout_init, layout_destroy , 0}, + { tag_init, tag_destroy , 0}, + { clientlist_init, clientlist_destroy , 0}, + { decorations_init, decorations_destroy , 0}, + { monitor_init, monitor_destroy , 0}, + { ewmh_init, ewmh_destroy , 0}, + { mouse_init, mouse_destroy , 0}, + { hook_init, hook_destroy , 0}, + { rules_init, rules_destroy , 0}, + { randr_init, randr_destroy , randr_xevent}, }; /* ----------------------------- */ @@ -1009,6 +1012,14 @@ int main(int argc, char* argv[]) { void (*handler) (XEvent*) = g_default_handler[event.type]; if (handler != NULL) { handler(&event); + } else { + // query all subsystems for the xevent + for (int i = LENGTH(g_modules); i --> 0;) { + if (g_modules[i].xevent) { + bool handled = g_modules[i].xevent(&event); + if (handled) break; + } + } } } } diff --git a/src/randr.c b/src/randr.c new file mode 100644 index 0000000..fda2d09 --- /dev/null +++ b/src/randr.c @@ -0,0 +1,89 @@ +/** Copyright 2014 Christian Dietrich. All rights reserved. + * + * This software is licensed under the "Simplified BSD License". + * See LICENSE for details */ + +#include +#include +#include +#ifdef XRANDR +#include + +static Time rr_last_timestamp; +#endif + +#include "globals.h" +#include "hook.h" + +/// GLOBALS /// +static int rr_event_base; + + +/// FUNCTIONS /// +void randr_init() { + rr_event_base = -1; + +#ifdef XRANDR + int ignore; + + /* Query whether the xrandr extension is available in a version >= 1.2 */ + if (XRRQueryExtension (g_display, &rr_event_base, &ignore)) { + // priv->randr_event_base = event_base; + + int major_version; + int minor_version; + + XRRQueryVersion (g_display, &major_version, &minor_version); + if (major_version < 1 || (major_version == 1 && minor_version < 2)) { + HSDebug("randr: xrandr version is too old (%d.%d); no screen notify events will be availabe", + major_version, minor_version); + rr_event_base = -1; + return; + } + + XRRSelectInput (g_display, g_root, RRScreenChangeNotifyMask); + HSDebug("randr: requested xrandr events for root window\n"); + return; + } else { + HSDebug("randr: xrandr extension is not available"); + } +#else + HSDebug("randr: not linked against xrandr library\n"); +#endif +} + +void randr_destroy() { +} + + +bool randr_xevent(XEvent * xevent) { +#ifdef XRANDR + /* randr module didn't initialize correctly */ + if (rr_event_base == -1) { + return false; + } + + int event_num = xevent->type - rr_event_base; + + if (event_num == RRScreenChangeNotify) { + XRRScreenChangeNotifyEvent *rr_event = (XRRScreenChangeNotifyEvent *) xevent; + if (rr_last_timestamp != rr_event->timestamp) { + rr_last_timestamp = rr_event->timestamp; + + HSDebug("randr: screen change notify %u %d %d\n", + (guint32) rr_event->timestamp, + rr_event->width, rr_event->height); + + char timestamp[30] , width[30], height[30]; + snprintf(timestamp, sizeof(timestamp), "%u", (guint32) rr_event->timestamp); + snprintf(width, sizeof(width), "%d", rr_event->width); + snprintf(height, sizeof(height), "%d", rr_event->height); + + hook_emit_list("randr_screen_change", timestamp, width, height, NULL); + } + + return true; + } +#endif + return false; +} diff --git a/src/randr.h b/src/randr.h new file mode 100644 index 0000000..6e26870 --- /dev/null +++ b/src/randr.h @@ -0,0 +1,17 @@ +/** Copyright 2014 Christian Dietrich. All rights reserved. + * + * This software is licensed under the "Simplified BSD License". + * See LICENSE for details */ + From me at the-compiler.org Wed Jul 16 11:31:47 2014 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 16 Jul 2014 11:31:47 +0200 Subject: [PATCH] xrandr: subscribe to RRScreenChange event In-Reply-To: <87lhrxig78.fsf@dokucode.de> References: <87lhrxig78.fsf@dokucode.de> Message-ID: <20140716093147.GN27386@lupin> Hi, * Christian Dietrich [2014-07-13 14:41:31 +0200]: > When Xrandr is available at compile and at run time, herbstluftwm > subscribes to the screen change events. These events are send, when > configuration of the monitors changes. The event is propagated to all > herbstclients via the hook. > > randr_screen_change 4108552 1497 724 > > An additional script can listen to those events and can start the > reconfiguration of the herbstluftwm monitors. This is especially useful > for using herbstluftwm within a virtual machine, whose screen size can > change quite often. Do you know about herbstluft's detect_monitors command, and the auto_detect_monitors settings? IMHO it would make more sense to make that work with XRandR (in addition to the existing Xinerama code). Then the other question is if you still need a hook for it, when HLWM reconfigures the monitors automatically. If so, it might make sense to emit it from the Xinerama code as well, if possible. > Hopefully my mail client didn't fuckup the patch. Looks like it did? I have the impression randr.h should be longer than that: > diff --git a/src/randr.h b/src/randr.h > new file mode 100644 > index 0000000..6e26870 > --- /dev/null > +++ b/src/randr.h > @@ -0,0 +1,17 @@ > +/** Copyright 2014 Christian Dietrich. All rights reserved. > + * > + * This software is licensed under the "Simplified BSD License". > + * See LICENSE for details */ > + Then some other feedback and minor nitpicks: > @@ -765,22 +766,24 @@ static HandlerTable g_default_handler = { > static struct { > void (*init)(); > void (*destroy)(); > + bool (*xevent)(XEvent *); > } g_modules[] = { > - { ipc_init, ipc_destroy }, > - { object_tree_init, object_tree_destroy }, > - { key_init, key_destroy }, > - { settings_init, settings_destroy }, > - { floating_init, floating_destroy }, > - { stacklist_init, stacklist_destroy }, > - { layout_init, layout_destroy }, > - { tag_init, tag_destroy }, > - { clientlist_init, clientlist_destroy }, > - { decorations_init, decorations_destroy }, > - { monitor_init, monitor_destroy }, > - { ewmh_init, ewmh_destroy }, > - { mouse_init, mouse_destroy }, > - { hook_init, hook_destroy }, > - { rules_init, rules_destroy }, > + { ipc_init, ipc_destroy , 0}, > + { object_tree_init, object_tree_destroy , 0}, > + { key_init, key_destroy , 0}, > + { settings_init, settings_destroy , 0}, > + { floating_init, floating_destroy , 0}, > + { stacklist_init, stacklist_destroy , 0}, > + { layout_init, layout_destroy , 0}, > + { tag_init, tag_destroy , 0}, > + { clientlist_init, clientlist_destroy , 0}, > + { decorations_init, decorations_destroy , 0}, > + { monitor_init, monitor_destroy , 0}, > + { ewmh_init, ewmh_destroy , 0}, > + { mouse_init, mouse_destroy , 0}, > + { hook_init, hook_destroy , 0}, > + { rules_init, rules_destroy , 0}, > + { randr_init, randr_destroy , randr_xevent}, > }; Wouldn't it make more sense to use NULL instead of 0 here? Also commas are before the spaces in the first column but after the spaces in the second ;) > + /* Query whether the xrandr extension is available in a version >= 1.2 */ > + if (XRRQueryExtension (g_display, &rr_event_base, &ignore)) { > ... For the sake of consistency, you might want to remove the spaces before ( with function calls. I think the current way this is handled in hlwm currently is "foo(...)" but "while (...)" (i.e., spaces only with control structures). > + HSDebug("randr: xrandr version is too old (%d.%d); no screen notify events will be availabe", > + major_version, minor_version); s/availabe/available/ ;) > + HSDebug("randr: xrandr extension is not available"); There's a newline missing (same with some other HSDebug calls). > + char timestamp[30] , width[30], height[30]; No space before that comma :P Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From edu at thorsten-wissmann.de Mon Jul 21 23:58:53 2014 From: edu at thorsten-wissmann.de (Thorsten =?iso-8859-1?Q?Wi=DFmann?=) Date: Mon, 21 Jul 2014 23:58:53 +0200 Subject: Migration to C++ (?) In-Reply-To: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> Message-ID: <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Hi, I just merged the C++ branch and pushed it. On Mon, Jun 30, 2014 at 12:36:44PM +0200, Thorsten Wi?mann wrote: > What do you think? There were some reactions and questions on the IRC. Here's a short FAQ: - Q: What about glib? A: I will migrate the datastructures continuously from glib to STL, which is a built-in library of C++. So on some day, no glib is required anymore. - Q: Isn't it problematic to write a library (i.e. libherbstclient) in C++? A: herbstclient stays C to make it easy to link it into any kind of programming language. - Q: I don't like OOP/Design-Patterns!.. A: Using C++ does not mean one needs to use the bad features of OOP or Design-Patterns. C++ is just a superset of C with respect to syntax and features. - Q: Does it still run on *bsd? A: As long as there is some C++ compiler (like g++ or clang++), hlwm will still run there. If you have still doubts or questions please ask! Cheers, Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From cickumqt at gmail.com Tue Jul 22 04:36:07 2014 From: cickumqt at gmail.com (Christopher Meng) Date: Tue, 22 Jul 2014 10:36:07 +0800 Subject: Migration to C++ (?) In-Reply-To: <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: Any plan of C++ on Boost? From udvzsolt at gmail.com Tue Jul 22 08:19:16 2014 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 22 Jul 2014 08:19:16 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: 2014-07-22 4:36 GMT+02:00 Christopher Meng : > Any plan of C++ on Boost? Is it serious? Herbstluftwm is a small, lightweight window manager, I think, depends on huge boost is a very-very bad idea... From udvzsolt at gmail.com Tue Jul 22 08:23:38 2014 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 22 Jul 2014 08:23:38 +0200 Subject: Migration to C++ (?) In-Reply-To: <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: 2014-07-21 23:58 GMT+02:00 Thorsten Wi?mann : > On Mon, Jun 30, 2014 at 12:36:44PM +0200, Thorsten Wi?mann wrote: > - Q: Does it still run on *bsd? > A: As long as there is some C++ compiler (like g++ or clang++), hlwm > will still run there. I've tested now on FreeBSD 10 - it's build well without any problem. Thanks for your work! From edu at thorsten-wissmann.de Tue Jul 22 09:04:04 2014 From: edu at thorsten-wissmann.de (Thorsten =?iso-8859-1?Q?Wi=DFmann?=) Date: Tue, 22 Jul 2014 09:04:04 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: <20140722070404.GA2255@ghul> On Tue, Jul 22, 2014 at 08:19:16AM +0200, Zsolt Udvari wrote: > 2014-07-22 4:36 GMT+02:00 Christopher Meng : > > Any plan of C++ on Boost? > > Is it serious? Herbstluftwm is a small, lightweight window manager, I > think, depends on huge boost is a very-very bad idea... I don't really know boost. But right now I can't think of a feature we need which is not covered by STL but by boost. So I can't think of a reason to use boost here. Cheers, Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From stettberger at dokucode.de Tue Jul 22 09:12:47 2014 From: stettberger at dokucode.de (Christian Dietrich) Date: Tue, 22 Jul 2014 09:12:47 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: Zsolt Udvari writes: > 2014-07-22 4:36 GMT+02:00 Christopher Meng : >> Any plan of C++ on Boost? > Is it serious? Herbstluftwm is a small, lightweight window manager, I > think, depends on huge boost is a very-very bad idea... Ok, so let's check the facts here. Boost is a C++ Template Library. Boost itself is a large project that is right, but is it a inseperable blob? Or to give the question in other words: Do we always pay the full price of using boost, when only using a small subset of all features. Because that would be bloat. Ok, first of all, there are nearly no shared libraries in boost: -rw-r--r-- 1 root root 128K Jun 4 2013 /usr/lib/libboost_filesystem.so.1.49.0 -rw-r--r-- 1 root root 1.1M Jun 4 2013 /usr/lib/libboost_regex.so.1.49.0 -rw-r--r-- 1 root root 15K Jun 4 2013 /usr/lib/libboost_system.so.1.49.0 -rw-r--r-- 1 root root 107K Jun 4 2013 /usr/lib/libboost_thread.so.1.49.0 And you "infect" your software only with with those libraries, when you use the corresponding boost feature. So, here a module separation is in place. But is this bad? herbstluftwm already links again various libraries. $ ldd =herbstluftwm | cut -d " " -f 3 | xargs ls -lhL -rwxr-xr-x 1 root root 1.8M Apr 12 12:38 /lib/x86_64-linux-gnu/libc.so.6 -rw-r--r-- 1 root root 15K Apr 12 12:38 /lib/x86_64-linux-gnu/libdl.so.2 -rw-r--r-- 1 root root 1.1M Apr 3 16:05 /lib/x86_64-linux-gnu/libglib-2.0.so.0 -rw-r--r-- 1 root root 247K Dec 3 2013 /lib/x86_64-linux-gnu/libpcre.so.3 -rwxr-xr-x 1 root root 139K Apr 12 12:38 /lib/x86_64-linux-gnu/libpthread.so.0 -rw-r--r-- 1 root root 1.3M Dec 4 2013 /usr/lib/x86_64-linux-gnu/libX11.so.6 -rw-r--r-- 1 root root 15K Jun 15 2013 /usr/lib/x86_64-linux-gnu/libXau.so.6 -rw-r--r-- 1 root root 23K Apr 30 2012 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 -rw-r--r-- 1 root root 72K Jun 30 2013 /usr/lib/x86_64-linux-gnu/libXext.so.6 -rw-r--r-- 1 root root 11K Jul 1 2013 /usr/lib/x86_64-linux-gnu/libXinerama.so.1 -rw-r--r-- 1 root root 123K Jan 15 2014 /usr/lib/x86_64-linux-gnu/libxcb.so.1 So, how much bloat are the template instantiations? Let's do a little experiment, just to get an impression and not to give full evidence. How is it with the boost::bind library? //////////////////////////////////////////////////////////////// L qy03fugy at faui49r /tmp % cat test.cc #include #ifdef USE_BOOST #include "boost/bind.hpp" #endif void nine_arguments( int i1,int i2,int i3,int i4, int i5,int i6,int i7,int i8, int i9) { std::cout << i1 << i2 << i3 << i4 << i5 << i6 << i7 << i8 << i9 << '\n'; } void(*funcptr)(int, int, int, int, int, int, int, int, int) = nine_arguments; int main(int argc, int *argv[]) { int i1=1,i2=2,i3=3,i4=4,i5=5,i6=6,i7=7,i8=8,i9=9; #ifdef USE_BOOST (boost::bind(funcptr,_9,_2,_1,_6,_3,_8,_4,_5,_7)) (i1,i2,i3,i4,i5,i6,i7,i8,i9); #else funcptr(i9, i2, i1, i6, i3, i8, i4, i5, i7); #endif return 0; } L qy03fugy at faui49r /tmp % g++ test.cc -D USE_BOOST -o with-boost; g++ test.cc -D USE_BOOST -o with-boost test.cc:16:5: warning: second argument of ?int main(int, int**)? should be ?char **? [-Wmain] [...] L qy03fugy at faui49r /tmp % ./with-boost; ./without-boost 921638457 921638457 L qy03fugy at faui49r /tmp % ls -lh with* -rwxr-xr-x 1 qy03fugy immdstud 22K Jul 22 09:05 with-boost* -rwxr-xr-x 1 qy03fugy immdstud 8.9K Jul 22 08:53 without-boost* //////////////////////////////////////////////////////////////// So here we see a little bloat, but we used g++ without optimizations. But what happens if we enable the least optimization level -O1? L qy03fugy at faui49r /tmp % g++ test.cc -D USE_BOOST -o with-boost -O1; g++ test.cc -D USE_BOOST -o with-boost -O1 test.cc:16:5: warning: second argument of ?int main(int, int**)? should be ?char **? [-Wmain] [...] L qy03fugy at faui49r /tmp % ./with-boost; ./without-boost 921638457 921638457 L qy03fugy at faui49r /tmp % ls -lh with* -rwxr-xr-x 1 qy03fugy immdstud 8.9K Jul 22 09:05 with-boost* -rwxr-xr-x 1 qy03fugy immdstud 8.9K Jul 22 08:53 without-boost* //////////////////////////////////////////////////////////////// And suddenly all my macro "bloat" disappears. Because macros are often used to hide boiler plate code in a nice API. When you want to know more about C++ template programming I would recommend reading Modern C++ Design; Andrei Alexandescu So, after I've shown that boost does not necessarily mean bloat, I want to empasize that I do *not* recommend the usage of boost in all cases or that it should be used extensively in herbstluftwm. BUT, if you make the claim, that boost is out of hell all is big, large and whatever, please check the facts first. Using Boost it not equal to Using Boost. That boot inhibits always bloat is a myth. chris From udvzsolt at gmail.com Tue Jul 22 09:26:21 2014 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 22 Jul 2014 09:26:21 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: I wrote boost is huge not bloatware. Yes, usage of boost has many-many more benefit which is larger than the size of boost in cases. But using only some functions from boost... I think sometimes easier create these functions than import many libs. But if any program needs boost you should install it. Many systems doesn't have boost installed - why install it because of only one simple and _lightweight_ program? I hope it's clear what I want to say. I think Thorsten has right: what is the benefit of boost in hlwm? Zsolt 2014-07-22 9:12 GMT+02:00 Christian Dietrich : > Zsolt Udvari writes: > >> 2014-07-22 4:36 GMT+02:00 Christopher Meng : >>> Any plan of C++ on Boost? > >> Is it serious? Herbstluftwm is a small, lightweight window manager, I >> think, depends on huge boost is a very-very bad idea... > > Ok, so let's check the facts here. Boost is a C++ Template > Library. Boost itself is a large project that is right, but is it a > inseperable blob? Or to give the question in other words: Do we always > pay the full price of using boost, when only using a small subset of all > features. Because that would be bloat. > > Ok, first of all, there are nearly no shared libraries in boost: > > -rw-r--r-- 1 root root 128K Jun 4 2013 /usr/lib/libboost_filesystem.so.1.49.0 > -rw-r--r-- 1 root root 1.1M Jun 4 2013 /usr/lib/libboost_regex.so.1.49.0 > -rw-r--r-- 1 root root 15K Jun 4 2013 /usr/lib/libboost_system.so.1.49.0 > -rw-r--r-- 1 root root 107K Jun 4 2013 /usr/lib/libboost_thread.so.1.49.0 > > And you "infect" your software only with with those libraries, when you > use the corresponding boost feature. So, here a module separation is in > place. But is this bad? herbstluftwm already links again various > libraries. > > $ ldd =herbstluftwm | cut -d " " -f 3 | xargs ls -lhL > -rwxr-xr-x 1 root root 1.8M Apr 12 12:38 /lib/x86_64-linux-gnu/libc.so.6 > -rw-r--r-- 1 root root 15K Apr 12 12:38 /lib/x86_64-linux-gnu/libdl.so.2 > -rw-r--r-- 1 root root 1.1M Apr 3 16:05 /lib/x86_64-linux-gnu/libglib-2.0.so.0 > -rw-r--r-- 1 root root 247K Dec 3 2013 /lib/x86_64-linux-gnu/libpcre.so.3 > -rwxr-xr-x 1 root root 139K Apr 12 12:38 /lib/x86_64-linux-gnu/libpthread.so.0 > -rw-r--r-- 1 root root 1.3M Dec 4 2013 /usr/lib/x86_64-linux-gnu/libX11.so.6 > -rw-r--r-- 1 root root 15K Jun 15 2013 /usr/lib/x86_64-linux-gnu/libXau.so.6 > -rw-r--r-- 1 root root 23K Apr 30 2012 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 > -rw-r--r-- 1 root root 72K Jun 30 2013 /usr/lib/x86_64-linux-gnu/libXext.so.6 > -rw-r--r-- 1 root root 11K Jul 1 2013 /usr/lib/x86_64-linux-gnu/libXinerama.so.1 > -rw-r--r-- 1 root root 123K Jan 15 2014 /usr/lib/x86_64-linux-gnu/libxcb.so.1 > > So, how much bloat are the template instantiations? Let's do a little > experiment, just to get an impression and not to give full evidence. How > is it with the boost::bind library? > > //////////////////////////////////////////////////////////////// > L qy03fugy at faui49r /tmp % cat test.cc > #include > #ifdef USE_BOOST > #include "boost/bind.hpp" > #endif > > void nine_arguments( > int i1,int i2,int i3,int i4, > int i5,int i6,int i7,int i8, int i9) { > std::cout << i1 << i2 << i3 << i4 << i5 > << i6 << i7 << i8 << i9 << '\n'; > } > > void(*funcptr)(int, int, int, int, int, > int, int, int, int) = nine_arguments; > > int main(int argc, int *argv[]) { > int i1=1,i2=2,i3=3,i4=4,i5=5,i6=6,i7=7,i8=8,i9=9; > > #ifdef USE_BOOST > (boost::bind(funcptr,_9,_2,_1,_6,_3,_8,_4,_5,_7)) > (i1,i2,i3,i4,i5,i6,i7,i8,i9); > #else > funcptr(i9, i2, i1, i6, i3, i8, i4, i5, i7); > #endif > return 0; > } > L qy03fugy at faui49r /tmp % g++ test.cc -D USE_BOOST -o with-boost; g++ test.cc -D USE_BOOST -o with-boost > test.cc:16:5: warning: second argument of ?int main(int, int**)? should be ?char **? [-Wmain] > [...] > L qy03fugy at faui49r /tmp % ./with-boost; ./without-boost > 921638457 > 921638457 > L qy03fugy at faui49r /tmp % ls -lh with* > -rwxr-xr-x 1 qy03fugy immdstud 22K Jul 22 09:05 with-boost* > -rwxr-xr-x 1 qy03fugy immdstud 8.9K Jul 22 08:53 without-boost* > > > //////////////////////////////////////////////////////////////// > > So here we see a little bloat, but we used g++ without > optimizations. But what happens if we enable the least optimization > level -O1? > > L qy03fugy at faui49r /tmp % g++ test.cc -D USE_BOOST -o with-boost -O1; g++ test.cc -D USE_BOOST -o with-boost -O1 > test.cc:16:5: warning: second argument of ?int main(int, int**)? should be ?char **? [-Wmain] > [...] > L qy03fugy at faui49r /tmp % ./with-boost; ./without-boost > 921638457 > 921638457 > L qy03fugy at faui49r /tmp % ls -lh with* > -rwxr-xr-x 1 qy03fugy immdstud 8.9K Jul 22 09:05 with-boost* > -rwxr-xr-x 1 qy03fugy immdstud 8.9K Jul 22 08:53 without-boost* > > //////////////////////////////////////////////////////////////// > > And suddenly all my macro "bloat" disappears. Because macros are often > used to hide boiler plate code in a nice API. When you want to know more > about C++ template programming I would recommend reading > > Modern C++ Design; Andrei Alexandescu > > So, after I've shown that boost does not necessarily mean bloat, I want > to empasize that I do *not* recommend the usage of boost in all cases or > that it should be used extensively in herbstluftwm. BUT, if you make the > claim, that boost is out of hell all is big, large and whatever, please > check the facts first. Using Boost it not equal to Using Boost. That > boot inhibits always bloat is a myth. > > chris From stettberger at dokucode.de Tue Jul 22 09:48:41 2014 From: stettberger at dokucode.de (Christian Dietrich) Date: Tue, 22 Jul 2014 09:48:41 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: Zsolt Udvari writes: > I wrote boost is huge not bloatware. Ok, so your problem is the size of the software "boost", not it influence on the size of herbstluftwm. > Yes, usage of boost has many-many more benefit which is larger than > the size of boost in cases. But using only some functions from > boost... I think sometimes easier create these functions than import > many libs. So, you would also say, that using the C++STL is a bad idea, since it is a huge library. The same is true for the libc or for glib. So where do you see the difference. > But if any program needs boost you should install it. Many systems > doesn't have boost installed - why install it because of only one > simple and _lightweight_ program? I hope it's clear what I want to > say. OK, again. When compiling with boost, the package does not necessarily need boost installed: $ ldd with-boost linux-vdso.so.1 => (0x00007fff2230e000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc4d3275000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc4d2eaf000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc4d2ba8000) /lib64/ld-linux-x86-64.so.2 (0x00007fc4d35ae000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc4d2992000) So a debian package user does not need boost to be installed. > I think Thorsten has right: what is the benefit of boost in hlwm? I've not said that boost has any benefits for hlwm. I just wanted to say, that boost is no bloat and that the "size" of boost does not matter. chris From udvzsolt at gmail.com Tue Jul 22 10:03:13 2014 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 22 Jul 2014 10:03:13 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: > So, you would also say, that using the C++STL is a bad idea, since it is > a huge library. The same is true for the libc or for glib. So where do > you see the difference. No, this isn't same. Why? The libc, glib, etc. is used many-many program so it's installed on many systems. If you want install hlwm, you've installed some GUI programs (if not, why do you need window manager? :) ). It's almost impossible to skip glib, so you've installed glib. But boost libs needed by only some programs, not almost all. On my system boost is needed by only Libreoffice. If I haven't Libreoffice, I don't need boost. > OK, again. When compiling with boost, the package does not necessarily > need boost installed: So boost is only buildtime-dependency everytime? > I've not said that boost has any benefits for hlwm. I just wanted to > say, that boost is no bloat and that the "size" of boost does not > matter. But if you doesn't have any boost-specific program you don't need boost. Boost isn't widely used lib as gtk, glib or similar. So this is the reason why I think *hlwm* shouldn't use boost. Zsolt From edu at thorsten-wissmann.de Tue Jul 22 10:44:07 2014 From: edu at thorsten-wissmann.de (Thorsten =?iso-8859-1?Q?Wi=DFmann?=) Date: Tue, 22 Jul 2014 10:44:07 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: <20140722084407.GA9759@ghul.eduroam.tuwien.ac.at> On Tue, Jul 22, 2014 at 10:03:13AM +0200, Zsolt Udvari wrote: > > So, you would also say, that using the C++STL is a bad idea, since it is > > a huge library. The same is true for the libc or for glib. So where do > > you see the difference. > No, this isn't same. Why? The libc, glib, etc. is used many-many > program so it's installed on many systems. If you want install hlwm, > you've installed some GUI programs (if not, why do you need window > manager? :) ). It's almost impossible to skip glib, so you've > installed glib. But boost libs needed by only some programs, not > almost all. On my system boost is needed by only Libreoffice. If I > haven't Libreoffice, I don't need boost. > > Boost isn't widely used lib as gtk, glib or similar. So this is > the reason why I think *hlwm* shouldn't use boost. I don't share the opinion that the choosing of libraries depends so much on what the others choose. More important for me is: 1. Does the library help me by doing the work for me? (in particular: does it help me creating a stable user-experience?) 2. Is the library itself stable & reliable? 3. Can it be installed easily be users? And both boost and STL and glib fulfill the third criterion. But I think STL fulfills the first much better than glib. I just don't see any advantage of boost over STL, and that is *the only reason* I wouldn't switch to boost. Just like Chris showed, in that tiny dimensions of size (no matter if huge, bloat or whatever you measure), I don't care about binary filesize or number of installed packages or hard disk usage... Cheers, Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From udvzsolt at gmail.com Tue Jul 22 10:58:42 2014 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Tue, 22 Jul 2014 10:58:42 +0200 Subject: Migration to C++ (?) In-Reply-To: <20140722084407.GA9759@ghul.eduroam.tuwien.ac.at> References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> <20140722084407.GA9759@ghul.eduroam.tuwien.ac.at> Message-ID: > I don't share the opinion that the choosing of libraries depends so much > on what the others choose. More important for me is: ... > 3. Can it be installed easily be users? Yes, the third criteria is important too. And what libs can be easily install? Which is packaged (or has ebuild, etc.). Which libs are packaged? The widely-used libs not the "made-by-one-man-and-share-on-github"-libs :) Yes, boost is commonly-used lib. And if hlwm will use boost... I'll not glad but install boost and continue using hlwm - the good window manager is more important for me than about plus 130M. Zsolt From stettberger at dokucode.de Tue Jul 22 13:48:56 2014 From: stettberger at dokucode.de (Christian Dietrich) Date: Tue, 22 Jul 2014 13:48:56 +0200 Subject: Migration to C++ (?) In-Reply-To: References: <20140630103643.GA22123@hoth.roethelheim.stw.uni-erlangen.de> <20140721215853.GA24641@ghul.eduroam.tuwien.ac.at> Message-ID: Zsolt Udvari writes: > So boost is only buildtime-dependency everytime? It depends on the part of boost you're using. But many boost components are only a build dependency. Because they are templates, which are always located in the header files. libboost1.54-dev consists of 1.8 million lines of headers in 9447 files. These headers contain nearly all all of boost and the package does depend only on the C++STL. Be aware, that in those 2 million lines of templates for example a full parser generator is included. So, perhaps is boost a big library (91mb of headers) on the developers machine, but not on the users one. And another note, because it seems for me that some people think boost is here to replace the STL. Boost is the playground for the C++ developers. Many of the features we nowerdays love in C++11 were implemented and tested before in boost. If you're interessted in this, search for C++ technical report 1[1]. chris BTW: I do not like boost very much either, I just wanted to clarify the confusion a little bit. [1] http://www.boost.org/doc/libs/?view=filtered_std-tr1