Change content width in WordPress Twenty Fourteen Theme

by | Jan 22, 2014 | Coding

Well obviously WordPress Twenty Fourteen got an issue: It’s was made for tablets and it’s primary width is 1260px – which obviously makes the content width 654px. That is a mess when you want to present log output and code to the reader.

I generally dislike hacking stylesheets, even if the default style.css is very well documented. The problem is that you ain’t gonna get it for free with a single entry, but must adopt plenty of them.

After installing this nifty plugin in order to overwrite various styles (the child theme idea just sucks), my attention was caught by this blog post.

I’ve modified it a bit, and set the following entries

  • site and site-header max-width are set to 1420px
  • all context is set to 1024px (present everything to the reader)
  • content area (hentry) is set to 768px

 

.site {
	max-width: 1420px;
}

.site-header {
	max-width: 1420px;
}

.hentry {
	max-width: 786px;
}

.site-content .entry-header,
.site-content .entry-content,
.site-content .entry-summary,
.site-content .entry-meta,
.page-content {
	max-width: 1024px;
}

.post-navigation,
.image-navigation {
	max-width: 1024px;
}

.archive-header,
.page-header {
	max-width: 1024px;
}

.contributor-info {
	max-width: 1024px;
}

.comments-area {
	max-width: 1024px;
}

.site-main .mu_register,
.widecolumn > h2,
.widecolumn > form {
	max-width: 1024px;
}

cmake build variables

by | Dec 27, 2013 | Coding

These build aliases are only handy for myself, and I’m pretty aware of what I’m doing (at least most of the time 😉 ).

Note: Use ‘-DCMAKE_CXX_FLAGS=-Wall’ to add additional compiler warnings.

$ cat ~/.bashrc

# icinga 2
export CMAKE_OPTS_DEBUG="-DCMAKE_CXX_FLAGS=-Wall -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_BUILD_TYPE=Debug -DICINGA2_USER=icinga -DICINGA2_GROUP=icinga -DICINGA2_COMMAND_USER=icinga -DICINGA2_COMMAND_GROUP=icingacmd"
export CMAKE_OPTS_NORMAL="-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_BUILD_TYPE=RelWithDebInfo -DICINGA2_USER=icinga -DICINGA2_GROUP=icinga -DICINGA2_COMMAND_USER=icinga -DICINGA2_COMMAND_GROUP=icingacmd"

alias icinga2_debug='rm -rf debug ; mkdir debug ; cd debug ; cmake $CMAKE_OPTS_DEBUG .. ; sudo make -j4 install ; cd ..'
alias icinga2_normal='rm -rf release ; mkdir release ; cd release ; cmake $CMAKE_OPTS_NORMAL .. ; sudo make -j4 install ; cd ..'

For builds without cmake runs, it’s tremendously easy with make too

$ sudo make -j8 install -C debug/

Error: passing xxx as this argument of yyy discards qualifiers

by | Dec 27, 2013 | Coding

Lession learnt when calling a non-const function on a const object. The example below happened whilst refactoring the Icinga 2 Livestatus component code, and it took me a while to figure out its meaning.

/home/michi/coding/icinga/icinga2/components/livestatus/logtable.cpp:365:37: error: passing ‘const icinga::String’ as ‘this’ argument of ‘bool icinga::String::Contains(const string&)’ discards qualifiers [-fpermissive]
  else if (type.Contains("HOST ALERT")) {

‘type’ is a const reference of the Icinga 2 String class.

Dictionary::Ptr LogTable::GetLogEntryAttributes(const String& type, const String& options)
{
...
	if (type.Contains("HOST ALERT")) {

‘Contains’ is a function member of the String class.

bool String::Contains(const String& str)
{
	return boost::algorithm::contains(m_Data, str);
}

By calling the non-const method ‘Contains’ on a const object ‘type’ the compiler requires the method not to modify the object in any way. Therefore the ‘Contains’ function of the String class requires the const qualifier.

bool String::Contains(const String& str) const
{
	return boost::algorithm::contains(m_Data, str);
}