Hiding the checkbox of a QListWidgetItem

Just something I figured out how to do, and it’s not in the top Google results:

The items in a QListWidget can be user-checkable, though by default they are not: QListWidget doesn’t display a (checked or unchecked) check box for a given item unless you set its check state to any value.

Once you set a check status, it’s seemingly impossible to remove the checkbox, even if you un-check it or use QListWidgetItem::setFlags() to remove the Qt::ItemIsUserCheckable flag.

The trick is to use QListWidgetItem::setData() to set the data in the Qt::CheckStateRole to an empty QVariant(). The same method can be used to set the item’s check state.

Unfortunately, this doesn’t preserve the check state, which is the reason why I investigated hiding the checkbox (I hoped that the state can be preserved while the box is hidden). Now I’ll probably store the original check state as user data.

Bloody Bazaar

I just had a version control scare: I managed to wipe out last week’s commits from a local branch of mine (and perhaps in the corresponding global branch). I managed to restore them from the backup files (*.~1~) created either by Bazaar or by Qt Creator. Whoever is responsible for that feature has a major “thank you” from me.

Note to self: for a given branch, either keep it bound all the time, or don’t bind it at all. Also, “revert to revision” in Bazaar Explorer’s log screen doesn’t do what you thought it did.

I’ve decided to have somewhat complete version of the Telescope Control plug-in merged in trunk before Stellarum’s 0.12 release. At the very least it should implement some basic ASCOM support, at the level now offered by StellariumScope. I’m almost done with that. INDI support will have to wait, as it is not usable yet. While the current INDI client seems to work, it lacks polish. It alos seems that parsing the INDI streams should be done in a separate thread, which means another re-write.

Relieving the load

Imagine that you are a Stellarium developer. You are working on a computer (or more precisely, on an OS) that is so slow that rebuilding Stellarium takes a long time even after small changes. Most of your changes are limited to a single plug-in and you are working on a dedicated Bazaar branch. You notice that you are wasting a lot of time even linking the Stellarium executable. What do you do?

You re-run CMake with command line options like the following:
-DUSE_PLUGIN_ANGLEMEASURE=0 -DUSE_PLUGIN_COMPASSMARKS=0 -DUSE_PLUGIN_EXOPLANETS=0 -DUSE_PLUGIN_OBSERVABILITY=0 -DUSE_PLUGIN_OCULARS=0 -DUSE_PLUGIN_PULSARS=0 -DUSE_PLUGIN_QUASARS=0 -DUSE_PLUGIN_RENDERERSTATISTICS=0 -DUSE_PLUGIN_SATELLITES=0 -DUSE_PLUGIN_SOLARSYSTEMEDITOR=0 -DUSE_PLUGIN_SUPERNOVAE=0 -DUSE_PLUGIN_TEXTUSERINTERFACE=0 -DUSE_PLUGIN_TIMEZONECONFIGURATION=0

Guessing on which plug-in I’m working at the moment is left as an exercise for the reader.

P.S. The first rebuild after this change will include a rebuild of the whole StelGui library, as static plug-ins are linked against it.

Cargo cult programming

A simple utility function suddenly becomes not so simple:

QString radToDmsStr(double angle, bool decimal, bool useD)
{
// ...
	int width;
	if (decimal)
	{
		os << qSetRealNumberPrecision(1);
		width = 4;
	}
	else
	{
		os << qSetRealNumberPrecision(0);
		width = 2;
	}
	os << fixed << qSetFieldWidth(width) << qSetPadChar('0');
	if (s<=0.1)
		os << QString("%1").arg(s, 0, 'f', 2);
	else
		os << s;
// ...
}

There are a few problems with that code. Can you spot them? If you don’t know any Qt, you probably can’t, but they are there. It’s not exactly material for the DailyWTF, but it’s still annoying enough to make me write this. An appropriate alternative title would be “RTFM!”.

The more obvious problem is the use of QString::arg() to display a formatted floating-point value in a text stream that otherwise uses only stream manipulators to do the same.

The less obvious, but more idiotic problem is in the last argument of the arg(). Adding it was the reason why arg() was used. What does it do? It sets the floating point number precision, i.e. number of digits after the decimal sign. Which has already been done with qSetRealNumberPrecision() a few lines above – someone had made the effort to set a custom precision with a parameter of the function. But if the value is less than 0.1, the precision happily gets overwritten…

Now excuse me, I have to go waste my time finding out what was the point of the original distinction and why the new change was made. Actually, no, I won’t. I don’t get paid for this. I had to spend two hours today listening to someone babbling platitudes about software project management and quality assurance, all in the name of making progress in my education. If I want to make sure that those two hours were not wasted, I should be studying right now, not venting on this blog or debugging someone else’s mistakes.

Stellarium and the Homeland Security cottage industrialists

To quote myself from before: I occasionally search for Stellarium in Google when I’m bored. It’s a good way to find out what good (or bad) things software reviewers are saying about Stellarium (and sometimes about me). It’s also a good way to catch bugs that haven’t been reported to Stellarium’s bug tracker.

Some of the stuff I come upon during these vanity searches is rather amusing, though. This time, it is a comment to a blog story about the two teenagers being denied entry into the US because of Twitter jokes. The part concerning Stellarium:

(…) And I think the real bad guys are ROFLMAO’ing right now. I think they no longer use channels that can be intercepted, no longer use patterns of association that can be flagged, stay clear of surveillance satellites and (maybe) even drones… So they basically nullify all the vastly expensive apparatus employed by the US in lieu of real intelligence (which was very embarrassingly highlighted by wikileaks – is this the best you can do, really?) An example of this is Stellarium – go ahead and use the add-ins that track satellites and asteroids, see what happens to your computer as the Homeland Security cottage industrialists (ineptly) borks your computer. All this does is ruin a great FOSS program for everyone and drive the baddies into using other tools… (…)

(spelling and formatting preserved from the original)

The same author shortly followed with:

And what seems to have happened to Stellarium is shameful.

Unfortunately, that website requires registration to comment, otherwise I would have jumped at the opportunity to procrastinate a little more and ask “what seems to have happened to Stellarium”. Am I misreading something, or this person really thinks that Homeland Security “borked” the Satellites plug-in so that terrorists couldn’t use it to dodge spy satellites? O_o

I suspect that the paranoid commenter encountered bug #894752, which causes Stellarium to freeze when the user turns on satellite hints (a spent rocket stage that decayed from orbit causes an endless loop). A workaround of the problem is described in a forum post. The other option is to wait for the next release of Stellarium or to download a test build from Stellarium’s download page at Launchpad. The test build also finally introduces a convenient way for adding new satellites from the update lists.

Stellarium’s Satellites plug-in: Some gain, some lose

I am supposed to be doing anything but programming. Instead, today I spent most of my time writing code for Stellarium. I lose.

When I’m working on Stellarium, I am also supposed to be working on the Device Control plug-in (the descendent of the Telescope Control plug-in), and in particular, on re-writing its INDI client. Instead, today I spent most of my time writing a simple GUI for adding satellites in the Satellite plug-in. Telescope users lose. Satellite lovers gain. Well, after my branch is merged with the trunk. The merge proposal is here:
https://code.launchpad.net/~daggerstab/stellarium/satellites-import-gui/+merge/87865

This morning I though that I can finish the basic part for two hours. It took me more than ten. Of course, one of the reasons is that I’m working on a netbook and operations such as compilation, version control and code comparison are slow. I also had to study other people’s code and re-factor some of it. Nevertheless… It’s still ten hours of my life that I’m not getting back.

Anyway, I have some ideas for improving the way the Satellites plug-in handles its updates. Both require adding a checkbox to the configuration window and some code in the update function:

• An option for automatic removing the satellites that are no longer in the update lists during an update.
• An option for automatic adding of the new satellites in a given source file (in particular, CelesTrak’s “last month’s launches” file).

The combination of the two will allow the users to have a constantly updated snapshot of the currently active satellites. I’m going to leave the implementation to someone else, though. I’ve had enough of Stellarium for now.

What I (should) have been working on: new interface for Oculars

Stellarium’s Oculars plug-in have been plagued with interface problems almost since its creation. Originally it was controlled with hard-coded key combinations, but the default ones were not easily accessible on keyboard layouts different from the default US QWERTY one and users complained. Then the plug-in’s author, Timothy Reaves, decided to add an option to change the combinations by entering the new ones by hand. This was somewhat awkward and users complained. Then he decided to use as few key combinations as possible and added a drop-down menu instead. Again, this was not very user-friendly and users have been complaining.

So I decided to look into the ways a plug-in can add controls on the screen – like the button bars in the lower left side of the screen. The result looks like this:

Before, there was a field in the upper right corner of the screen that displayed information about the current telescope/eyepiece. Now in its place is a control panel that allows cycling through the telescopes, eyepieces and sensors by clicking buttons. When the ocular view or sensor frame overlay is not active, the panel retracts, showing only the large buttons at the bottom.

There are several things that need to be done to finish the redesign of the interface, but I haven’t worked on it properly for the last few weeks. Even after the new interface is completed, it won’t help much Stellarium’s problems with the limited options for user interactions available to plug-ins.

The code is here:

https://code.launchpad.net/~daggerstab/stellarium/plugins-gui-improvement

Did I mention that this was supposed to be quick project before I continued my work on other stuff, such as telescope control? I’ve been sitting on some ASCOM and INDI code for long enough to forget what needs to be done with it.