headers
Valdas Jankūnas | 2 Mar 10:40
Picon

New locations for KStars

Hello,

sending new locations of cities (Lithuania) for KStars.

___
 Best regards,
    Valdas Jankūnas
Attachment (mycities.dat): application/x-ns-proxy-autoconfig, 803 bytes
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 0 comments |
headers
H | 2 Mar 23:09
Picon

kstars locationdialog.cpp question

Hi list,

If I select a city from the kstars list, and change a single coordinate
digit the 'add to list' button gets black. Good. However I always get
"could not parse coordinates". No matter what example city or
coordinates I use.

Any ideas ? Do you need more details ?

regards,
  Hans Lambermont

ps. please CC to my email address as I'm not a member of the list.
Permalink | Reply | 1 comment |
headers
Akarsh Simha | 3 Mar 09:25
Picon
Gravatar

Re: kstars locationdialog.cpp question

Hi

> If I select a city from the kstars list, and change a single coordinate
> digit the 'add to list' button gets black. Good. However I always get
> "could not parse coordinates". No matter what example city or
> coordinates I use.

https://bugs.kde.org/show_bug.cgi?id=178908

I think this is fixed in KDE 4.2

Regards
Akarsh
Permalink | Reply | 0 comments |
headers
Jain Basil Aliyas | 3 Mar 17:47
Favicon

Some Doubts : Please Help

Hello All,

I am working on a BUGFIX : 115928, I would like to have some clarifications regarding the same.

Some users set their hardware clock to UT, and do not configure their systems to convert to local time.
If possible, KStars should detect this and set the local time correctly in this case.

Some users set their hardware clock to UT : This seems to be okay since Gnu/Linux allows us to keep our hardware clock to UTC. Also this can be tracked by checking the file /etc/adjtime in which it will be written UTC or LOCAL.As far as I understood, hwclock  can be used to check this.see manual page of hwclock
 
do not configure their systems to convert to local time : This gives me some confusions. As we install our Gnu/Linux system, we need to select a time Zone and installation cannot continue without that.So Kernel automatically converts the time to local time (if hardware clock uses UTC or else it will not), based on this and we will be getting the Local time automatically. i.e. we may test this argument using hwclock command.

hwclock will display only local time. Suppose a hardware clock is set to local time. then if we run hwclock, it will show the local time. now we add an option --utc to it. this will interpret hwclock set to utc and now the result shows a conversion. Hence, I think there is no argument such that user donot configure their systems to convert to local time.

Can anyone please clarify this thing for me?

Regards,
Jain Basil Aliyas
--
http://jainbasil.wordpress.com
http://fsugtsr.org

_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 501 comments |
headers
Médéric Boquien | 3 Mar 18:00
Picon
Favicon
Gravatar

Re: Some Doubts : Please Help

Hi!


I am not sure i understand your questions but please avoid any use of hwclock or /etc/adjtime. As far as i know that is not portable and has every chance to break under MS windows for instance. QDate and QDateTime (and any related K* class) should provide enough information to solve the bug hopefully.


Regards,


Médéric


On Tuesday 03 March 2009 11:47:12 Jain Basil Aliyas wrote:
> Hello All,
>
> I am working on a BUGFIX : *115928*, I would like to have some
> clarifications regarding the same.
>
> *Some users set their hardware clock to UT, and do not configure their
> systems to convert to local time.
> If possible, KStars should detect this and set the local time correctly in
> this case.
> *
> *Some users set their hardware clock to UT* : This seems to be okay since
> Gnu/Linux allows us to keep our hardware clock to UTC. Also this can be
> tracked by checking the file */etc/adjtime* in which it will be written UTC
> or LOCAL.As far as I understood, *hwclock *can be used to check this.see
> manual page of *hwclock*
>
> *do not configure their systems to convert to local time* : This gives me
> some confusions. As we install our Gnu/Linux system, we need to select a
> time Zone and installation cannot continue without that.So Kernel
> automatically converts the time to local time (if hardware clock uses UTC
> or else it will not), based on this and we will be getting the Local time
> automatically. i.e. we may test this argument using hwclock command.
>
> hwclock will display only local time. Suppose a hardware clock is set to
> local time. then if we run hwclock, it will show the local time. now we add
> an option --utc to it. this will interpret hwclock set to utc and now the
> result shows a conversion. Hence, I think there is no argument such that
> user donot configure their systems to convert to local time.
>
> Can anyone please clarify this thing for me?


_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 501 comments |
headers
Khudyakov Alexey | 3 Mar 22:16
Picon
Gravatar

Re: Popup menu usability

On Tuesday 24 February 2009 08:48:39 Akarsh Simha wrote:
> > Me too. BTW it would be nice to add such <sup>m</sup> to labels on map.
> > For me it takes some time to understand that number after label is
> > magnitude.
>
> Good idea. You could go ahead and implement that too.
>
It turned out to be somewhat difficult, since on map labels are not QLabels 
and thus do not make '<sup>m</sup>' superscript. I'll left it aside for time 
being

> > As for my thoughts on catalogs. Sorry for delay but writing everything
> > takes more time than I expected.
>
> Well, I have some thoughts too - I would like to have support for
> Cartes du Ciel's catalog format - they are really extensible.
>
Is there some documention on that or should I look into sources?

AFAIK CdC has annoying issue with catalogs. If you install many catalogs you 
can found youself with fake double stars. This is because stars has slightly 
different coordinates in different catalogs. I haven't experienced this 
myself, only have been told. But without [one object] <-> [many catalog 
entries] relation this could become kstars problem too. 

> Why not try p->type() to distinguish between Comets, Asteroids and
> Planets, and p->isMajorPlanet() to distinguish between minor and major
> planets?

This does work. It's only breaks for Jupiter moon. type() return 
UNKNOWN_OBJECT for them. It seems that they are made special case somehow I'm 
digging for it now.
Permalink | Reply | 6 comments |
headers
Khudyakov Alexey | 3 Mar 22:08
Picon
Gravatar

Unneeded files?

Hello

I've found files like "*old" "*bak" in kstars/htmesh directory. Judging from 
their names I believe that they are some fossils from old times and should be 
removed then. Am I right?

--
  Khudyakov Alexey
Permalink | Reply | 1 comment |
headers
Khudyakov Alexey | 3 Mar 22:07
Picon
Gravatar

Some thoughts on catalogs

Hello.

I believe that there is a problem with current data model. Stellar objects can 
(and they do) appear in different catalogs. But there is no way to express 
such relation. DeepSkyObject has ugc() and pgc() methods[1] which return UGC 
and PGC number respectively. This isn't best way to add multiple catalog 
support. And of course i does not provide way to get data from that catalogs. 

Second there is no way to extract arbitrary data from catalog. Star catalogs 
can contain very diverse kind of data. Data which is present in one catalog 
may be absent in another. Currently there is no way get arbitrary data 
present in catalog. Creating all possible virtual functions is infeasible in 
my opinion. Just too many of them. 

So what is catalog? I'm going abstract from that point. Catalog is just set of 
pair: { (k,v) } where `k' is record type (magnitude, RA, B-V, etc.), and `v' 
is some value. Problem is that it could easily be of any type: number, 
string, couple of numbers. So it's difficult to implement this properly. 
I haven't much idea about it. It's kind of heterogenous map.

Another problem I mentioned already - creating one object <-> many catalogs 
relation. It's only become more difficult with need to utilize HTM and 
requirement that catalogs must be pluggable. 

This is attempt to formulate problem. No solutions or even proposal yet.
Comments, suggestions, crytitism are welcome. 

[1] kstars/deepskyobject.h : 152,157
--
  Khudyakov Alexey
Permalink | Reply | 2 comments |
headers
Khudyakov Alexey | 2 Mar 20:35
Picon
Gravatar

[patch] Change magnitude display in details dialog

Hello.

There are two patches which change how magnitude displayed in details dialog. 

* helper_functions.patch 

Add helper function to convert magnitude to string representation suitable for 
QLabel. It takes care for special cases. 

It was put in separate source file. It is meant to hold various small utility 
functions. Probably there is more suitable place for it but couldn't find it.

* details_m_superscript.patch 

Change how does magnitude displayed in details dialog. Use "m" superscript 
instead of "mag."

--
  Khudyakov Alexey
Attachment (helper_function.patch): text/x-diff, 4102 bytes
Attachment (details_m_superscript.patch): text/x-diff, 2352 bytes
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 5 comments |
headers
Médéric Boquien | 4 Mar 03:27
Picon
Favicon
Gravatar

List of observatories in Marble

Hi list,

I have just committed the support of astronomical observatories to Marble. If 
you run trunk you can see them, for instance zooming in on Chile. The list of 
observatories i have committed has been extracted from the kstars current 
database. The idea is not to lose a feature when switching to Marble for the 
location picker, someday.
I have added the observatories to marble/data/placemarks/otherplacemarks.kml. 
An example of a placemark is:
<Placemark>
    <name>Allegheny Observatory</name>
    <role>A</role>
    <pop>100000</pop>
        <Point>
            <coordinates>-80.0205555556,40.4833333333</coordinates>
        </Point>
</Placemark>

Role indicates the type of placemark, always A here, pop is the popularity, it 
defines when it should be displayed. For now its value is always 100000, but it 
could be tweaked according to the importance of the observatory. The 
coordinates are self-explanatory. Note that for now there is no metadata. You 
can see an example of such medata at the beginning of otherplacemarks.kml, in 
the descriptio field of the RMS Titanic.
So, what can be done now:
* add new observatories as the list is very uncomplete,
* add metadata,
* tweak the popularity
In case your are interested, you can test modifying otherplacemarks.kml and 
following the instructions given in marble/data/placemarks/HOWTO-cities.txt 
from point 3 (replacing cityplacemarks.kml by otherplacemarks.kml)

Regards,

Médéric
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 0 comments |

Gmane