开云体育

Thanks for the info. So I have to compile lx200xed seperately from
the XEphem compile?

Bob


--- In xephem@y..., Cor Bosman <cor@x> wrote:

I havent tried 3.5.2, but Elwood sent me a pre-release of the
lx200xed of 3.5.2 and that worked fine for me.

Make sure you compile lx200xed from 3.5.2 and use that. Previous
versions indeed dont work.

Cor

On Sat, Jan 19, 2002 at 06:49:46AM -0500, bncarper@c... wrote:

I'm making the switch from Windows to LINUX and would like to use

XEphem. I

have got XEphem up and running OK but can't seem to control my

LX200? Every

time I try I get the marker jumping all over the screen. I have

tried both

3.4.0.1 and 3.5.2.

Bob C

To unsubscribe from this group, send an email to:
xephem-unsubscribe@...



Your use of Yahoo! Groups is subject to

I'm making the switch from Windows to LINUX and would like to use XEphem. I
have got XEphem up and running OK but can't seem to control my LX200? Every
time I try I get the marker jumping all over the screen. I have tried both
3.4.0.1 and 3.5.2.

Bob C

Hello,

I've been using XEphem successfully for a long time already, starting with early 3.0 versions, also at our telescope site in Chile. Now that 3.5.2 is out, I'm trying it out.

First problem I got into, is the definition of Time Zone, which for my site reads:

Las Campanas Observatory ; 29 0 12 S ; 70 42 6 W ; 2282 ; &#92; WST4WDT,M9.5.0,M3.2.0

Apart from that the acronyms are rather wrong (should be
CLT/CLST), it also does not work well. I guess it is because
the Daylight Savings Time here in Chile is reversed, although this seems to be accounted for, at least theoretically, by adding the
"M" reversed entries. Still, when I invoke XEphem, it shows
WST time zone and 4:00:00 UT offset - both are wrong as we
have summertime here, so the DST acronym should be shown and
also we are 3 hours from UT time, not 4. I've even tried to
temporarily change the system time on my machine to some April
date (which is perfectly in Standard Time). XEphem kept showing
the same WST/4 settings in the main window. So something seems to be wrong here.

The older versions (at least up to 3.2) allowed for having the
time zone read from the system (at least on some systems like
Solaris, Linux). This, unfortunately, seems to be unavailable now, unless I was simply not clever enough to find it. At least, I tried to put the old preferences entry
XEphem.JD: Now
into ~/XEphem/XEphem file, to no success.

Any ideas?

regards, Michal Szymanski





To unsubscribe from this group, send an email to:
xephem-unsubscribe@...



Your use of Yahoo! Groups is subject to

--- In xephem@y..., Stephen Binks <steveb@i...> wrote:

I am running RH 7.2 linux with Sawfish WM on an i686.

Xephem 3.5.1 worked correctly but now with 3.5.2, anytime I try to

close

a window with the WM control (X button), the window contents

disappear

but the window stays open. The only exception to this is the main
window.

Thanks for the report. No, this is the first I have heard of this. The
only changes to window control from 3.5.1 to 3.5.2 were to the
Jupiter, Saturn and Uranus views so they no longer caused XEphem to
crash with some window managers (including Sawfish). These changes
fixed a bona fide bug common to these three windows that had been
there for years, it was not just a trial change. So it is puzzling to
hear a report that suggests a broader windowing issue has been
introduced. I would like to discuss some ideas to help me figure this
out.

1. Was the 3.5.1 binary that works ok also built on the same RH 7.2
system, with the same versions of gcc and Motif and run with the same
version of Sawfish? In other words, are we certain the only change
here was XEphem itself?

2. I see at www.redhat.com there has been two updates issued for the C
library for 7.2. I doubt this is the problem but it might be a good
idea to install these if you haven't already and rebuild both 3.5.1
and 3.5.2.

3. Have you tried other desktops, window managers, themes, etc? Most
of my testing is with KDE and FVWM2.

4. Window managers add their decorations around the application's
window by creating their own window slightly larger than the one
created by the app and reparenting so it appears behind the app's
window. It sounds like when XEphem is closed (via the decoration) that
XEphem does remove its own window ok but the window manager does not
then remove its window. Since the latter is the responsibility of the
window manager, it sounds like there might be some sort of missing or
broken handshake between the app and the window manager. This
handshake is handled automatically by Motif (via Xlib) so if this
really is the problem there is little I can do. If you are using
lesstif you might try openmotif (or v.v.) as way to explore this
possibility.

If anyone else has additional ideas, please join in.



To unsubscribe from this group, send an email to:
xephem-unsubscribe@...



Your use of Yahoo! Groups is subject to

--- In xephem@y..., Stephen Binks <steveb@i...> wrote:

I am running RH 7.2 linux with Sawfish WM on an i686.

Xephem 3.5.1 worked correctly but now with 3.5.2, anytime I try to

close

a window with the WM control (X button), the window contents

disappear

but the window stays open. The only exception to this is the main
window.

The windows close correctly from the xephem control

or

window "Close" button).

Once a window has been "closed"with the WM control, it can no

longer be

re-opened and the entire program must be shut down to close it.

I compiled Xephem from source.


Does anyone know what's going on and how to fix it?

Thanks for the report. No, this is the first I have heard of this.

only changes to window control from 3.5.1 to 3.5.2 were to the
Jupiter, Saturn and Uranus views so they no longer caused XEphem to
crash with some window managers (including Sawfish). These changes
fixed a bona fide bug common to these three windows that had been
there for years, it was not just a trial change. So it is puzzling

hear a report that suggests a broader windowing issue has been
introduced. I would like to discuss some ideas to help me figure

out.

1. Was the 3.5.1 binary that works ok also built on the same RH 7.2
system, with the same versions of gcc and Motif and run with the

version of Sawfish? In other words, are we certain the only change
here was XEphem itself?

2. I see at www.redhat.com there has been two updates issued for the

library for 7.2. I doubt this is the problem but it might be a good
idea to install these if you haven't already and rebuild both 3.5.1
and 3.5.2.

3. Have you tried other desktops, window managers, themes, etc? Most
of my testing is with KDE and FVWM2.

4. Window managers add their decorations around the application's
window by creating their own window slightly larger than the one
created by the app and reparenting so it appears behind the app's
window. It sounds like when XEphem is closed (via the decoration)

XEphem does remove its own window ok but the window manager does not
then remove its window. Since the latter is the responsibility of

window manager, it sounds like there might be some sort of missing

broken handshake between the app and the window manager. This
handshake is handled automatically by Motif (via Xlib) so if this
really is the problem there is little I can do. If you are using
lesstif you might try openmotif (or v.v.) as way to explore this
possibility.

If anyone else has additional ideas, please join in.