Beta i3 window manager - help us come up with a cool config!

feh is my favorite choice as well. it's so small and has some cool capabilities over nitrogen (as an image viewer for example).

Yabar isn't working well for the pandora. I would love to use polybar but it doesn't want to compile because of the gcc 7.1 implicit fallthrough issue.
@ptitSeb help! How can I properly get make to ignore the compiler warnings? I passed -Wno-implicit-fallthrough in the CMakeList before running cmake and then make. Still fails and treats the warning as error. Argh...

btw doing it like this right now in CMakeList.txt:
set(CMAKE_CXX_FLAGS "-Wno-implicit-fallthrough")
set(CMAKE_C_FLAGS "-Wno-implicit-fallthrough")
Last edited:
Remove the Warning as Error: look for "-Wall" in the CMakeList.txt, that seems easier (because the CMakeList.txt may be made to ignore you CFLAGS / CXXFLAGS).
@ptitSeb: polybar has a bazillion CMakeList.txt in subfolders for all it's different dependencies and modules. I managed to find all those pesky -Werror flags and I am getting past the previous error only to find another problem...

this time it's exiting on a warning being treated as error again, but saying
[  1%] Built target xpp                                                                                                                                                
[  5%] Built target jsoncpp_lib_static                                                                                                                                  
[  5%] Building CXX object lib/i3ipcpp/CMakeFiles/i3ipc++.dir/src/ipc.cpp.o                                                                                            
In file included from /media/pandora/pandora/code/polybar/lib/i3ipcpp/src/ipc.cpp:9:0:
/media/pandora/pandora/code/polybar/lib/i3ipcpp/include/i3ipc++/ipc-util.hpp:147:57: error: dynamic exception specifications are deprecated in C++11 [-Werror=deprecate ]                                                                                                                                                                      
 std::shared_ptr<buf_t>   i3_recv(const int32_t  sockfd) throw (invalid_header_error, eof_error);
In file included from /media/pandora/pandora/code/polybar/lib/i3ipcpp/src/ipc.cpp:9:0:
/media/pandora/pandora/code/polybar/lib/i3ipcpp/include/i3ipc++/ipc-util.hpp:163:131: error: dynamic exception specifications are deprecated in C++11 [-Werror=deprecated]
 std::shared_ptr<buf_t>  i3_msg(const int32_t  sockfd, const ClientMessageType  type, const std::string&  payload = std::string()) throw (invalid_header_error, eof_error);                          

cc1plus: all warnings being treated as errors                                                                                                                          
lib/i3ipcpp/CMakeFiles/i3ipc++.dir/build.make:62: recipe for target 'lib/i3ipcpp/CMakeFiles/i3ipc++.dir/src/ipc.cpp.o' failed                                          
make[2]: *** [lib/i3ipcpp/CMakeFiles/i3ipc++.dir/src/ipc.cpp.o] Error 1                                                                                                
CMakeFiles/Makefile2:441: recipe for target 'lib/i3ipcpp/CMakeFiles/i3ipc++.dir/all' failed                                                                            
make[1]: *** [lib/i3ipcpp/CMakeFiles/i3ipc++.dir/all] Error 2                                                                                                          
Makefile:127: recipe for target 'all' failed                                                                                                                            
make: *** [all] Error 2
[doublepost=1499703675,1499701779][/doublepost]can't figure this one out. not a warning, but an actual error it seems. There is an issue with this error on the polybar github but it's closed. People there were able to build polybar with clang as a workaround, but that won't be an option for me with codeblocks I guess.
@ptitSeb thank you very much! really appreciate all your help. Though I wish I was experienced enough to solve these issues myself...
Unfortunatly, polybar doesn't build with gcc 7.1, look:

So, even if the -Werror can be removed, it will fail later for now (and only existing workaround is to use clang...)
I used this diff to avoid the -Werror, but not sure it's effective...
diff --git a/cmake/01-core.cmake b/cmake/01-core.cmake
index 67ed81b..34799a1 100644
--- a/cmake/01-core.cmake
+++ b/cmake/01-core.cmake
@@ -19,12 +19,12 @@ endif()

 # Compiler flags
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic")
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic-errors")
+#set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic")
+#set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic-errors")

   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-error=parentheses-equality")
Also, you need the "-fno-single-precision-constant" flag to you CXXFLAGS or you'll have some other errors.
@ptitSeb yes that is the issue I was mentioning above. Could it possibly be built with an older codeblocks pnd and older gcc version?
Have you considered using i3blocks to configure i3bar so it fits your needs better? I just compiled/installed it with zero issues and it only depends on libc.
[doublepost=1499836566,1499834081][/doublepost]Also, to migrate my modifier to the right shoulder, I have begun modifying my i3 config to replace Mod1 with Control at places that I feel it is appropriate. It makes things much simpler than messing with xmodmap. I am just trying to avoid running into shortcuts that are already commonly used by existing programs. (for example, mapping mod+w for tabbed mode directly to control doesn't make sense, as control+w is already commonly used)
Could it be that some part of SuperZaxxon overrides the LD_LIBRARY_PATH? I wonder why the commands work from a terminal after setting the library path in .bashrc but still can't use the env variable when they are executed by i3. I could just clobber all old libraries in /usr/lib instead of using a subfolder but I am sure that would ruin the system. What else could I try?

LD_LIBRARY_PATH is dropped whenever a suid executable is started. IIRC (to lazy to go checking) on the Pandora /bin/sh (being linked to busybox) is suid. If that is the cause, one solution is to copy busybox, remove the suid bit from the copy and link that to /bin/sh.