Celestia Forums

Hi,

Judging by feedback from when I broke the qt build, there seem to be many more people around doing builds than are participating in the dev list discussion (btw it would be nice if people showed up there!). Thought it might be worth pointing out a couple of patches that have been submitted to the dev list for v1.6.1 but haven't yet had any feedback from people testing.

These patches are against the v1.6.1 branch, SVN 5144.

Firstly there is a fix from Nils Larsson for libpng-1.4. Would be good to test this on all Celestia versions.

Secondly I've provided a patch for the KDE version to allow handling of Unicode bookmarks.

(If there's anything else I've missed, e.g. Mac stuff then feel free to add to this thread.)

EDIT: My patch for the KDE version does not fully fix the issue for "Add relative bookmark", I have therefore removed the patch.

3 months ago, I wrote in the dev list that a first 1.6.0 bugfix release (i.e. 1.6.1)
as much as > 1.5 years after the 1.6.0 release makes little sense. I argued that a mere bugfix release 1.6.1 so much later might well be interpreted by many as a rather discrediting sign for lacking Celestia development activity!

Since the 1.6.0 release, many significant changes/new features were actually implemented in the trunk code branch (e.g. Eigenizing, large code reorganizations, universal Qt GUI, [Chris' great new shader stars],......). Therefore I rather suggested that we concentrate instead all our efforts on a first trunk branch release (1.7.0 / 2.0+Qt GUI) as early as possible!

My suggestion to skip the 1.6.1 release was not shared by ChrisL and possibly some other devs....
Although I had triggered off in the dev list the extensive subsequent activities about Linux fixes for modern gcc compilers in the 1.6.1 branch, my enthusiasm for 1.6.1 testing remains somewhat limited for the reasons given.

Meanwhile, another 3 months have passed with barely perceptable dev activity in the trunk branch, and thus my opinion from 3 months ago has surely not changed...

Fridger

On the other hand we've recently got 1.6.1 to a state where it is very nearly able to be released (at least for Linux and Windows - I'm not sure what the current status of the Mac version is: would be nice if ChrisL would come out of lurk mode...)

For people who want to test the latest (Windows) SVN build, you can download it from the link in my signature. It's build 5144.
It has the new star rendering feature built in.

ajtribick wrote:On the other hand we've recently got 1.6.1 to a state where it is very nearly able to be released (at least for Linux and Windows - I'm not sure what the current status of the Mac version is: would be nice if ChrisL would come out of lurk mode...)

Yes, costing another three months in which working on the trunk branch instead, would have met with a lot more enthusiasm at least from my part.

Fridger

--- edit ---

CAP-Team wrote:For people who want to test the latest (Windows) SVN build, you can download it from the link in my signature. It's build 5144.
It has the new star rendering feature built in.

FYI, my test with your build.

1) the shadow's bug reported here persist, so I think is due to the new star rendering, since - by exclusion - your build doesn't has the fade orbits, while I did found it in Guillermo's build with the new stars and the new orbits;

2) I'm unable to render completely transparent the CMODs models, neither the asteroids points as below (in the screen shot, the opacity for the belt is set = 0.003 which is enough to make it invisibles), nor the meshes like the Star Trek Starbase.

john Van Vliet wrote:the only thing that might be missing ( and i do know will get fixed) it the qt4 build not finding the data directory .

I thought we are talking here about the forthcoming 1.6.1 branch release. 1.6.1 does NOT have a Qt GUI. Qt4 is only relevant for the trunk code.

I agree that -- apart from just a few mild issues-- the trunk code is pretty stable and compiles well, including the latest compilers. Altogether, however, there is still plenty of work to be done before the trunk branch would be ready for release.

Fridger

Yeah CAP-Team derailed the thread with the post about Windows trunk builds.

Could we split the trunk stuff out of here?

Regarding the libpng patch, it looks like this has been in trunk for a while now so I've gone and committed it to 1.6.1. Any takers for testing the 1.6.1 KDE patch?

Andrew,

you had previously provided around 4 KDEbookmark patches or so in the dev list, each with some sort of deficiency...Hence I lost contact to what this latest fix of yours was supposed to really cure?

Also I figure that the fix should be applicable as well to the trunk branch? Noone made significant KDE changes since 1.6.0 to the bookmark code, as far as I remember. I do see a bug in the bookmark code of my Celestia.Sci development version (KDE), but it is not related directly to a unicode issue.

For the above-mentioned reasons I am not looking anymore into 1.6.1, but I would be willing to test your patch for the trunk, as soon as you specify precisely what it should cure. Example?

Fridger

Yeap was going to look at it on trunk as well. Technically I posted 3 patches, the last one twice, but I guess everyone was sufficiently bored with my mistakes by that point.

As to what it does, it is intended to fix the handling of Unicode in the KDE version's bookmarks menu... I believe the same problem exists in trunk, try bookmarking an object with a non-ASCII character in the name (e.g. the lunar crater G?rtner).

ajtribick wrote:Yeap was going to look at it on trunk as well. Technically I posted 3 patches, the last one twice, but I guess everyone was sufficiently bored with my mistakes by that point.

As to what it does, it is intended to fix the handling of Unicode in the KDE version's bookmarks menu... I believe the same problem exists in trunk, try bookmarking an object with a non-ASCII character in the name (e.g. the lunar crater G?rtner).

Andrew,

this is about latest trunk r. 9145. Used a fresh checkout and a fresh installation as always in tests.

Well in my case of (trunk) celestia-kde the Moon has been "special" since a long time: While always located at the right position, it is sometimes not rendered, unlike I rotate it to a particular position (depending on the amount of zoom). This bug in the KDE version I notice since a long time (years!) and have brought it up also in the dev list previously. Since few KDE3-competent people seem to be using KDE since Christophe Teyssier has left, there were no clearcut reactions reported. It is not excluded either that the effect is due to a nasty persistent KDE bug (I always use the latest CVS versions of KDE3). In celestia-gtk and celestia-qt I don't see this bug. Moreover, the moon is the only object where this "magic" effect occurs.

So testing with the G?rtner crater didn't work for me

Instead I used towns from my 40000+ earth-Gazetteer-intl.ssc locations file on Earth that contain plenty of cities with non-ascii characters. Of course, for bookmarking locations one has to use "relative bookmarks" in the bookmark menue. Moreover, I bookmarked stars like ? And. In both cases I don't seem to need your above patch. Things relocate and display fine if the relative bookmark entry is clicked on the selected Earth.

So again, what does your patch correct for in these Unicode related bookmarks?

Fridger

Sorry I have never ever experienced the problem you are seeing with the Moon in the KDE version. I have absolutely no idea what you are talking about here. I guess just as you dismiss my problems with Unicode bookmarks as a non-existent issue, I should dismiss your problems with the moon as similarly non-existent

Nor am I using your world capitals add-on.

Maybe this is a localisation issue, however I switched my system to de_DE.utf8 and saw no change of behaviour.

Nevertheless I can reliably reproduce the KDE bookmarks problem on Ubuntu as follows:

Open a new installation of Celestia 1.6.1 (having previously remembered to delete the ~/.kde/share/apps/celestia preferences directory)

Hit Enter. Type "Moon/Gartner"

Hit G.

Bookmark the location using "Add bookmark".

The bookmarks menu now has an entry called "Follow G%ffffffc3%...fc3%ffffffa4rtner". Clicking on it takes me immediately to the coordinate origin. Using "Add relative bookmark" gives me a slightly different but still mangled string, and the bookmark is still non-functional.

If instead I run with my patch, the same process results in an entry called "Follow G?rtner [G?rtner]". This bookmark results in me being taken to the expected location. Using "Add relative bookmark" gives me an entry called "Follow G%c3%a4rtner [G%c3%a4rtner]" (not as ideal) and the bookmark still works.

However while I also experience this issue in trunk, the patch does NOT fix it there.

EDIT: Withdrawn the KDE patch (again) because of the relative bookmark error. (This is a cosmetic problem rather than a functional one)

ajtribick wrote:Sorry I have never ever experienced the problem you are seeing with the Moon in the KDE version. I have absolutely no idea what you are talking about here. I guess just as you dismiss my problems with Unicode bookmarks as a non-existent issue, I should dismiss your problems with the moon as similarly non-existent

Fair enough

Seriously, since I observe this Moon issue for so long on several of my Linux machines with different versions of OpenSuSE it can hardly be fiction. Years ago I had a similarly persistent issue with gimp, which only after one year was officially resolved to be a gtk+ bug.

Nor am I using your world capitals add-on.

Too bad, there is nothing better if you want 40000+ cities marked on Earth with dynamical (i.e. non-mangled) label density display. It's not an add-on, since I made it way before the Motherlode existed . Later it was largely copied by HS without citation and uploaded to CML...

Maybe this is a localisation issue, however I switched my system to de_DE.utf8 and saw no change of behaviour.

I NEVER use i18n stuff. English is my standard language for Celestia or scientific matters since decades.

However while I also experience this issue in trunk, the patch does NOT fix it there.

Aha! That's what I also observed in trunk, whence I concluded that I don't need that patch.
Since I don't fancy and thus didn't test 1.6.1 ...

Moreover there was no bookmarking problem in trunk with city names on Earth containing Unicode chars.

EDIT: Withdrawn the KDE patch (again) because of the relative bookmark error. (This is a cosmetic problem rather than a functional one)

OK

Fridger

Situation with trunk is somewhat different because ChrisL did not submit his url.cpp fix (5132) to the trunk. The problems with Unicode in cel URLs that are now fixed in 1.6.1 still affect the trunk (to demonstrate copy a URL after using G to go to something that has non-ASCII characters, and try to re-open, this will result in the user being transported to the coordinate origin). This is in addition to the KDE bookmarks menu issues I mentioned previously.

Attached patches fix all the KDE bookmark issues I have come across, including for relative and settings bookmarks, one is for v1.6.1, one is for trunk 5144 (the latter includes the changes to url.cpp now included in 1.6.1, this is not specific to the KDE version).

ajtribick wrote:Situation with trunk is somewhat different because ChrisL did not submit his url.cpp fix (5132) to the trunk. The problems with Unicode in cel URLs that are now fixed in 1.6.1 still affect the trunk (to demonstrate copy a URL after using G to go to something that has non-ASCII characters, and try to re-open, this will result in the user being transported to the coordinate origin). This is in addition to the KDE bookmarks menu issues I mentioned previously.

Attached patches fix all the KDE bookmark issues I have come across, including for relative and settings bookmarks, one is for v1.6.1, one is for trunk 5144 (the latter includes the changes to url.cpp now included in 1.6.1, this is not specific to the KDE version).

Andrew,

unlike the previous one, this last patch of yours (urlpatch-trunk.diff) works nicely on my KDE3 version of trunk. Why don't you commit it, in order to settle this issue for now?

Fridger

--- edit ---

john Van Vliet wrote:my oops there
the kde3 VS kde4 ( qt3 VS qt4)

right now i would not even bother with any kde3 bugs
now true i could install kde3.5 on my centOS 5.5 install HOWEVER like most i am planning on moving to SL 6
the Centso devs ( this time ) are being very slow

and there are not many still using kde 3.5

Celestia-kde3 is an officially supported Celestia flavor and is VERY stable in general. That's why us devs are taking care of it.

In addition, the KDE version of Celestia is more advanced than Celestia-gtk or Celestia-gnome. Unlike the latter two, it has a very convenient bookmarking facility, for example.

Celestia-kde integrates well into KDE4 desktops, so that's no problem whatsoever. One just has to install KDE3 and Qt3 libs and headers for building the code. KDE3 is VERY well debugged given the many years of being a principal desktop kit for Linux.

In OpenSuSE KDE3 and KDE4 applications are coexisting happily since a long time.
Of course, OpenSuSE also offers the KDE3 version of celestia-1.6.0 in its 11.x distributions.

Fridger

ajtribick wrote:On the other hand we've recently got 1.6.1 to a state where it is very nearly able to be released (at least for Linux and Windows - I'm not sure what the current status of the Mac version is: would be nice if ChrisL would come out of lurk mode...)

I'm looking at one more Mac bug (though it's likely not even Mac-specific): The flashing that occurs when running some Lua scripts that present a 2D UI overlay. I've tried to fix this before without success. I'll give myself the weekend to resolve it, otherwise we should punt it to the next version.

--Chris

--- edit ---