I don't think we should drop support for non OpenGL ES2 video cards
indeed. We can still continue develop the OpenGL 2.0/ES part of the
code, it's just more complicated to maintain both in parallel.
For the bugs, most of the text-related bug are caused by Qt/opengl
driver bugs. It could be that som
IMHO: folks, first step - we need found and invite skilled OpenGL
programmers and second step - begin discussion about supported
versions of OpenGL into Stellarium and OpenGL related bugs.
--
With best regards, Alexander
---
On Tue, Feb 21, 2012 at 4:59 AM, Alexander Wolf wrote:
> Greetings!
>
> 2012/2/21 Reaves, Timothy :
>>> The OpenGL state is not so much a mess as you seem to think, but it is
>>> a bit complicated for 2 reasons:
>> If you think this, you are not paying attention to the defect list. Alex,
>> would
Stellarium is not geared towards people with cheap Atom based laptops that
want to use it 'scope-side. That there are people in that category that
use it is not overly relevant. If Stellarium wants to change to be geared
towards those users, then remove the advanced stuff.
Stellarium is not inte
You are right, it's cheap vs. advanced notebooks. Unfortunately, "cheap"
reflects to "old-fashioned shaderless OpenGL 1.4". "Old" is even less,
like pre-1998 OpenGL1.2. I don't know whether dropping 1.2 support makes
any significant change in today's user base, performance or stability, but
droppin
So, with 50% or more of the registered defects being OpenGL related, this
is the area that needs work most. Fabian has stated that some of this is
due to supporting multiple versions of OpenGL. Doesn't sound like a hard
decision to me.
And to inflame some people even more, I'll point out that it
On Tue, Feb 21, 2012 at 2:58 AM, Georg Zotti wrote:
> On Mo, 20.02.2012, 23:51, Fabien Chéreau wrote:
>> [snip]
>> The OpenGL state is not so much a mess as you seem to think, but it is a
> bit complicated for 2 reasons:
>> - we still support old graphic cards which don't support shaders, and
>>
On 20 February 2012 12:45, Bogdan Marinov wrote:
> I just saw the latest changes, revision 5199. The revert to the old
> names is not complete
Sorted, thanks.
--
Keep Your Developer Skills Current with LearnDevNow!
The m
Greetings!
2012/2/21 Reaves, Timothy :
>> The OpenGL state is not so much a mess as you seem to think, but it is
>> a bit complicated for 2 reasons:
> If you think this, you are not paying attention to the defect list. Alex,
> would you care to chime in on how many OpenGL defects there are in
> L
On Mon, Feb 20, 2012 at 5:51 PM, Fabien Chéreau <
fabien.cher...@googlemail.com> wrote:
>
> The OpenGL state is not so much a mess as you seem to think, but it is
> a bit complicated for 2 reasons:
>
If you think this, you are not paying attention to the defect list. Alex,
would you care to chim
On Mo, 20.02.2012, 23:51, Fabien Chéreau wrote:
> Hi guys,
> I was just followoing the thread from far away.
>> [...]
>> So what does that leave? Small, mainly non-consequential cosmetic stuff.
>
> I disagree, the real working is going in the plugins now, because the
core is quite stable. Even i
t; well as possible but do not try every possibility, so i only easily pick up
>> the most glaring mistakes.
>>
>> Barry Gerdes
>> Beaumont Hills Observatory
>> S 33' 41' 44" E 150' 56' 32"
>>
>>
>> > From: matthew..
ell as possible but do not try every possibility, so i only easily pick up
> the most glaring mistakes.
>
> Barry Gerdes
> Beaumont Hills Observatory
> S 33' 41' 44"E 150' 56' 32"
>
>
> > From: matthew...@gmail.com
> > Date: Mon,
m-pubdevel@lists.sourceforge.net
> Subject: Re: [Stellarium-pubdevel] renaming of members in the core
>
> Disambiguation required:
>
> QT is an abbreviation for Apple's QuickTime (which Stellarium does not use).
>
> QT is also Trolltech/Nokia's QT platform independent SDK
On Mon, Feb 20, 2012 at 2:50 AM, Matthew Gates wrote:
> Recent changes to use the QT properties system have included the
> renaming of many core class member functions. In the case of public
> slots, this directly changes the scripting API. I also don't think
> the replacements offer any real im
On Mo, 20.02.2012, 19:28, Matthew Gates wrote:
> Disambiguation required:
>
> QT is an abbreviation for Apple's QuickTime (which Stellarium does not
> use).
>
> QT is also Trolltech/Nokia's QT platform independent SDK, which
> Stellarium does use.
Hey, it's perfectly disambiguated: the second is
Disambiguation required:
QT is an abbreviation for Apple's QuickTime (which Stellarium does not use).
QT is also Trolltech/Nokia's QT platform independent SDK, which
Stellarium does use.
M
On 20 February 2012 10:20, Thomas Morris wrote:
> I think Timothy was being sarcastic? (Qt is the library
I think Timothy was being sarcastic? (Qt is the library/toolkit we use)
I tend to agree with Matthew regarding API changes, since many script
engine users may not be regular/serious programmers, and don't want to
change their scripts too often. Just my opinion!
Thanks,
Thomas
On 20 February 2012
On Feb 20, 2012 2:59 PM, "Reaves, Timothy"
wrote:
>
> As an aside, Stellarium does not - and probably never will - use QT. QT
is a technology used for playing audio & video.
Did not look at trunk (or however the current SCM calls it) lately but
IIRC, Stellarium _does_ use QT. it does use it to
Changes to StelModule public slot names are not insulated from the
scripting language. Public slots of classes whose instantiated
objects are made available to the script engine make up a large part
of the scripting API. This is how QTs scripting engine works, and in
my view it's a perfectly good
I think the changes do add value. isXXXDisplayed will let you know if XXX
is displayed. getFlagXXX -especially getFlagNames - tells you nothing.
As far as the scripting API goes, the uses should have been updated too.
But the scripting API should have insulated any scripts from the names of
meth
Recent changes to use the QT properties system have included the
renaming of many core class member functions. In the case of public
slots, this directly changes the scripting API. I also don't think
the replacements offer any real improvement over the previous names
(e.g. getFlagNames vs. isName
22 matches
Mail list logo
