Binary Orbits Revisited!

[granthutchison]

OK Grant, I shut up if you prefer.

Not at all. Feel free to carry on without me.

Grant

[t00fri]

OK Grant, I shut up if you prefer.

Not at all. Feel free to carry on without me.

Grant

That would be exceedingly boring as you know very well . So I'll return to studying the strikingly exponential growth law of global Swine flu infections ...

viewtopic.php?f=8&t=13834&start=17

Fridger

[Chuft-Captain]

Yes, one day , we may well think about allowing people to have still another switch for customizing "star name popularity". But additional customization switches also have a tendency of making things less transparent...

You must have a different definition of "transparent' to me. In my view, having the ability to see all naming schemes in the Celestial Browser makes it MORE transparent, not less. Bear in mind, I'm not suggesting a change in the order of the displayed string at the top of Celestia's main window, just the ability to display ALL naming schemes in the Celestial Browser.
Perhaps radio buttons is not the best approach (but that was just an example in order to communicate my point).
By far the best approach IMO, is something similar to the Windows Explorer title-bar (in "detail" mode) where a right-mouse click on the column titles area allows customization of the displayed columns, and a left-click allows columns to be dragged and dropped to change the display order.

explorer-det.jpg

The default content and order could remain as the status-quo (which is clearly your preference), but a user could add and remove the other naming schemes as additional columns in whatever order they desire.
eg.

browser-QT.jpg

This is pretty standard and easily accessed functionality (for a developer) in windows; I would expect that there is some equivalent in QT.

If you do something like this, then firstly, the Celestial Browser becomes much more transparent, and secondly, the arguments about popularity of the different schemes become irrelevant, as the Browser would cater for all tastes.

None of my comments apply to the main window display string. I leave it to you and/or Grant to battle about the best order for that.

CC

[t00fri]

CC,

my statement about lessened transparency merely referred to the general fact that increased amounts of customization invariably imply new things to learn for the users, which might be confusing to some. Since e.g. many claimed being unable to cope with starting my texture tools in command-line mode (a standard feature of Windows), one may indeed wonder whether such a sophisticated customization option would only be used by very few in practice...

Beyond that more general argument, I certainly agree that some options for customization of the name display could be useful.

Programming and testing a totally flexible customized name display scheme, as you seem to suggest, constitutes no doubt a considerable programming effort compared to your simplistic WE example above. Reasons are that the strings don't have the same number of alternate name elements and even involve different acronyms in different input catalogs: there are plenty of stars without a CCDM, HIP, HD, SAO,... entry; many different small but relevant catalog names need to be included in the customization; Grant uses the old "Gliese" naming for the identical catalog designation that SIMBAD and I call GJ (= Gliese+Jahreiss ) , just to name a few of such "little" complexities. I surely know from my respective Perl code that it is very easy to forget an exception here and there ...

On the level of the component stars, the amount of incompatible naming diversification is even much larger.

Notably, the HIP designation is NOT a consistent naming at the component level, basically since the HIP catalog is not specializing on separating multiple stars. For now, however, the multiple star browser lists the components NOT the barycenters. ONLY the latter include the HIP, HD,SAO entries as a matter of consistency. So your example above is not feasible in the manner you suggested in the attachment.

Yes, almost EVERYTHING can be programmed and all these irregularities can be accounted for, of course. But in my view there are quite a few tasks on our todo list, before time would be available for such a more sophisticated customization.

However, there may be much simpler ways that might satisfy much of what you'd like to have. The simplest would be to display the entire name string in the browser, instead of just the first entry. The "non-leading" names would be automatically clipped in the display and replaced by a ... . By temporarily adjusting the browser's first column width with the mouse (a standard Qt feature), most entries of the name string could then be inspected.

Another "easy" feature could be to simply add a little widget (1 line) in the browser that allows to scroll through all alternate names of a selected multiple star.

Fridger

[Chuft-Captain]

Programming and testing a totally flexible customized name display scheme, as you seem to suggest, constitutes no doubt a considerable programming effort compared to your simplistic WE example above. Reasons are that the strings don't have the same number of alternate name elements and even involve different acronyms in different input catalogs: there are plenty of stars without a CCDM, HIP, HD, SAO,... entry; many different small but relevant catalog names need to be included in the customization; Grant uses the old "Gliese" naming for the identical catalog designation that SIMBAD and I call GJ (= Gliese+Jahreiss ) , just to name a few of such "little" complexities. I surely know from my respective Perl code that it is very easy to forget an exception here and there ...

I had assumed that the catalog strings had already been parsed at start-time and the constituents loaded as separate attributes of the stellar class.
If that was the case, then my example above (or some alternate version) would be very straight-forward to implement by simply accessing those attributes, however reading from what you say, it seems that this is not the case, and that in fact the full string is simply being loaded in raw un-parsed form, and therefore the class has never had separate attributes for the different classification schemes.

CC

[t00fri]

CC,

the starname column in the Qt browser gets the star names from Celestia's star database (stardb.cpp) for a given catalog number. Right now the following is entered into the first name column:

Code: Select all

The name for the star with specified catalog number.  The returned
string will be:

-- the common name if it exists, otherwise
-- the Bayer or Flamsteed designation if it exists, otherwise
-- the HD catalog number if it exists, otherwise
-- the HIPPARCOS catalog number.


Note this is a general starname extraction method. Since in case of multiple stars, the HIP, HD numbers are only associated with the barycenter and NOT with the displayed components, you will usually not get a HIP/HD display from this method.

You did not at all comment about my two much simpler options for alternative name outputs in my previous post! Did you overlook them or did you dislike them?

For your info, I quickly coded the first option that I discussed. Here is a screenshot, after temporarily increasing the width of the first column with the mouse:



Instead of just displaying the single name hierarchy as specified above, I now display the full list of component names with a maximum of 4 items. The latter max number may be changed of course. The width of the 1st column can be anytime reduced or modified according to personal gusto.

Fridger

PS: note the pro-level CCDM entries (Catalogue of the Components of the Double and Multiple stars) are essential for a scientific cross referencing of multiple star components. The CCDM naming is almost synonymous with the WDS designations (Washington Double Star catalog). Unlike HIP numbers, the CCDM/WDS nomenclature is uniquely associated with the multiple star components

[Chuft-Captain]

You did not at all comment about my two much simpler options for alternative name outputs in my previous post! Did you overlook them or did you dislike them?

Neither. I understood the "little complications" and therefore considered your suggestion to be a reasonable compromise under the current constraints. Any further comment by me would have been superfluous.
(.. and what you've quickly coded seems to be a reasonable workaround given the constraints). -- The main aim I guess is to be reasonably consistent between what's displayed in the Browser versus what's displayed on the top of the screen.

The only comment I would add is to say that in the long term it might be worth considering whether extraction and "normalization" of the catalog data at load time into the runtime structures, would give a lot more flexibility for different display formats including user customization in the future (as well as save on coding time in those situations). -- "re-construction" is easier than "destruction"

CC