headers
Jasem Mutlaq | 2 Jun 08:14

Re: KDE/kdeedu/kstars

--- Jason Harris <kstars <at> 30doradus.org> wrote:

> SVN commit 670149 by harris:
> 
> Adding README.api, which is meant to provide a
> high-level description of 
> the code architecture.  Eventually, this should
> become our Mainpage.dox, 
> so it will appear at 
>
http://api.kde.org/4.0-api/kdeedu-apidocs/kstars/html/index.html
> (by the way, why does that page show the INDI
> mainpage now?)

That's because of \mainpage Doxygen keyword used in
indi/indiapi.h, it needs to be in KStars docs instead.
Will fix this soon.

Cheers,
Jasem
Permalink | Reply | 1 comment |
headers
Glenn Becker | 3 Jun 22:05
Picon
Favicon

herschel images


Hi, all -

My apologies for having gone missing. Will do my best to get some work 
done on the Herschel images add-on in the next couple of weekends.

Best,

Glenn

+-----------------------------------------------------+
Glenn Becker - burningc <at> sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
+-----------------------------------------------------+
Permalink | Reply | 0 comments |
headers
Akarsh Simha | 4 Jun 11:43
Picon
Gravatar

Re: Kstars-devel Digest, Vol 46, Issue 8

I'm sorry... please ignore my previous reply in this thread - it makes
no sense whatever and I was confused while writing that.

How would one predict occultations though?
The only way I can think of is keep increasing (or decreasing) the
time in certain small steps and check if the occultation is going to
happen. But that will be extremely slow, or so I think.

A modification I see to the above is that we ask the user to input a
time range and then do some kind of a smart search which also applies
some logic to guess an estimate and then search around that.

Any better ideas?

On 5/28/07, Akarsh Simha <akarshsimha <at> gmail.com> wrote:
> Ok. Thanks for that. I guess I should be able to do it easily if the
> heliocentric longitudes are computed somewhere. I'll take a look into
> this.
>
> On 5/28/07, brian hurren <brianhurren <at> yahoo.com> wrote:
> > Akarsh, have a go at writing a class for occultations.
> >
> > kstars-devel-request <at> kde.org wrote:
> > Send Kstars-devel mailing list submissions to
> > kstars-devel <at> kde.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://mail.kde.org/mailman/listinfo/kstars-devel
> > or, via email, send a message with subject or body 'help' to
> > kstars-devel-request <at> kde.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason Harris | 4 Jun 16:57
X-Face

Re: Kstars-devel Digest, Vol 46, Issue 8

Hello,

I think you're right; the only way to predict occultation events is to advance 
the time in small steps, and check whether the angular separation of the 
bodies is smaller than their angular size.

However, there are ways to speed up the process.  You can take a large 
timestep, and see if a linear approximation of the body's path carries it 
near any bright stars.  If so, then you can estimate when a potential 
occultation would occur, set the clock to that time, and check the position.  
The new position will either (a) be in occultation, (b) exclude the 
possibility of occultation, or (c) be placed "before" or "after" a potential 
occultation.  In case (c), we would predict a new occultation time based on 
the body's positions at known times bracketing the target star, set the clock 
to that time and try again until we got (a) or (b).

This is called a "predictor-corrector" search.  It is much faster than just 
advancing the clock by small steps over the whole interval.  When the target 
object that may be occulted is another planetary body (rather than a star), 
the calculation will be more complicated, but the general strategy still 
applies, I think.

regards,
Jason

On Monday 04 June 2007 02:43, Akarsh Simha wrote:
> I'm sorry... please ignore my previous reply in this thread - it makes
> no sense whatever and I was confused while writing that.
>
> How would one predict occultations though?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akarsh Simha | 4 Jun 19:06
Picon
Gravatar

Re: Kstars-devel Digest, Vol 46, Issue 8

Hi.

I see that this logic works very fast.

But how would you be sure that the algorithm hasn't missed one of
those possible occultations?

And how do we keep these "occultable" objects, i.e. bright stars,
planets? Do we put them in a QList or QHash or some such thing?

How I picturize the occultation module is that it should be able to
predict occultations of a fixed body against a number of possible
other bodies. These other bodies could be bright stars, other planets,
or DSOs. I should also be able to select a fixed object for the second
object, like, for instance ask when the next occultation of Moon and
Mars will be. I should also be able to give time ranges for prediction
of occultations.

I also feel it'd be nice if we could extend the occultations tool to
also do rendezvous predictions, like the recent Comet 73P and Ring
Nebula etc. I picturize this as an "occultation" where the angular
separation between the objects is set to something arbitrary, say the
FOV of your telescope. That could help you predict, for instance, when
Comet 2P/Encke and Andromeda Galaxy would again appear in the same FOV
in the telescope, which would be a wonderful and unique extension to
the same occultation tool.

Any ideas?

On 6/4/07, Jason Harris <jharris <at> 30doradus.org> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
brian hurren | 5 Jun 12:49
Picon
Favicon

Re: Kstars-devel Digest, Vol 47, Issue 4

in reguards to ocultations, woud it be easier to convert everything into polar coordinates then the positions of the stars and the moon becomes an angle and a radius. everywhere that the angles of the stars and the moon are the same and the radii are the same is an occultation. the thing becomes geometry without such a need for time. if you think of it as a graph you can visualise all the stars in the moons path as a 'donut' and the moons path (say for aguments sake, over a year) would make a spirograph patern. everywhere where the spirograph patern hits a star would be an occultation.

kstars-devel-request <at> kde.org wrote:

Send Kstars-devel mailing list submissions to
kstars-devel <at> kde.org

To subscribe or unsubscribe via the World Wide Web, visit https://mail.kde.org/mailman/listinfo/kstars-devel
or, via email, send a message with subject or body 'help' to
kstars-devel-request <at> kde.org

You can reach the person managing the list at
kstars-devel-owner <at> kde.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kstars-devel digest..."


Today's Topics:

1. Re: Kstars-devel Digest, Vol 46, Issue 8 (Jason Harris)
2. Re: Kstars-devel Digest, Vol 46, Issue 8 (Akarsh Simha)


----------------------------------------------------------------------

Message: 1
Date: Mon, 4 Jun 2007 07:57:17 -0700
From: Jason Harris
Subject: Re: [Kstars-devel] Kstars-devel Digest, Vol 46, Issue 8
To: KStars Development Mailing List
Message-ID: <200706040757.18055.kstars <at> 30doradus.org>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I think you're right; the only way to predict occultation events is to advance
the time in small steps, and check whether the angular separation of the
bodies is smaller than their angular size.

However, there are ways to speed up the process. You can take a large
timestep, and see if a linear approximation of the body's path carries it
near any bright stars. If so, then you can estimate when a potential
occultation would occur, set the clock to that time, and check the position.
The new position will either (a) be in occultation, (b) exclude the
possibility of occultation, or (c) be placed "before" or "after" a potential
occultation. In case (c), we would predict a new occultation time based on
the body's positions at known times bracketing the target star, set the clock
to that time and try again until we got (a) or (b).

This is called a "predictor-corrector" search. It is much faster than just
advancing the clock by smal l steps over the whole interval. When the target
object that may be occulted is another planetary body (rather than a star),
the calculation will be more complicated, but the general strategy still
applies, I think.

regards,
Jason

On Monday 04 June 2007 02:43, Akarsh Simha wrote:
> I'm sorry... please ignore my previous reply in this thread - it makes
> no sense whatever and I was confused while writing that.
>
> How would one predict occultations though?
> The only way I can think of is keep increasing (or decreasing) the
> time in certain small steps and check if the occultation is going to
> happen. But that will be extremely slow, or so I think.
>
> A modification I see to the above is that we ask the user to input a
> time range and then do some kind of a smart search which also applies
> some logic to guess an estimate and then search around that.
>
> Any be tter ideas?
>
> On 5/28/07, Akarsh Simha wrote:
> > Ok. Thanks for that. I guess I should be able to do it easily if the
> > heliocentric longitudes are computed somewhere. I'll take a look into
> > this.
> >
> > On 5/28/07, brian hurren wrote:
> > > Akarsh, have a go at writing a class for occultations.
> > >
> > > kstars-devel-request <at> kde.org wrote:
> > > Send Kstars-devel mailing list submissions to
> > > kstars-devel <at> kde.org
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > https://mail.kde.org/mailman/listinfo/kstars-devel
> > > or, via email, send a message with subject or body 'help' to
> > > kstars-devel-request <at> kde.org
> > >
> > > You can reach the person managing the list at
> > > kstars-devel-owner <at> kde.org
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of Kstars-devel digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > > 1. Quite a few bugs (Akarsh Simha)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Sun, 27 May 2007 00:55:29 +0530
> > > From: "Akarsh Simha"
> > > Subject: [Kstars-devel] Quite a few bugs
> > > To: kstars-devel <at> kde.org
> > > Message-ID:
> > >
> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > >
> > > Hello
> > >
> > > I am new to this mailing list. I am Akarsh Simha, a student of
&g t; > > Physics, from Bangalore, India and an amateur astronomer. Am not very
> > > well acquainted with Linux programming, though I can do some coding in
> > > C++.
> > >
> > > I was looking through KStars and found a few bugs, which I'm posting
> > > here:
> > >
> > > 1. The highlighted constellation boundaries do not coincide with the
> > > actual boundaries when zoomed in.
> > > 2. Io and Europa are not displaying correctly
> > > 3. Constellation names in the object identification that pops up when
> > > you right click on the object shows the constellations' three letter
> > > abbreviations instead of the name.
> > > 4. I opened the Object Details dialog and clicked on the image to do
> > > an image search. After I closed the image search dialog, I got a
> > > segmentation fau lt. I have saved the Backtrace that KDE generated.
> > > 5. It seems like there is no display symbol for asteroids. I feel that
> > > the symbol for comets need to be something more meaningful.
> > >
> > > Regards,
> > > Akarsh
> > >
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > Kstars-devel mailing list
> > > Kstars-devel <at> kde.org
> > > https://mail.kde.org/mailman/listinfo/kstars-devel
> > >
> > >
> > > End of Kstars-devel Digest, Vol 46, Issue 8
> > > *******************************************
> > >
> > >
> > >
> > > ________________________________
> > > Ready for the edge of your seat? Check out tonight's top picks on
> > > Yahoo! TV .
> > >
> > >
> > > _______________________________________________
> > > Kstars-devel mailing list
> > > Kstars-devel <at> kde.org
> > > https://mail.kde.org/mailman/listinfo/kstars-devel
> >
> > --
> > Regards,
> > Akarsh
> > http://www.bas.org.in
> > http://www.nascent-technologies.com

--
KStars: http://edu.kde.org/kstars
Community Forums: http://kstars.30doradus.org


------------------------------

Message: 2
Date: Mon, 4 Jun 2007 22:36:02 +0530
From: "Akarsh Simha"
Subject: Re: [Kstars-devel] Kstars-devel Digest, Vol 46, Issue 8
To: "KStars Development Mailing List"
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi.

I see that this logic works very fast.

But how would you be sure that the algorithm hasn't missed one of
those possible occultations?

And how do we keep these "occultable" objects, i.e. bright stars,
planets? Do we put them in a QList or QHash or some such thing?

How I picturize the occultation module is that it should be able to
predict occultations of a fixed body against a number of possible
other bodies. These other bodies could be bright stars, other planets,
or DSOs. I should also be able to select a fixed object for the second
object, like, for instance ask when the next occultation of Moon and
Mars will be. I should also be able to give time ranges for prediction
of occultations.

I also feel it'd be nice if we could extend the occultations tool to
also do rendezvous predictions, like the recent Comet 73P and Ring
Nebula etc. I picturize this as an "occultation" where the angular
separation between the objects is set to something arbitrary, say the
FOV of your telescope. That could help you predict, for instance, when
Comet 2P/Encke and Andromeda Galaxy would again appear in the same FOV
in the telescope, which would be a wonderful and unique extension to
the same occultation tool.

Any ideas?



On 6/4/07, Jason Harris wrote:
> Hello,
>
> I think you're right; the only way to predict occultation events is to advance
> the time in small steps, and check whether the angular separation of the
> bodies is smaller than their angular size.
>
> However, there are ways to speed up the process. You can take a large
> timestep, and see if a linear approximation of the body's path carries it
> near any bright stars. If so, then you can estimate when a potential
> occultation would occur, set the clock to that time, and check the position.
> The new position will either (a) be in occultation, (b) exclude the
> possibility of occultation, or (c) be placed "before" or "after" a potential
> occultation. In case (c), we would predict a new occultation time based on
> the body's positions at known times bracketing the target star, set the clock
> to that time and try again until we got (a) or (b).
>
> This is called a "predictor-corrector" search. It is much faster than just
> advancing the clock by small steps over the whole interval. When the target
> object that may be occulted is another planetary body (rather than a star),
> the calculation will be more complicated, but the general strategy still
> applies, I think.
>
> regards,
> Jason
>
> On Monday 04 June 2007 02:43, Akarsh Simha wrote:
> > I'm sorry... please ignore my previous reply in this thread - it makes
> > no sense whatever and I was confused while writing that.
> >
> > How would one predict occultations though?
> > The only way I can think of is keep increasing (or decreasing) the
> > time in certain small steps and check if the occultation is going to
> > happen. But that will be extremely slow, or so I think.
> >
> > A modification I see to the above is that we ask the user to input a
> > time range and then do some kind of a smart search which also applies
> > some logic to guess an estimate and then search around that.
> >
> > Any better ideas?
> >
> > On 5/28/07, Akarsh Simha wrote:
> > > Ok. Thanks for that. I guess I should be able to do it easily if the
> > > heliocentric longitudes are computed somewhere. I'll take a look into
> > > this.
> > >
> > > On 5/28/07, brian hurren wrote:
> > > > Akarsh, have a go at writing a class for occultations.
> > > >
> > > > kstars-devel-request <at> kde.org wrote:
> > > > Send Kstars-devel mailing list submissions to
> > > > kstars-devel <at> kde.org
> > > >
> > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > https://mail.kde.org/mailman/listinfo/kstars-devel
> > > > or, via email, send a message with subject or body 'help' to
> > > > kstars-devel-request <at> kde.org
> > > >
> > > > You can reach the person managing the list at
> > > > kstars-devel-owner <at> kde.org
> > > >
> > > > When replying, please edit your Subject line so it is more specific
> > > > than "Re: Contents of Kstars-devel digest..."
> > > >
> > > >
> > > > Today's Topics :
> > > >
> > > > 1. Quite a few bugs (Akarsh Simha)
> > > >
> > > >
> > > > ----------------------------------------------------------------------
> > > >
> > > > Message: 1
> > > > Date: Sun, 27 May 2007 00:55:29 +0530
> > > > From: "Akarsh Simha"
> > > > Subject: [Kstars-devel] Quite a few bugs
> > > > To: kstars-devel <at> kde.org
> > > > Message-ID:
> > > >
> > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > > >
> > > > Hello
> > > >
> > > > I am new to this mailing list. I am Akarsh Simha, a student of
> > > > Physics, from Bangalore, India and an amateur astronomer. Am not very
> > > > well acquainted with Linux programming, though I can do some coding in
> > > > C++.
> > > >
> > > > I was looking through KStars and found a few bugs, which I'm posting
> > > > here:
> > > >
> > > > 1. The highlighted constellation boundaries do not coincide with the
> > > > actual boundaries when zoomed in.
> > > > 2. Io and Europa are not displaying correctly
> > > > 3. Constellation names in the object identification that pops up when
> > > > you right click on the object shows the constellations' three letter
> > > > abbreviations instead of the name.
> > > > 4. I opened the Object Details dialog and clicked on the image to do
> > > > an image search. After I closed the image search dialog, I got a
> > > > segmentation fault. I have saved the Backtrace that KDE generated.
> > > > 5. It seems like there is no display symbol for asteroids. I feel that
> > > > the symbol for comets need to be something more meaningful.
> > > >
> > > > Regards,
> > > > Akarsh
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > _______________________________________________
> > > > Kstars-devel mailing list
> > > > Kstars-devel <at> kde.org
> > > > https://mail.kde.org/mailman/listinfo/kstars-devel
> > > >
> > > >
> > > > End of Kstars-devel Digest, Vol 46, Issue 8
> > > > *******************************************
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > Ready for the edge of your seat? Check out tonight's top picks on
> > & gt; > Yahoo! TV.
> > > >
> > > >
> > > > _______________________________________________
> > > > Kstars-devel mailing list
> > > > Kstars-devel <at> kde.org
> > > > https://mail.kde.org/mailman/listinfo/kstars-devel
> > >
> > > --
> > > Regards,
> > > Akarsh
> > > http://www.bas.org.in
> > > http://www.nascent-technologies.com
>
> --
> KStars: http://edu.kde.org/kstars
> Community Forums: http://kstars.30doradus.org
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel <at> kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>


--
Regards,
Akarsh
http://www.bas.org.in
http://www.nascent-technologies.com


------------------------------

______________________________________ _________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel


End of Kstars-devel Digest, Vol 47, Issue 4
*******************************************
<at> yahoo.com> <at> gmail.com> <at> 30doradus.org> <at> mail.gmail.com> <at> kde.org> <at> gmail.com> <at> yahoo.com> <at> gmail.com> <at> kde.org> <at> 30doradus.org>

Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center. 
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 1 comment |
headers
Jason Harris | 5 Jun 16:08

Re: Kstars-devel Digest, Vol 47, Issue 4

Hi Brian,

But the moon moves, so you have to take time into account, so you know 
when the occultation occurs.  And you don't know the shape of the Moon's 
"spirograph" ahead of time, the only way to "plot" it on the graph is to 
calculate the moon's position for a long series of timesteps.

The moon's path across the sky is not a simple formula; it's a complex 
numerical integration that is a function of both time and position on 
Earth.  See README.planetmath for more information on this.

A simple strategy like you are describing would possibly work for solar 
occultations of background stars, since the path of the sun across the 
sky is known ahead of time: it's just the ecliptic.  We know which 
bright stars are within 0.25 degrees of the ecliptic, and using the 
"equation of time", we can easily figure out when the Sun is occulting 
these stars.  However, not many people are interested in occultations of 
stars by the Sun :)

regards,
Jason

brian hurren wrote:
> in reguards to ocultations, woud it be easier to convert everything into polar coordinates then the
positions of the stars and the moon becomes an angle and a radius. everywhere that the angles of the stars
and the moon are the same and the radii are the same is an occultation. the thing becomes geometry without
such a need for time. if you think of it as a graph you can visualise all the stars in the moons path as a 'donut'
and the moons path (say for aguments sake, over a year) would make a spirograph patern. everywhere where
the spirograph patern hits a star would be an occultation.
> 
> kstars-devel-request <at> kde.org wrote: Send Kstars-devel mailing list submissions to
>  kstars-devel <at> kde.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>  https://mail.kde.org/mailman/listinfo/kstars-devel
> or, via email, send a message with subject or body 'help' to
>  kstars-devel-request <at> kde.org
> 
> You can reach the person managing the list at
>  kstars-devel-owner <at> kde.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kstars-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Kstars-devel Digest, Vol 46, Issue 8 (Jason Harris)
>    2. Re: Kstars-devel Digest, Vol 46, Issue 8 (Akarsh Simha)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 4 Jun 2007 07:57:17 -0700
> From: Jason Harris 
> Subject: Re: [Kstars-devel] Kstars-devel Digest, Vol 46, Issue 8
> To: KStars Development Mailing List 
> Message-ID: <200706040757.18055.kstars <at> 30doradus.org>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> Hello,
> 
> I think you're right; the only way to predict occultation events is to advance 
> the time in small steps, and check whether the angular separation of the 
> bodies is smaller than their angular size.
> 
> However, there are ways to speed up the process.  You can take a large 
> timestep, and see if a linear approximation of the body's path carries it 
> near any bright stars.  If so, then you can estimate when a potential 
> occultation would occur, set the clock to that time, and check the position.  
> The new position will either (a) be in occultation, (b) exclude the 
> possibility of occultation, or (c) be placed "before" or "after" a potential 
> occultation.  In case (c), we would predict a new occultation time based on 
> the body's positions at known times bracketing the target star, set the clock 
> to that time and try again until we got (a) or (b).
> 
> This is called a "predictor-corrector" search.  It is much faster than just 
> advancing the clock by small steps over the whole interval.  When the target 
> object that may be occulted is another planetary body (rather than a star), 
> the calculation will be more complicated, but the general strategy still 
> applies, I think.
> 
> regards,
> Jason
> 
> On Monday 04 June 2007 02:43, Akarsh Simha wrote:
>> I'm sorry... please ignore my previous reply in this thread - it makes
>> no sense whatever and I was confused while writing that.
>>
>> How would one predict occultations though?
>> The only way I can think of is keep increasing (or decreasing) the
>> time in certain small steps and check if the occultation is going to
>> happen. But that will be extremely slow, or so I think.
>>
>> A modification I see to the above is that we ask the user to input a
>> time range and then do some kind of a smart search which also applies
>> some logic to guess an estimate and then search around that.
>>
>> Any better ideas?
>>
>> On 5/28/07, Akarsh Simha  wrote:
>>> Ok. Thanks for that. I guess I should be able to do it easily if the
>>> heliocentric longitudes are computed somewhere. I'll take a look into
>>> this.
>>>
>>> On 5/28/07, brian hurren 
>  wrote:
>>>> Akarsh, have a go at writing a class for occultations.
>>>>
>>>> kstars-devel-request <at> kde.org wrote:
>>>> Send Kstars-devel mailing list submissions to
>>>> kstars-devel <at> kde.org
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> https://mail.kde.org/mailman/listinfo/kstars-devel
>>>> or, via email, send a message with subject or body 'help' to
>>>> kstars-devel-request <at> kde.org
>>>>
>>>> You can reach the person managing the list at
>>>> kstars-devel-owner <at> kde.org
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of Kstars-devel digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>> 1. Quite a few bugs (Akarsh Simha)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Sun, 27 May 2007 00:55:29 +0530
>>>> From: "Akarsh Simha"
>>>> Subject: [Kstars-devel] Quite a few bugs
>>>> To: kstars-devel <at> kde.org
>>>> Message-ID:
>>>>
>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>
>>>> Hello
>>>>
>>>> I am new to this mailing list. I am Akarsh Simha, a student of
>>>> Physics, from Bangalore, India and an amateur astronomer. Am not very
>>>> well acquainted with Linux programming, though I can do some coding in
>>>> C++.
>>>>
>>>> I was looking through KStars and found a few bugs, which I'm posting
>>>> here:
>>>>
>>>> 1. The highlighted constellation boundaries do not coincide with the
>>>> actual boundaries when zoomed in.
>>>> 2. Io and Europa are not displaying correctly
>>>> 3. Constellation names in the object identification that pops up when
>>>> you right click on the object shows the constellations' three letter
>>>> abbreviations instead of the name.
>>>> 4. I opened the Object Details dialog and clicked on the image to do
>>>> an image search. After I closed the image search dialog, I got a
>>>> segmentation fault. I have saved the Backtrace that KDE generated.
>>>> 5. It seems like there is no display symbol for asteroids. I feel that
>>>> the symbol for comets need to be something more meaningful.
>>>>
>>>> Regards,
>>>> Akarsh
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Kstars-devel mailing list
>>>> Kstars-devel <at> kde.org
>>>> https://mail.kde.org/mailman/listinfo/kstars-devel
>>>>
>>>>
>>>> End of Kstars-devel Digest, Vol 46, Issue 8
>>>> *******************************************
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> Ready for the edge of your seat? Check out tonight's top picks on
>>>> Yahoo! TV.
>>>>
>>>>
>>>> _______________________________________________
>>>> Kstars-devel mailing list
>>>> Kstars-devel <at> kde.org
>>>> https://mail.kde.org/mailman/listinfo/kstars-devel
>>> --
>>> Regards,
>>>      Akarsh
>>> http://www.bas.org.in
>>> http://www.nascent-technologies.com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel <at> kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 0 comments |
headers
Jasem Mutlaq | 8 Jun 23:45

KStars context menu

Hello all,

I found a couple of items in the context that most
users will probably never or rarely use. Since the
context menu is accessed very often, we ought to keep
it as uncluttered as possible:

1. Add Link: We already have this functionality in the
details dialog. I think it's time to remove this menu
item from the context menu.

2. Angular Distance To: While useful and I use it
occasionally, most users wouldn't be using it often.

I suggest it should be removed as well from the menu.
But where would it go?

Maybe we can add another small toolbar for that
purpose (actions in the skymap). A "hand" icon is the
default and you can use it to zoom and pan like
normal. A ruler or a similar icon for angular
distance, and another icon for area-zoom (now done
with ctrl+left mouse).

Your thoughts?

Cheers,
Jasem
Permalink | Reply | 7 comments |
headers
Akarsh Simha | 9 Jun 00:29
Picon
Gravatar

Re: KStars context menu

Hello All.

I think that the 'toolbar' idea will be useful to expand the functionality of KStars.
Things like Digitized Sky Survey images can go to the toolbar as well.

In addition to these, I think objects, or at least stars should display their magnitudes in the context menu, because it is one of the most important factors we'd want to look up often.

Regards,
   Akarsh.

On 6/9/07, Jasem Mutlaq <mutlaqja <at> ikarustech.com> wrote:
Hello all,

I found a couple of items in the context that most
users will probably never or rarely use. Since the
context menu is accessed very often, we ought to keep
it as uncluttered as possible:

1. Add Link: We already have this functionality in the
details dialog. I think it's time to remove this menu
item from the context menu.

2. Angular Distance To: While useful and I use it
occasionally, most users wouldn't be using it often.

I suggest it should be removed as well from the menu.
But where would it go?

Maybe we can add another small toolbar for that
purpose (actions in the skymap). A "hand" icon is the
default and you can use it to zoom and pan like
normal. A ruler or a similar icon for angular
distance, and another icon for area-zoom (now done
with ctrl+left mouse).

Your thoughts?

Cheers,
Jasem

_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel



http://www.bas.org.in
http://www.nascent-technologies.com 
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 3 comments |
headers
Jasem Mutlaq | 9 Jun 01:18

Re: KStars context menu

Hi Akarsh,

--- Akarsh Simha <akarshsimha <at> gmail.com> wrote:

> Hello All.
> 
> I think that the 'toolbar' idea will be useful to
> expand the functionality
> of KStars.
> Things like Digitized Sky Survey images can go to
> the toolbar as well.

Actually, the toolbar is for 'actions on the skymap'
so your mouse cursor would change its shape to reflect
the action, which is be default panning. If someone
selected the ruler icon, the cursor changes and he can
select the two objects in the map to get angular
distance..etc

Regards,
Jasem
Permalink | Reply | 2 comments |

Gmane