Look here, if you are interested.
Given that the KF5 based Kate works OK on Windows, I would like to get the Mac version up and running, too.
As virtualization of MacOS X is kind of “forbidden” and not that nicely usable anyway, as no nice accelerating drivers are available for the standard vm solutions, I just went out into the world and bought some Retina MacBook.
I followed the nice guide on https://github.com/haraldF/homebrew-kf5 (thanks Harald :=) and got some installed Kate/KWrite (after patching kio to skip X11 detection).
But ok, not that usable, at least without any investigation which env vars are missing per default you get a Kate that crashs or just shows the main window central content without any actions/menus/toolbars/sidebars/…
In addition, the application is scaled, as the manifest that tells we are able to handle retina bla stuff is missing.
Guess lots of work ahead, but given I have now some Mac, I will work on that in the following months 😉
P.S. I never had a Mac before and got often told by “Mac Fans” that I should switch to some “real” operating system from my stupid borked unusable cluttered hacky … Linux. Given that the new shiny MacBook directly stalled for ever during the guided “create your user and give us all your data” installation wizard on first boot, I am not that impressed ;=) My mother would have been stuck and after some googling that seems to be a “known issue”, at least for me, after a hard reboot, the thingy worked and I had a login, more luck than others 😛
For my job, I need to take care of the support of old Linux distributions for our products, therefore I experimented in building Qt 5.x for Red Hat Enterprise 5 (or CentOS 5 or other clones).
Whereas Red Hat Enterprise 6 works more or less out of the box, to build Qt (even with WebKit and Co.) on Red Hat Enterprise 5, more work is needed. Even the xcb library is not yet existent there.
Therefore, here a small howto, for other people having problems with building it. It contains some hacks and any input is for sure nice to have as an comment (to help others to avoid my faults).
Disclaimer: I am not responsible for creating a completely messy and buggy Qt 5.x build :=)
First, lets assume you have some CentOS 5.11 box or chroot.
You will need some new development toolsets to get rolling:
wget http://people.centos.org/tru/devtools-1.1/devtools-1.1.repo -O /etc/yum.repos.d/devtools-1.1.repo
wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
I tend to use the version 2, version 1.1 does work, too (GCC 4.7.2 vs. 4.8.2).
We will needed EPEL, for a more up-to-date python (2.6, for xcb):
rpm -i epel-release-5-4.noarch.rpm
Then, lets install the minimal deps (I install both toolsets, you can choose one):
yum install devtoolset-1.1 devtoolset-2 python26 fontconfig-devel libX11-devel libXau-devel libXext-devel libXrender-devel
Then, get some compile shell ready:
scl enable devtoolset-2 bash
I will just for excercise build Qt and stuff into /tmp/usr/(qt)?
To build Qt, you need libxcb, get that (with deps):
# package config for xcb stuff
# xcb proto
tar -xzf xcb-proto-1.11.tar.gz
# pthread stubs
tar -xzf libpthread-stubs-0.3.tar.gz
tar -xzf libxcb-1.11.tar.gz
Now we are ready to build Qt 5.4, at least some parts ;=)
I skip here the GL stuff, I don’t need it and I skip some other modules.
# unpack qt
tar -xzf qt-everywhere-opensource-src-5.4.0.tar.gz
# no perf events => patch that out, won’t compile, at least not for me because of missing syscall/broken kernel header
sed -i “s/#define QTESTLIB_USE_PERF_EVENTS/#undef QTESTLIB_USE_PERF_EVENTS/g” qtbase/src/testlib/qbenchmark_p.h
# configure with some defines to work on centos 5 (fake some defines)
./configure -R ‘\\\$$ORIGIN’ -D _X_INLINE=inline -D XK_dead_currency=0xfe6f -D XK_ISO_Level5_Lock=0xfe13 -D FC_WEIGHT_EXTRABLACK=215 -D FC_WEIGHT_ULTRABLACK=FC_WEIGHT_EXTRABLACK -v -opensource -confirm-license -sysconfdir /etc/xdg -prefix /tmp/usr/qt -release -shared -qt-zlib -qt-libpng -qt-libjpeg -qt-pcre -qt-xcb -qt-xkbcommon -xkb-config-root /usr/share/X11/xkb -no-xcb-xlib -c++11 -nomake examples -nomake tests -no-dbus -no-icu -no-opengl -skip activeqt -skip androidextras -skip connectivity -skip enginio -skip location -skip macextras -skip multimedia -skip quick1 -skip sensors -skip serialport -skip wayland -skip webchannel -skip webengine -skip webkit -skip webkit-examples -skip websockets -skip winextras -skip x11extras
# build and install
=> You have some Qt, but keep in mind you need to bundle at least the libxcb.so* library, as your Red Hat Enterprise 5.x guys won’t have it!
Recently, there were some thoughts on where KDE is going, and related to that what’s the driving force behind it in terms of the pillars of KDE. Albeit it is true our development model changed significantly, I’m not convinced that it’s all about git.
No, I rather believe that it is the excitement about the KDE that makes it stand out – KDE as a community if you wish, but also KDE as a software project.
Going back to the late nineties, I was developing small games for DOS (Turpo Pascal, anyone? Snake and Gorillas in QBasic? 🙂 ) and also for Windows. At around that time, Linux got also a bit more popular so that I finally had a SuSE 6.0 in my hands. I installed it and was able to run KDE 2, iirc (?). It certainly was interesting, but then I also wasn’t involved in any free software projects, so it also wasn’t that a big deal.
Still, I started to look into how to develop GUI applications for Linux. Since under Windows I used MFC (oh well, now it’s out, but you know, I quickly got back on the right track) I found Qt quite nice (for CPoint you had QPoint, for CDialog a QDialog, and so on). As I used KDE in Linux, I started to change small things like an Emoticon preview in Kopete (one of my first contributions?), or some wizards for KDevelop in 2003. These were projects that were fairly easy to compile and run. Still, what might seem so little was a huge success for the following reason:
More or less still being child, getting in touch with C++, KDE, and all the tools around it was completely new. CVS? Never heard about it before, and anyways, what was a version control system? How it worked with the mailing lists. With entering a bug. Compiling kdelibs: It took me more than 2 weeks to succeed (Which btw. to myself proves that even at that time it was really hard for a newbe to compile KDE, just like today). All in all, these were times where I learned a lot. I started to read the cvs-commit mailing list (around 400 mails a day, I read them almost all, more than 5 years long).
But that was not yet it. It continued like that for years. For instance, understanding how KIO slaves worked was just amazing. How all KDE components integrate into and interact with each other. There were a lot of parts where KDE was simply the best in terms of the software technology it provided and created.
To me, this was KDE at its best.
In my opinion, KDE followed this route for a long time, also with KDE4. I even say KDE still follows this way today.
But it’s much harder to get excited about it. Why? Think of yourself as seeing snow for the first time. It’s just awesome, you’re excited and can’t believe how awesome this is. Or maybe also New Years eve with nicely looking fireworks coming. It’s something you simply can’t wait for enough. Kind of like a small child… This is the excitement KDE raised in lots of us. Getting a new KDE release was totally something I wanted. I saw the improvements everywhere. What also helped a lot was the detailed commit digest Derek Kite worked on so hard each week, showing what was going on even with detailed discussions and screenshots (today the KDE commit digest is mostly an auto-generated list of commits, which I already have through the KDE commit filter).
Today, I know all the details. All the KDE technology. Of course, it got even better over time, and certainly still is an immensely powerful technology. But I’m not that much excited about it anymore.
I believe this in itself is not an issue. For exactly this reason, developers come and go, leaving room for other developers to implement their ideas. It helps the project to stay young and agile.
It is often said, the KDE has grown up. This is certainly a good thing for instance in terms of the KDE e.V. supporting the KDE project as much as possible, or the KDE Free Qt Foundation that helps us to make sure Qt will always be freely available to us, or a strong background in legal issues.
At the same time, it is a very bad thing in terms of getting people excited about KDE. We need developers with freaky ideas who just sit down and implement new features (btw., this is very much true for all free software projects). For instance, why has no one come up with a better KXmlGui concept? I’m sure it can be done better!
Where does that put us? Is there really no cool stuff in KDE?
Well, the reason for this post is to show that we did not loose what once was cool. In fact, we see it every day. For instance, yesterday I was using Dolphin and had to change a lot between subfolders in the same level (e.g. from some_folder/foo to some_folder/bar and so on). I accidentally used the mouse wheel over “foo”, and whohooo! You can switch to the next folder just by scrolling with the mouse wheel over the navigation bar. This is immensely useful, and in fact, this is why KDE shines also today, it’s just not so visible to users and maybe also to developers. You now may say that it’s just some little detail. But this is exactly it: Yesterday I was totally amazed by how cool this is, just like 10 years back from now… Therefore, I say, this still is
KDE at its very Best!
Getting people excited about KDE is what defines KDE’s future, not git.
Edit (imho): I would like to add something here. When reading these kind of blogs, you may get the impression that KDE is getting a less and less attractive platform, or that KDE is kind of dying. This is absolutely not the case. Quite contrary: With KDE’s foundation libraries, and applications being about to released on top of the KDE Frameworks 5 libraries, KDE can certainly make the statement that the project and its software will definitely be available and certainly just as strong in 10 years from now. I have absolutely no doubt that you can count on that. And that is a really cool thing only few free software projects can claim! Let’s talk about it again in 2024 🙂
PS: On a unrelated note, KDE currently runs the End of Year 2014 Fundraiser. Support is very much welcome!