Now you can also find my poorly thought-out code on Github:
The only project there so far is a work in progress: a plug-in that will allow controlling Stellarium with a joystick or gamepad instead of a mouse. (Of course, you’ll still need a keyboard if you want to use all the hotkeys, unless you have one of those exotic gamepads with a full QWERTY keyboard.)
Since it introduces an external dependency (on SDL, for multi-platform joystick support), I’ve decided to implement it as a dynamic plug-in distributed separately from Stellarium. As a side effect, this may result in changes that will make dynamic plug-in development easier, such as creating a “development package” for Stellarium (a “stellarium-dev” for those familiar with Unix naming schemes).
Since this adds more to my already well-padded Stellarium work list, don’t expect miracles. After the initial enthusiasm abates, I’ll treat it as a task to turn to when I get stuck somewhere else. (On a second thought, I treat all my Stellarium tasks that way, so it won’t be an exception.)
One can find interesting things in their Inbox when they bother to check their e-mail. Such as the Canada-France-Hawaii Telescope (CFHT) on Mauna Kea.
I’m supposed to be working on Stellarium’s time zone support. The only work so far is on what I should have left for the end: the GUI.
I need to cram somehow three radio buttons, a spin box, a drop-down list and the label that describes the whole group in the existing window, while keeping it simple. The best I could come up with so far:
One of the advantages of putting the name field at the top is that it puts it at the top of the tab order, solving some of the problems we had (and still have) with changing focus when certain controls are disabled. The internal logic of the window will also have to be overhauled anyway, though.
I’m back home. I was hoping that I can use my limited free time to work on Stellarium, but I’m getting severely unpleasant feelings even thinking of all the stuff I’ll have to do. Burn out? Or I just need some rest?
Rest is probably a good idea anyway.
…is mostly ready for a merge, though I couldn’t finish everything I wanted to do before running out of free time at the end of April. I wanted to propose the merge today, but I’m too sleep-deprived to do the necessary writeup and cleanup, so I’ll leave it for tomorrow. It’s eating from my study time, but don’t worry, you’ll have your improved Satellites on the next release.
The code and a list of work done (and work unfinished) is here:
After the introduction of ΔT computations to Stellarium, there has been a sequence of bugs “fixed” like this. In other words, some piece of code needs the time, uses the ΔT corrected time, then subtracts the correction, because it doesn’t need it. (Do I need to spell out the obvious solution?)
This pattern has repeated at least three times by now. It is one of the reasons I’m often wondering why I’m still involved with this project.
(Oh, and if I see another incomplete URL in the commit message instead of a bug report or a proper explanation… :evil:)
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.
Posted in Programming, Qt