D14813: Adding XPlanet Viewer adds this option... as string?! if it's a number, then just use the proper type, i.e. Int.

Also, what is the use case to make this configurable? Why should users change/edit it?
Ideally, kstars should just use a proper timeout on its own, possibly doing some estimation based on the data provided to xplanet (i.e. wait more if requesting a bigger image).

This is synchronous, and ugly.

Instead, use the signal of QFutureWatcher to know when it finishes. To implement a timeout, use a separate QTimer, to start when starting the computation, and stop when the future finishes -- if the timer fires, then cancel the future.

fd is leaked. Most probably you want to set it for the QFile object? (see QFile::open() that takes a fd.

No need to have it as class member, just move it to the cpp file.

As noted previously, Requires Maps --> requires maps

Also at least on Linux, there is xplanet-images package, is there more to it than that?

Yes, you are correct, it should be int.

I think it is important to make it configurable because I have found that xplanet can take anywhere from a few milliseconds to several seconds to complete. The time is not just dependent on the image size, a lot of it is due to the complexity of a rendering. Jupiter is often very quickly rendered, except when it has a transit of one of its moons, then xplanet takes significantly longer to complete. And we don't know when such events will occur in KStars currently. The other issue would be computers, some computers could take longer to render complex images. I think the user should be allowed to set the timeout based on personal preference. They might want to give a complicated conjunction or transit time to render. Or they might want it to stop before it spends too long trying to calculate a complicated one because it slows down their animation.

True, that would probably be better

Yeah, I wasn't sure what to do with that. It was the way it was in server manager.cpp in KStars. I can re-examine it.

Yes, the user can put any map they want to into this directory. The xplanet-images package you mention is really not adequate. It doesn't include most of the planets let alone the moons. I provided a link to the maps recommended by xplanet. For the MacOS version, I download the ones from from that page under flat planet and include the distributable planet images. The package is called alien. But they are not necessarily the best ones, just the ones I liked. You can install any you like.

Nope, I just went back and checked. fd here is not a leaked object, it is simply an int, the return value of a computation. It isn't the file or the filename. If it is 0, that means the command succeeded and -1 means it failed.

Except that I used the enum values in a couple of places, particularly for Earth.

uint32_t timeout

const QString &

We better start using m_VariableName convention with everything initialized in header. e.g.

int m_CurrentObjectIndex { 0 };
int m_CurrentOriginIndex { 0 };
...
...
uint32_t m_Radius { 0 }
double m_FOV { 0 }

I am moving slowly to this convention in other files.

int objectIndex

No it's not possible.

How do you make them look like icon buttons and not just some button with a pixmap on it?

The lines you highlighted are not dead code. I just tried commenting them out to make sure. They are centering the drawing of the planet image in the view. No, they aren't resizing it, as you stated that is already handled in resizeEvent, they are repositioning it.

Yes that is true now that I changed the header file to set it to zero.

The time that xplanet takes to complete a rendering is not predictable because it depends on the positioning of moons, shadows, maps, and many other variables other than size. It will take a different amount of time on different machines too. But we can't make the timeout a really long time because then the user would have to wait for it to finish. The user might want to wait for a complicated render to finish or maybe they don't and just want to get on to the next frame.

Nice feature, didn't know about it

I do not believe so. XPlanet requires its date and time to be in a numerical format with a very specific structure. Here is a comparison of what the Date/Time looks like with the toString method and with the above code. There may be a way to get KStarsDateTime to do this, but the toString method does not.

Using toString: "Tue Aug 21 18:16:05 2018 GMT"
Using current code: "20180821.181605"

I just tried to implement this. The code was much longer because I had to add a bunch of lines to give it the same functionality as the static method, but perhaps its better that way I don't know.

ok

Gotcha, I got carried away when making the change Jasem requested

Oh didn't see the first part of the comment.

That does look like ISO 8601. You can format code to ISO 8601 (Qt supports that format) then remove all dashes (-) and colons (:) and replace T with .