Archive for Geek stuff

Windows 7, round 1

October 15, 2009 · Filed under Declared enemies

Disclaimer: I’m writing the following not as a member of the KDE e.V., but as an individual computer user. As usual, I’m only expressing my very own opinion. Though this should be clear to anyone reading my blog, I’m stating it explicitly now because there have already been more than enough flamewars because of misconceptions and misunderstandings, esp. when it comes to operating system debates.

When Vista had its public beta, I downloaded and installed it on a non-production machine. “Non-production” was a very good idea, because it ate the partition table. I’m not sure how much this has influenced my switch upgrade from XP to Linux some months afterwards. (I was surely also influenced by my first few contacts with Vista, which are very well described by the word “horrible”.)

So I was still running an XP system on my PC at home (mostly for my scanner, which does not work under Linux, and for games that refuse to run under Wine). Eight years after the release of Windows XP, I thought it was time to finally retire XP, and move on to something more stable and secure. (Yes, I know, Linux… but it has to be a Windows for aforementioned reasons. Actually, this machine is a dual-boot with Arch.) So I decided to give Windows 7 a try. Because my university is enrolled in Micro$oft’s MSDNAA program, I could recieve a free copy and license of Windows 7.

I thought that the MSDNAA program was partially meant to attract students from the non-Windows realms to consider the switch. That is, until I wanted to download Windows 7 from their webpage. All I got was “Downloader for Windows 7 RTM.exe” (and the license key). Yuck!

Anyway, let’s see if Wine eats it. Wine wanted to install Gecko, which it uses as a replacement for the Internet Explorer engine that can be used by third-party programs on Windows. Wine crashed. Later I found that the program consists of an Internet Explorer window without interface (think QWebView) that downloads some ActiveX controls (yuck again!) to do the actual downloading. The advantage of this system is that the download can be paused and resumed by simply closing and restarting the program, the disadvantages are about anything else.

Glad am I that I still have a Windows XP installation. This one could execute the Downloader.exe and download Windows 7. I ended up with a 2,4 GB ISO, which I burnt to DVD under Linux. (Windows does not include the necessary tools. Of course.)

Up to now, I’ve already spent three hours of work on an offer that is trying to convince me that Windows is better than Linux. No comment.

Installation of Windows 7 went quite smooth, with the only WTF that it needs to reboot three times, while I have seen Linux distros that install without even a single reboot. I had expected that it would eat my Grub installation in the MBR, but that’s normal (and restored in under three minutes with a Linux live CD.) Actually, I was (for the first time in the process) positively surprised, because Windows did not expose its usual imperialistic behavior when it comes to hard disk partitioning. It showed me a list of all partitions, I selected the Windows XP one, formatted it and clicked “Install”. So far so good.

The desktop showed up in non-native 1024×768 resolution, and with compositing disabled. I’d expected this, because the NVidia video driver is missing. Because my home PC is actually an early 2006 notebook, I expected suitable drivers not to be available, but Dell offered me Vista drivers, which worked very good. On my way, I found another WTF: On the NVidia driver download page, I have to select the exact model of the graphics card, while under Linux one driver serves all. Why can’t Windows be as simple as Linux?

The next possible surprise: The video driver was the only driver I had to install. Under Linux, I expect everything on this notebook to work out of the box, but on Windows, only one missing driver is astonishing. XP required about a dozen driver packages to be installed in a particular order (unless you use the recovery partition, ruin your Linux dual-boot on the way, and get all the nice extra programs that the do-gooders at the notebook manufacturer donate to you; you know what I mean). Another thing which surprised me was Microsoft Paint, which seems to have had its first bigger update since Windows 95.

Of course, something was missing. An open-source browser. An archive reading program. A good text editor. Long story short: KDE was missing. Next surprise: The kdewin-installer has progressed very well (I actually thought that development speed had lowered because of manpower problems). The package list in the simple mode is a bit long because (for some unknown reason) all apps are grouped into module packages, except for kdegames. Also strange: The KDE stuff does not show up in Windows 7’s start menu. I blame this on Windows 7 changing conventions, because this used to work on XP. Adding the bin directory of the KDE installation folder to the $PATH variable solved the problem for me, I’m more used to launching progs with Alt+F2 Win+R than with the start menu.

My conclusion: From my first observations, Windows 7 is definitely the best Windows ever (I won’t judge on how hard it was to achieve this position). However, I do not consider the graphical presentation mature. I mean, I have Aero Glass and such enabled, but to me, Windows 7 feels like a dozen apps, developed in parallel, and combined for the first time only one week before release. There is by far not as much a common style as in KDE.

Okay, there is this glass look all over the place, but the conceptual basis is not much more. The taskbar buttons have nice glow-on-hover effects, everything else doesn’t. The windows have nice compositing effects, the desktop applets don’t. And each of the desktop applets looks, and behaves, different, though there are only nine of them. (Compare this to the dozens of applets shipping with the KDE Software Distribution. And by the way, the desktop applets are not scalable, and of course always too small.)

Using KDE, you do not have to have a widget style that matches your Plasma theme, or suitable color schemes. It’s the behavior and the subtle design elements that make everything feel like a coherent whole. In my opinion, this is absolutely missing from Windows 7, though this should be a key selling point of Windows as a platform. (Many people buy a computer based on the presentation in the computer store, and also based on what friends tell them about their own experience.)

Micro$oft has hundreds of developers working full-time on the user interface, while KDE apps are usually developed by only one or two people at a time, most of them working in their free time as a hobby. Micro$oft has dozens of the best-paid designers in the world, KDE has a handful of mostly freelance artists. Taking all this into account, Windows 7 is a shame for the Microsoft developers, because it’s in my opinion easily surpassed by KDE in terms of polish and design.

The fine print: Just in case someone wants to read this into my post, I am in no way saying that KDE is perfect. I am also not saying that Windows 7 just sucks. (I’ve actually enjoyed using it up to now, esp. when compared to XP and Vista.) What I’m saying is that KDE is far more close to perfection than Windows 7 when it comes to polish, style and taste.

P.S. The rumors about 16 GB installation size of Windows 7 are exaggerated. The Professional edition needs about 9 GB.

Comments (48) »

Say hello to the ModelListModel

October 11, 2009 · Filed under Say hello to...

Preface: In my new series “Say hello to…”, I regularly present you additions to my Git-based collection of useful helper classes and smaller projects (see its very simple homepage for more information).

Yesterday, you saw me debugging models. Today, you see the result: I’ve implemented a model that lists other models.

The ModelListModel in action

The ModelListModel in action

Perhaps you find this useful for your own application (I’ll use it for fantastic new features in Palapeli’s puzzle library). In an ideal world, I would have implemented a yet more generic model, in which one can “mount” other models at arbitrary positions, but from what I know about model/view programming, this is very hard to do right (i.e., without massive memleaks).

Comments (6) »

Debugging models is hard work

October 10, 2009 · Filed under Programming

It’s fifteen minutes till midnight and I’m sitting here and analysing pages of boring debug output. What a life. (At least I chose it freely.)

debugging-models

Some of you might read from this that I’m working on model/view stuff currently. I hope to have visible results tomorrow.

Comments (5) »

Say hello to Utils::SelectionDialog

September 22, 2009 · Filed under Say hello to...

Preface: In my new series “Say hello to…”, I regularly present you additions to my Git-based collection of useful helper classes and smaller projects (see its very simple homepage for more information).

Today, I needed a dialog for Kolf that shows a list view to the user, and lets him select some items from that (plus the “OK/Cancel” buttons which you’re used to from modal dialogs). I had to create a new class, complete with own header and source file, because I needed to declare a new KDialog subclass with a slot.

Incidentally, I’ve already created such dialogs for Palapeli. And much of them. So this is a task that should clearly be simplified. This is how the SelectionDialog class came into life. See the APIDOX in its header for details on how to use it.

Leave a comment »

Say hello to StaticVector!

September 20, 2009 · Filed under Say hello to...

I present you the second addition to my Git-based collection of smaller code pieces (which now also has a very simple homepage).

This time, I show you a generic container class. There is already a big bunch of container classes in Qt, but I had to make one that fits my needs: the StaticVector.

Its API and purpose is similar to QVector, but it behaves quite differently: A StaticVector does never reallocate or resize its data unless it’s explicity told to do so. Also, any copy of a StaticVector will be read-only, because the data is implicitly shared for performance reasons, but write operations would require the copy to detach from the original data (which is an implicit reallocation, which is forbidden).

The usecase for this is quite simple: In Kolf, we are regularly passing big data arrays to OpenGL and ODE. And passing big arrays to methods from C libraries almost always requires one to pass a base pointer and a size, i.e., two parameters. With such data encapsuled into classes (such as QImage), you might end up with a situation like the following:


void passData(uint* data, int size);

class MyContainer
{
QVector m_payload;
public:
QVector payload() const { return m_data; }
//...
};

MyContainer container;
//...
passData(container.payload().data(), container.payload().size());

This is asking for trouble. The two calls to MyContainer::payload() in the last line create two temporary objects. The latter one is not problematic, because QVector::size() is a const method, but QVector::data() is a non-const method (because the C library wants a modifiable pointer). Calling it causes this temporary QVector instance to detach from the original payload, i.e., allocate new memory and copy the data to there. The C library will remember the pointer to this newly allocated data. After the passData method call, the temporary QVector instances are deleted, which causes the newly allocated data to be deallocated. When the C library tries to access this data later on, we’ll get a SIGSEGV or even uglier things.

That’s where StaticVector comes in. If you substitute QVector with StaticVector in the above example, everything works well, because the temporary StaticVector instances are read-only, but (for this usecase) may return a non-const raw data pointer.

If you ever need to use C libraries which want non-const data pointers, StaticVector might be a good choice for you, because it allows to get this non-const pointer even from const or read-only StaticVector instances, while it minimises misuse of this pointer as much as possible.

Comments (3) »

Say hello to QRangeSelector!

September 12, 2009 · Filed under Say hello to...

As suggested yesterday, I’ve set up a Git repository for “a broad collection of smaller code pieces which I’ve acquired over the course of my life”. Find it at http://github.com/majewsky/majewsky-misc/, and clone it from git://github.com/majewsky/majewsky-misc.git.

As some first entry, I actually put some stuff I’m currently working on. In line with Andreas Marschke writing about his recent work on a generic video widget, I’m announcing QRangeSelector. This class is similar to a normal slider, but it does not only allow to select a single value, but to select a range of values from some bigger range. (One may also, given some big range, select a small range from it, and select a value within this range.) QRangeSelector also allows for arbitrary contents to be drawn inside its slider area. This screenshot illustrates some usecases which I need in Kolf. (If you do not see the benefit yet, I’ll do a screencast once the QRangeSelector is used in Kolf.)

Testcase for QRangeSelector widget

Testcase for QRangeSelector widget

Note: The white widgets at the top and inbetween the two QRangeSelectors are simple line edits. I needed those to test keyboard focus.

Comments (8) »

Anticipation

September 11, 2009 · Filed under Programming

In a programmer’s life, one acquires many smaller code pieces which one might want to share. In my case, I have two sources of smaller code:

  1. In my home directory is a huge directory called “code”. Inside this directory is some directory called “misc”, with other 30 smaller programs (most of them tests for some smaller feature, or a calculation program for some university task).
  2. Esp. during my work on Kolf 2, I’ve written many small utility classes which might also be usable in other situations (most prominently the range selector widget which I’m currently working on).

Over the course of the next days, I’ll select some code from these sources, and make it available publicly in a Git repo under the MIT license (a simplified form of the BSD license and a very liberal and easy-to-use license). Stay tuned.

Comments (3) »

Code documentation is really important

July 27, 2009 · Filed under Kolf, Programming

One of the things I learned about during my continuing involvement in Kolf is the importance of code documentation. All of you will know user documentation (handbooks, tooltips, …), and developers know about API documentation. But developer documentation is also happening on a more abstract level. It doesn’t help if you understand what single functions do, if you do not get the big picture. How do these classes work together? And which class should I use in the code I’m working on?

These questions were exactly the ones I couldn’t answer when I was looking at the source code of Kolf 1. It might have been that I could get into it with enough time and will (it seems doable), but you see: Missing developer documentation raises the entry barrier.

I was enthusiastic to get proper, extensive documentation in Kolf 2. From the start, every class API has been documented (the obligatory lower level of developer documentation). Unfortunately, the high level documentation was going very slowly until last weekend. When I started to refactor some internals, I set the private goal to not proceed with the refactoring until I documented the last part. Currently, I’m working on documentation for the basements of Kolf, which look like this:

Class layout in Kolf 2 (cut-out)

Class layout in Kolf 2 (cut-out)

I would like to encourage every developer out there to write high-level developer documentation, to be sure that work on his code can continue even if he is not available anymore. Writing documentation is also a good opportunity for reflections on the class layout and the semantics of the classes.

P.S. You might’ve noticed that above graphics uses TeX fonts. It’s actually written in LaTeX (with PGF/TikZ), the sources are in SVN at trunk/playground/games/kolf-ng/doc (view in WebSVN), where the complete documentation is located (see the README for how to compile).

Comments (1) »

Sign this petition!

July 19, 2009 · Filed under Geek stuff

This is for all German citizens out there: Please sign this petition on the Bundestag webpage. I want the Bundestag plasmoid on my desktop!

Comments (3) »

Shutdown your machine automatically (or from remote)

July 11, 2009 · Filed under The command line and I

I was wondering whether it is possible to shutdown a KDE 4 session programmatically. The obvious solution is “sudo shutdown -h now”, but this requires me to enter my root password. The manpage shutdown(8) mentions a file /etc/shutdown.allow which could define users allowed to shutdown the machine, but this does not seem to work. (I put myself into that file, and shutdown keeps telling me that I must be root to do that.)

That was too much of a hassle for me, so I looked for a KDE-ish solution to the problem. And whenever you need to access KDE functionality from the command line, DBus is your friend. I quickly found on the session bus the org.kde.ksmserver service, which contains no shutdown() method, but a logout() method. Technically, both things are fairly similar, so let’s look into this method: Okay, it takes three int parameters. What would MacGyver do now?

I eventually found what these parameters are. Reading the code of KSMServer and the KWorkspace library, the three parameters are values from the enumerations KWorkspace::ShutdownConfirm, KWorkspace::ShutdownType, KWorkspace::ShutdownMode (in that particular order). The possible values for these enumerations can be found in the API documentation for KWorkspace. For example, to shutdown your machine from the command line, say:


$ qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout 0 2 2

The parameters mean that, without confirmation (the 0), the machine should be shut down (the first 2) immediately (the second 2). So if you ever wanted e.g. to shutdown your machine from remote, now you know how to do it. (Perhaps this could be put on one of our wikis, but I’m unsure which one of Techbase and Userbase is the right one, and where to put it there.)

Update 1: Milian Wolff correctly mentioned in the comments that KShutdown simplifies this task very much. I had also used KShutdown in KDE 3, but had forgotten about it because the port was not done when I switched to KDE 4 as my main desktop.

Update 2: A commenter asked for a more detailed guide on how to get to such information. As an example, I’ll show you how to find the command that toggles KWin’s compositing: (I know of Alt-Shift-F12, but one might want to do this in a script)

  1. Call qdbus without parameters to get a list of all registered services. Tthe numerical names such as “:1.42″ can be ignored, as most programs register more readable names such as “org.kde.ksmserver. Some of thesed named services have some numerical suffix, this is the process ID for applications which can have multiple instances at once.
  2. When you’ve found the right service, give its name as the first parameter to qdbus. In this example, you would then invoke “qdbus org.kde.kwin”. qdbus will now print all interfaces in this service. All KDE applications have a “/MainApplication” interface to control the application in a generic name. (This generic interface is used by kquitapp, for instance.)
  3. Pass the name of the right interface (“/KWin” in our case) as the second parameter to qdbus. Now, you’ll see an extensive list of all methods and signals that this interface provides. While signals allow the service to pass information to its clients, methods allow to invoke certain things in the service. In our case, the right method is:

    method Q_NOREPLY void org.kde.KWin.toggleCompositing()
  4. Add the name of the method, which is “org.kde.KWin.toggleCompositing” in the above example, as the third and last parameter to your final qdbus call. If the method in question has arguments (like the above “org.kde.KSMServerInterface.logout” method), give these in the right order as further arguments. (Of course, you have to know what these parameters mean, which was not that apparent in the KSMServer case.)

Comments (11) »

« Previous entries
Next Page »