Page 1 of 2
Why is there so little feedback here?
Posted: 02.06.2006, 21:05
by Lethe
Celestia is a great application, no doubt about it.
But why is there virtually no feedback in this forum at all. Not even an 'OK, we don't know' type reponse to the issues people see?
I mean, why even have a 'bug forum' if all it is for is users to post to and then ignored?
Nick
Posted: 02.06.2006, 21:07
by Hunter Parasite
because celestia is perfect.
Re: Why is there so little feedback here?
Posted: 02.06.2006, 21:19
by t00fri
Lethe wrote:Celestia is a great application, no doubt about it.
But why is there virtually no feedback in this forum at all. Not even an 'OK, we don't know' type reponse to the issues people see?
I mean, why even have a 'bug forum' if all it is for is users to post to and then ignored?
Nick
Selden is answering questions with admirable patience and competence.
As to proposals for new features, many are just not realistic or far too specially formulated. Few proposals take into account constraints imposed by the existing code and its request for high performance.
But interesting proposals usually do receive quite a bit of feedback.
Many "bug" reports are no bugs, but simply due to incorrect OpenGL etc. installations and/or the use of old drivers. Few people care to make use of our most extensive search engine. The vast majority of "generic bugs" has been reported before...
++++++++++++++
Since the majority of bug reporters seem too lazy to sit down and write /precise/ reports about their used hard and software and the observed symptoms, it often would take too much time for the developers to extract these absolutely necessary data in tedious dialogs.
++++++++++++++
Bye Fridger
Posted: 02.06.2006, 21:21
by Hunter Parasite
thus, it is perfect. mostly.
Posted: 02.06.2006, 21:26
by t00fri
Hunter Parasite wrote:thus, it is perfect. mostly.
The question was not about Celestia's actual status but the apparent lack of feedback. Feedback costs a lot of time if questions are formulated in a very imprecise manner as it happens frequently, unfortunately.
Bye Fridger
Posted: 02.06.2006, 21:40
by Hunter Parasite
I still think celestia is awesome though.
Posted: 03.06.2006, 08:16
by Lethe
OK, lets take one example - the thread here, with my hack to fix the build:
http://www.celestiaproject.net/forum/viewtopic.php?t=9090
Now, you _could_ say this was a issue with Slackware, and nothing to do with Celestia code.
But how come I can build Linux kernels 2.6.16.xx, KDE3.3.5, QT3.3.6, Xorg6.9.0, GCC etc. etc. all from source with NO errors at all? Doesn't sound like my system is wrong?
And yet there is not one comment from a dev. in that thread...
Nick
Posted: 03.06.2006, 09:21
by t00fri
Lethe wrote:OK, lets take one example - the thread here, with my hack to fix the build:
http://www.celestiaproject.net/forum/viewtopic.php?t=9090Now, you _could_ say this was a issue with Slackware, and nothing to do with Celestia code.
But how come I can build Linux kernels 2.6.16.xx, KDE3.3.5, QT3.3.6, Xorg6.9.0, GCC etc. etc. all from source with NO errors at all? Doesn't sound like my system is wrong?
And yet there is not one comment from a dev. in that thread...
Nick
Because Slackware is simply not supported, since no developer uses it. No other distribution we use has shown this effect. There is obviously something wrong with the locale setup.
There are way too many Linux distributions out there. Most usually incorporate many distribution specific patches beyond our control. One day this inflation on the distribution market will kill the entire Linux idea.
We don't have the menpower to follow up "peculatities" of each single distribution.
Bye Fridger
Posted: 03.06.2006, 10:48
by Lethe
"But how come I can build Linux kernels 2.6.16.xx, KDE3.3.5, QT3.3.6, Xorg6.9.0, GCC etc. etc. all from source with NO errors at all?"
You ignored what I said. It is only Celestia (out of all the 100's of applications I build from source) that fails to build on that one line.
I am not knocking, but this bug was reported and ignored. I mean, somebody could have replied with what you just said and stated 'it builds OK on Redhat, SuSe, Mandriva etc. etc.' so we don't know?' Then perhaps people could start to look at what MAKES it build OK on other distros, and perhaps me (or someone else) could issue a patch to fix it for Slackware. That is a heck of a lot better than deathly silence.
Also I think you will find Slack is perhaps the cleanest Linux distro there is - it you can't build something on Slack, then suspect the code.
Nick
Posted: 03.06.2006, 12:46
by t00fri
Lethe wrote:"But how come I can build Linux kernels 2.6.16.xx, KDE3.3.5, QT3.3.6, Xorg6.9.0, GCC etc. etc. all from source with NO errors at all?"
You ignored what I said. It is only Celestia (out of all the 100's of applications I build from source) that fails to build on that one line.
I am not knocking, but this bug was reported and ignored. I mean, somebody could have replied with what you just said and stated 'it builds OK on Redhat, SuSe, Mandriva etc. etc.' so we don't know?' Then perhaps people could start to look at what MAKES it build OK on other distros, and perhaps me (or someone else) could issue a patch to fix it for Slackware. That is a heck of a lot better than deathly silence.
Also I think you will find Slack is perhaps the cleanest Linux distro there is - it you can't build something on Slack, then suspect the code.
Nick
Since this error happens in a kde specific routine (celsplashscreen) this is Christophe Teyssier's domain.
He coded that kde splashscreen stuff. He is also the developer who takes care about internationalization.
He does not look too often into this forum (like many developers including Chris). Just send him an email,
chris@teyssier.org
You did not tell what internationalization you have activated. It's strange, however that your 'make' suddenly switches to Russian and cyrillian fonts.
Do you get the same problem if you switch to English?
Bye Fridger
Posted: 03.06.2006, 15:17
by Lethe
If you actually read the post, the 'original' poster uses Russian. I am in England, and thus use English - same error.
The error has nothing to do with Locale. It is something to do with the code on calling C++ libraries.
Nick
Posted: 04.06.2006, 08:52
by Christophe
I do read the forum from time to time
The problem is probably that by default Qt is build without STL support on Slackware, so there is no implicit cast from std::string to QString.
Code: Select all
Index: src/celestia/kde/celsplashscreen.cpp
===================================================================
RCS file: /cvsroot/celestia/celestia/src/celestia/kde/celsplashscreen.cpp,v
retrieving revision 1.4
diff -u -r1.4 celsplashscreen.cpp
--- src/celestia/kde/celsplashscreen.cpp 7 Jan 2006 11:05:28 -0000 1.4
+++ src/celestia/kde/celsplashscreen.cpp 4 Jun 2006 08:49:51 -0000
@@ -56,7 +56,7 @@
}
void CelSplashScreen::update(const string& _message) {
- status.setContent(_message);
+ status.setContent(QString(_message));
repaint();
}
If this patch fixes the problem, let me know, I'll commit it.
Posted: 04.06.2006, 11:31
by Lethe
Nah, I did mess about with this a bit - I can't remember if I tried similar.
And I see re QT build line '-no-stl' I build my own QT, but do use Slackware configure line. Should I build QT with stl enabled?
then mv -f ".deps/celsplashscreen.Tpo" ".deps/celsplashscreen.Po"; \
else rm -f ".deps/celsplashscreen.Tpo"; exit 1; \
fi
celsplashscreen.cpp: In member function `virtual void CelSplashScreen::update(const std::string&)':
celsplashscreen.cpp:59: error: no matching function for call to `QString::QString(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/lib/qt/include/qstring.h:746: note: candidates are: QString::QString(QStringData*, bool)
/usr/lib/qt/include/qstring.h:720: note: QString::QString(int, bool)
/usr/lib/qt/include/qstring.h:406: note: QString::QString(const char*)
/usr/lib/qt/include/qstring.h:404: note: QString::QString(const QChar*, uint)
/usr/lib/qt/include/qstring.h:403: note: QString::QString(const QByteArray&)
/usr/lib/qt/include/qstring.h:402: note: QString::QString(const QString&)
/usr/lib/qt/include/qstring.h:401: note: QString::QString(QChar)
/usr/lib/qt/include/qstring.h:838: note: QString::QString()
make[5]: *** [celsplashscreen.o] Error 1
make[5]: Leaving directory `/home/nick/celestia/celestia-1.4.1/src/celestia/kde'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/nick/celestia/celestia-1.4.1/src/celestia/kde'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/nick/celestia/celestia-1.4.1/src/celestia'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/nick/celestia/celestia-1.4.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/nick/celestia/celestia-1.4.1'
make: *** [all] Error 2
BTW, on KDE3.5.3 now - that all built OK last night.
Thanks for trying, anyway.
Nick
Posted: 04.06.2006, 17:00
by Christophe
Yes, I've run into this before, explicit conversion from std::string to QString isn't possible either, you have to go through a char*. So the correct fix is probably this:
Code: Select all
Index: src/celestia/kde/celsplashscreen.cpp
===================================================================
RCS file: /cvsroot/celestia/celestia/src/celestia/kde/celsplashscreen.cpp,v
retrieving revision 1.4
diff -u -r1.4 celsplashscreen.cpp
--- src/celestia/kde/celsplashscreen.cpp 7 Jan 2006 11:05:28 -0000 1.4
+++ src/celestia/kde/celsplashscreen.cpp 4 Jun 2006 16:57:55 -0000
@@ -56,7 +56,7 @@
}
void CelSplashScreen::update(const string& _message) {
- status.setContent(_message);
+ status.setContent(_message.c_str());
repaint();
}
I think most distribs build Qt with STL support enabled these days, but still, Celestia isn't supposed to rely on it.
Posted: 04.06.2006, 17:31
by Lethe
Yep, that builds correct now, thanks!
BTW, I would never have got that fix in a 1000 years
(I think I tried everything else).
Nick
Posted: 04.06.2006, 17:50
by t00fri
Lethe wrote:Yep, that builds correct now, thanks!
BTW, I would never have got that fix in a 1000 years
(I think I tried everything else).
Nick
Yet it was a Slackware dependent issue...
Bye Fridger
Posted: 04.06.2006, 18:31
by Lethe
Eh? It;s a QT build option - nothing to do with what GNU/Linux version.
QT recommend turninmg off stl anyway, and it looks like most distros are building QT with slt off.
From trolltech site:
We want our container classes to behave in the same way on all platforms. The different compilers might have differnt implementations of STL, so the behavior can vary. In addition when we created the container classes, not all platforms had decent implementations of STL. Finally, we provide QString which is a string class which provides a string of unicode characters. Since QString is available on all platforms, we can be sure that it will work for passing unicode characters from one place to another.
Nick
Posted: 04.06.2006, 20:53
by Christophe
Lethe wrote:Eh? It;s a QT build option - nothing to do with what GNU/Linux version.
Well, yes. It is a distribution issue and not a Celestia bug proper. We try to make Celestia not rely on optional things like this but when conflicts occur with other packages, it is left to the packager to fix.
What Fridger means is that we can't possibly test Celestia on every distribution out there (who the hell can?), but we do know that released versions of Celestia are in wide use on a wide range of distributions. If you are having a problem compiling a released version of Celestia on your particular distribution then it most probably is an integration issue which any packager should be able to fix.
Lethe wrote:it looks like most distros are building QT with slt off.
Do they? STL support in gcc has come a long way since the pre-3.0 days. It is certainly now in wide use and a lot of opensource Qt projects do require STL support in Qt.
Posted: 05.06.2006, 10:32
by t00fri
Lethe,
here you got another "great" respective example of what I keep saying:
http://www.celestiaproject.net/forum/viewtopic ... highlight=
Xandros 3.0 Deluxe Linux...Who needs Xandros 3.0 Deluxe Linux in addition to the 10-15 distributions we got already!
This is the typical "format" the Celestia developers are supposed to follow up:
-- Celestia version used: unspecified
-- hardware: unspecified
-- naturally assumed that we know
every detail, patches and compile options of Xandros 3.0 Deluxe Linux...
-- and a Linux newbie in addition, meaning that you got to take a lot of "personal uncontrolled action" into account.
So if you feel like getting into this, providing "happy feedback" ...please
Bye Fridger
Posted: 05.06.2006, 19:22
by Lethe
I have
But this wasn't what I was on about. I understand the issues with all the permutations available, but you read through this forum, there is very little help at all with any bug reported.
Not even a 'don't know'.
That was all I was saying.
Nick