Clickable property

[chris]

The latest code in SVN has a Clickable property for ssc objects. This works as you might expect. Adding the line:

Clickable false

to an ssc object definition will prevent it from being selected when clicked. As far as click selection is concerned, the object behaves as it if isn't there at all: it's possible to click other objects behind the a clickable false object. This is strange behavior if the clickable false is applied to an opaque object, but presumably this is not how add-on creators will use it

There is currently no Clickable property for stars or deep sky objects. For stars, I can't see that it would ever be necessary. For deep sky objects, maybe. This change also doesn't Chuft-Captain's 'translucent' option at the moment.

It's possible to select a Clickable false object via other means, such as the solar system browser or the Find object dialog. A 'Selectable' property which would prevent selection by any means at all is under consideration.

--Chris

[Cham]

The latest code in SVN has a Clickable property for ssc objects. This works as you might expect. Adding the line:

Clickable false

to an ssc object definition will prevent it from being selected when clicked.

I'll be testing this new *VERY* important feature right away, tonight, when I'll be back home ! Unfortunately, I'm stuck at my office for a long period today, just because it's the "open doors" event at my institution !

it's possible to click other objects behind the a clickable false object. This is strange behavior if the clickable false is applied to an opaque object, but presumably this is not how add-on creators will use it

There is currently no Clickable property for stars or deep sky objects.

Actually, an unclickable opaque object is also VERY important ! It just happens that I placed some opaque models around several stars (mostly pulsars), and don't want the shell to be clickable, so we can select the star itself. So contrary to what you believed, this is VERY important too, and I'll be using the feature for opaque objects also.

Another example : I'm using some opaque 3ds labels close to some stars and don't want them to be clickable (it would be useless and confusing to the novice users).

The unclickable feature is also requested for deep sky objects (nebulae, grids, 3ds labels, etc).

[cartrite]

I used to have a problem with the katrina model I created. I used an invisible box to orient the hurricane model. This was called earth2. The problem was that while the model was running, you couldn't select any thing for earth like vt's or info or anything. This fixes that problem 100% so far. Now I can have the katrina model running with earth2 and still right click to select features on the earth. Chris, this is great. Thanks.
cartrite

[Cham]

(I'm still at my office right now, so didn't had time to test the new feature yet)

To me, this new feature is certainly one of the MOST important features of Celestia 1.5.x. It will have repercussions (in the positive sense) on about ALL of my addons. I can't emphasize enough how much important it is for addons.

Simple example : Currently, in the case of ALL my old black holes addons, the accretion disk and jets are always in the way of the user. When some user wants to click on the central black hole to select and follow it, he/she gets the accretion disk (or jets) selected instead, which is very annoying. The user had to use the selection console to type in the name of the central object, and this makes things much more complicated. With the new feature, this is completely solved ! Clicking the central object will not select the disk (jets) anymore !

In the case of the pulsars I've created, I had to use an opaque sphere around the neutron star, so I could show the "hot spots" aligned with the tilted jets. Clicking on the star was always selecting that shell, instead of the neutron star itself. This is annoying since the user can't get the neutron star information (in the upper-left corner), unless he/she select it with the selection console. With the new feature, this problem is completely solved !

There are also some rare cases where my magnetic field lines can be selected when the user click on a line (especially in the regions of high concentration of field lines). The new feature solves this too.

And in the case of the stars comparison addon I made last year (yet to be published), I'm using some floating 3ds labels to identify each star. Currently, the user can click on them, which is useless and may be confusing. Again, the new option will solves this.

And there are many more examples of addons which can be improved with the unclickable false option. This is really an EXTREMELY important new feature, and I'm very enthusiastic for it !

[Cham]

Chris,

I'm testing the new feature, and it's really a HUGE improvement ! Everything works very well, until now. Nomore confusion after clicking on an accretion disk, or spherical shells around a star, pulsar jets, etc. This is simply great ! I already edited about all of my addons to use this *ESSENTIAL* feature (1).

Please, you should also consider to add the same feature to deep space objects (graticules, floating 3ds labels, nebula layers, etc).




(1) About all my published addons are now obsolete ! I'll have to republish everything, for Celestia 1.5.1.

[rthorvald]

The latest code in SVN has a Clickable property for ssc objects. This works as you might expect. Adding the line:

Clickable false

to an ssc object definition will prevent it from being selected when clicked.

I updated my Celestia today. This function does not work for me (Intel OSX). What can be the problem?

- rthorvald

[chris]

The latest code in SVN has a Clickable property for ssc objects. This works as you might expect. Adding the line:

Clickable false

to an ssc object definition will prevent it from being selected when clicked.

I updated my Celestia today. This function does not work for me (Intel OSX). What can be the problem?

- rthorvald

Can you post one of your ssc definitions that uses it?

--Chris

[rthorvald]

Here is my Bernal Sphere:

Code: Select all

"Bylgja Orbital" "Ran/Bylgja"
   {
    Class "spacecraft"
   Mesh "th_placeholder.cmod"
   Beginning   2372928.3637936 # OCT 1784
   Radius 9
   EllipticalOrbit
      {
      Period      4.444
      SemiMajorAxis   164339
      Eccentricity   0.7
      Inclination   -7
      MeanAnomaly   94
      AscendingNode   15
      }
   InfoURL "data/th_00_celurls.celx"
   Albedo 0.01
   RotationPeriod   0.1
   }



"" "Ran/Bylgja"
   {
    Class "spacecraft"
   Mesh "th_bylgiaislandhab.cmod"
   Beginning   2372928.3637936 # OCT 1784
   Radius 9
   EllipticalOrbit
      {
      Period      4.444
      SemiMajorAxis   164339
      Eccentricity   0.7
      Inclination   -7
      MeanAnomaly   94
      AscendingNode   15
      }
   Clickable false
   InfoURL "data/th_01ran.html"
   Albedo 0.01
   RotationPeriod   0.1
   }
"" "Ran/Bylgja"
   {
    Class "spacecraft"
   Mesh "th_bylgiaislandstat.cmod"
   Beginning   2372928.3637936 # OCT 1784
   Radius 9
   EllipticalOrbit
      {
      Period      4.444
      SemiMajorAxis   164339
      Eccentricity   0.7
      Inclination   -7
      MeanAnomaly   94
      AscendingNode   15
      }
   InfoURL "data/th_01ran.html"
   Clickable false
   Albedo 0.01
   }




... As you see, i left the InfoURL declarations in, for backwards compability. Perhaps that creates a conflict? If it does, it should not...

- rthorvald

[chris]

... As you see, i left the InfoURL declarations in, for backwards compability. Perhaps that creates a conflict? If it does, it should not...

The InfoURL doesn't interact with the Clickable property at all. Setting Clickable to false works just fine for me with any SSC object. Are you absolutely sure that you're running a new version of Celestia?

--Chris

[rthorvald]

Are you absolutely sure that you're running a new version of Celestia?

Yes. I updated and compiled it today, from CVS.

- rthorvald

[chris]

Are you absolutely sure that you're running a new version of Celestia?

Yes. I updated and compiled it today, from CVS.

That's the problem then: after 1.5.0, we switched from using CVS to Subversion (SVN). If you're using CVS, you're just getting the 1.5.0 source code. The procedure for using SVN is described here:

http://en.wikibooks.org/wiki/Celestia/D ... S_platform

If you're running Leopard, it's possible that SVN is installed already--you can check by trying to run svn from a terminal window. Post in this thread if you have any trouble getting SVN to work.

--Chris

[rthorvald]

That's the problem then: after 1.5.0, we switched from using CVS to Subversion (SVN). If you're using CVS, you're just getting the 1.5.0 source code.

Aha, that clears it up. Thanks!

- rthorvald

[rthorvald]

Ok, i compiled with the new. Now it works!

BTW, while doing so, i discovered a bug. Actually, it was a bug in one of my projects, not in Celestia, but 1.5.1 handles it differently than 1.5.0:

- If an object has an ending date that is earlier than its beginning date, 1.5.0 just ignores it, but 1.5.1 crashes.

- rthorvald

[chris]

Ok, i compiled with the new. Now it works!

Great! Are you running Leopard on your Mac? If so, was SVN already installed? I want to update the WikiBook docs with this information.

BTW, while doing so, i discovered a bug. Actually, it was a bug in one of my projects, not in Celestia, but 1.5.1 handles it differently than 1.5.0:

- If an object has an ending date that is earlier than its beginning date, 1.5.0 just ignores it, but 1.5.1 crashes.

Crashing is certainly not the right behavior I'll fix the problem.

--Chris

[rthorvald]

Are you running Leopard on your Mac? If so, was SVN already installed?

Yes, Leopard, but i don??t remember if it was part of the default install. It was not in Tiger, at least, and i seem to remember the Leo upgrade was a lot simpler, so most probably it was (for example, X11 was part of the default for the first time).

- rthorvald

[cartrite]

Quote:

BTW, while doing so, i discovered a bug. Actually, it was a bug in one of my projects, not in Celestia, but 1.5.1 handles it differently than 1.5.0:

- If an object has an ending date that is earlier than its beginning date, 1.5.0 just ignores it, but 1.5.1 crashes.


Crashing is certainly not the right behavior Smile I'll fix the problem.

This may be related to the crash I get in KDE when I try to enter a date before 4713 BC. This didn't happen with CVS but it happens in SVN. The last time it happened was from version 4157. In case you missed the email here is a crash log.

> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > [Thread debugging using libthread_db enabled]
> > [New Thread 47375666814464 (LWP 4900)]
> > [KCrash handler]
> > #5 0x00002b1680d1fd70 in strlen () from /lib64/libc.so.6
> > #6 0x00002b1680d37afe in strftime_l () from /lib64/libc.so.6
> > #7 0x00002b1680d374cc in strftime_l () from /lib64/libc.so.6
> > #8 0x0000000000499d3e in astro::Date::toCStr ()
> > #9 0x00000000004282ed in CelestiaCore::renderOverlay ()
> > #10 0x000000000042ac5b in CelestiaCore::draw ()
> > #11 0x00002b167c039706 in QGLWidget::glDraw ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #12 0x000000000048af5d in KdeApp::qt_invoke ()
> > #13 0x00002b167be22a7c in QObject::activate_signal ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #14 0x00002b167be23753 in QObject::activate_signal ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #15 0x00002b167be41dd5 in QTimer::event ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #16 0x00002b167bdcbe55 in QApplication::internalNotify ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #17 0x00002b167bdccbe0 in QApplication::notify ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #18 0x00002b167ab06208 in KApplication::notify ()
> > from /opt/kde3/lib64/libkdecore.so.4
> > #19 0x00002b167bdc24af in QEventLoop::activateTimers ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #20 0x00002b167bd8269d in QEventLoop::processEvents ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #21 0x00002b167bde0903 in QEventLoop::enterLoop ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #22 0x00002b167bf81bbb in QDialog::exec ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #23 0x000000000046665f in KdeApp::slotSetTime ()
> > #24 0x000000000048b090 in KdeApp::qt_invoke ()
> > #25 0x00002b167be22a7c in QObject::activate_signal ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #26 0x00002b167be23753 in QObject::activate_signal ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #27 0x00002b167a1ea13e in KAction::slotPopupActivated ()
> > from /opt/kde3/lib64/libkdeui.so.4
> > #28 0x00002b167a1ea3e3 in KAction::qt_invoke ()
> > from /opt/kde3/lib64/libkdeui.so.4
> > #29 0x00002b167be22a7c in QObject::activate_signal ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #30 0x00002b167c1066b2 in QSignal::signal ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #31 0x00002b167be3b4f5 in QSignal::activate ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #32 0x00002b167bf12c25 in QPopupMenu::mouseReleaseEvent ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #33 0x00002b167be55757 in QWidget::event ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #34 0x00002b167bdcbe55 in QApplication::internalNotify ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #35 0x00002b167bdccd91 in QApplication::notify ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #36 0x00002b167ab06208 in KApplication::notify ()
> > from /opt/kde3/lib64/libkdecore.so.4
> > #37 0x00002b167bd74c45 in QETWidget::translateMouseEvent ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #38 0x00002b167bd733f3 in QApplication::x11ProcessEvent ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #39 0x00002b167bd8240f in QEventLoop::processEvents ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #40 0x00002b167bde0903 in QEventLoop::enterLoop ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #41 0x00002b167bde07b2 in QEventLoop::exec ()
> > from /usr/lib/qt3/lib64/libqt-mt.so.3
> > #42 0x0000000000462971 in main ()

This crash used to only happen with the QT4 version but I noticed that it now happens in the KDE SVN version as well. I believe dirkpit also experienced this crash on MAC.
cartrite

[chris]

Ok, i compiled with the new. Now it works!

BTW, while doing so, i discovered a bug. Actually, it was a bug in one of my projects, not in Celestia, but 1.5.1 handles it differently than 1.5.0:

- If an object has an ending date that is earlier than its beginning date, 1.5.0 just ignores it, but 1.5.1 crashes.

I just committed a fix for this bug to SVN.

--Chris

[Chuft-Captain]

The latest code in SVN has a Clickable property for ssc objects.......This change also doesn't Chuft-Captain's 'translucent' option at the moment.

Just been testing the Clickable false property. Seems to work as expected.

However, I was wondering why you didn't implement the translucent option at the same time. There are situations where this also will be very useful, in fact essential, and IMO it would have been just as easy to implement a ternary property (true, false, translucent) as a binary one.

[EDIT: Unless your plan is to do something fancy like making the actual visual transparency of the clicked polygon a consideration in determining the "click-translucency" ]

CC

[Adirondack]

Maybe it would be useful if one could lock (and unlock) the entire screen for clicking
while a cel script is running (similar to the clickable property of ssc scripting).
In some circumstances (e.g. time sensitive script) a cel script can become useless when the
user clicks an object and go to it. To prevent any user action with the mouse, something
like 'clickablescreen false | true' (true is default) is needed in cel scripts.
Is this feasible?

Adirondack