[Tfug] Wallpaper criteria

[Bexley Hall]

Hi John,

On 1/9/2013 5:27 AM, John Gruenenfelder wrote:
> On Wed, Jan 9, 2013 at 3:12 AM, Bexley Hall<bexley401 at yahoo.com>  wrote:

>>> Ever since I learned about it, I've been using Xplanet to generate my
>>> background.  Over time, I've attempted to collect the best imagery I
>>> could find for this purpose.  Primarily, this means very high
>>> resolution maps of day and night Earth, as well as the best images I
>>> could find of the other planetary bodies.
>>
>> I run xearth on my software development workstations.  It seems
>> to fit the criteria I outlined previously (dark, no hot spots,
>> etc.) *and* has the added benefit of acting like a "clock" for
>> me (showing me a Sun's view of Earth so I can just watch to see
>> where it is currently "noon" to get an idea of what the local
>> time is).
>>
>> This works well for single monitor use or "X-in-a-window" but
>> not well for multiple monitor use (too much "outer space")
>
> The simplest explanation is that Xplanet is like xearth on steroids.

Well, the imagery sure is a lot finer/prettier!  Xearth is really
just a shaded blue globe with green landmasses patched onto it.  But,
good in terms of "not very busy", "dark" and "no bright spots".

> As its name implies, it can display any object in the solar system for
> which you have a map image.  Various options let you control where the
> viewer is and what they are viewing.  So, you could view the Earth as
> seen from the Sun, or view Saturn as seen by an observer on the Moon,
> etc.

Understood.

>> Agreed.  Especially in the case of xearth where there is very
>> little detail besides outlines of continents and city names.
>
> Since Xplanet lets you control precisely which map images are used and
> also allows "arc" files, you could feed Xplanet a very simple map of
> the Earth and apply the provided borders arc file so you can see the
> political boundaries.

OK.

>>> To make this ordeal easier to manage, I created a set of regular
>>> Bourne shell scripts (i.e. no bash extras) to handle all of the
>>> downloading, processing, and handling of program options.  They are
>>> limited in some ways as they really only address use cases that I have
>>> dealt with personally.  For example, the scripts support one or two
>>> screens, and can display a different object on each screen, or,
>>> optionally, one object can be replaced by a 'triple' which displays
>>> three objects instead of one.
>>
>> For example?  (i.e., why?)
>
> Uh, why what?  Why are the available modes the only ones available?
> As I said, with little to no feedback these scripts solve and/or
> simplify the ways in which I personally have been using Xplanet.

Grrrr... sorry, I was too vague, there.  I was refering to the "triple".
I.e., what sort of "three objects" (earth moon sun)?  And, why would
you choose three objects instead of *one*?

I'm just trying to understand what the user would *see* in these cases.
E.g., watching the terminator traverse the planet tells you time of day.
Looking at (sun,earth,moon) would, as well -- and, if you were *really*
observant, perhaps (calendar) month of year as well as time of (lunar)
month??

[Hmmm... I need to rethink this -- you mean three *related* objects.
I.e. sharing the same "outer space".  *Not* three images "tiled"
side by side!]

>>> They make some assumptions, however,
>>> like assuming that the user will always want the Earth to be one of
>>> the objects and therefore the scripts always attempt to download the
>>> most recent (every 12 hours) cloud map.  I've also never dealt with a
>>> situation where I wanted a different image on each desktop/pane so the
>>> scripts don't handle that.
>>
>> Ah, OK.  That's far more detailed than what xearth presents.  (it also
>> requires the machines to have access to the outside world -- something
>> that I don't allow development machines to do!  :<  )
>>
>> Great!  I'll take a look at it.  I can always download *one* set
>> of imagery and live with it "forever", right?
>
> Well, to be more precise, it is my scripts which require Net access to
> fetch the cloud map, the current satellite TLE files, and some
> time-dependent data files downloaded by the TotalMarker helper tool,
> in particular the locations and tracks of any storms of tropical
> depression size or larger.  Xplanet then makes use of these various
> data files to add features to the image.

So, the two *could* be "decoupled".  I.e., xplanet just refreshing
it's idea of "what to use/what to do" by reading a set of files
*dropped* in a particular location, "whenever" -- the interface
isn't strictly "synchronous" (where xplanet *tickles* your
scripts, they do their thing and "return" their results to
xplanet so that it can "continue")

I.e., I could conceivably run the scripts from another "connected"
host and sneakernet the resulting portion of the filesystem over
to the machine(s) in question -- with the obvious understanding that
the imagery would not change between updates ("Gee, that same storm
has been parked over New England for several *months*!!"  :>)

> As they stand now, the scripts allow you to turn off all of the
> features requiring Net access with the exception of the cloud map.
> There is no good reason for that; it's just something I've never
> gotten around to.
>
>>> Oh, and if you'd like to see what my wallpaper looks like right about
>>> now, you can see it at:
>>>     http://bach.as.arizona.edu/~johng/files/xplanet-wallpaper.jpg
>>
>> So, it shows the earth from a vantage point above a fixed location
>> (e.g., beantown) instead of from a fixed point in space.
>
> Yes, with my particular settings (all changeable), the viewer is
> placed directly above latitude 25 deg. and longitude -72 deg. at a
> height of 10 Earth radii from the Earth.  I don't know offhand, but
> given how many options Xplanet has, I wouldn't be surprised if there
> is some method for specifying an arbitrary point in space.

Yes, that's how xearth works.  We have adopted different approaches
to what we want to "see":  you prefer a static earth with dynamic
illumination changes (e.g., so that you can see what portion of the
day it is in a given location) whereas I prefer static illumination
(it's always "noon" -- somewhere!  :> ) with a dynamic earthscape.

[Are you in beantown, now?  I had thought you had returned (permanently)
to Tucson?]

>>> The brightness on the left is the Sun just about
>>> to appear and it will take just over an hour and a half to move across
>>> the screen entirely.
>>
>> ?? Why?  Doesn't it show the current terminator?
>
> Just a matter of timing.  If you can see the Sun pass directly behind
> the Earth then the terminator is necessarily perpendicular to the
> observer.  If I were looking at my desktop at, say, 2PM, then I would
> definitely see the terminator slowly moving from East to West,  And,
> of course, my view settings are on a fixed point on Earth.  If I
> alternatively chose to view from a fixed point like the Sun, then I
> would see the rotation of the Earth and little, if any,  movement of
> the terminator.

Understood.  My comment is why "an hour and a half"?  This suggests
your earth is rotating faster than normal?  (??)  Maybe I don't
understand what you're saying...

E.g., in my setup, it takes 24 hours for Tucson to reappear in the
center of the display -- "high noon".

>> My original request was for something largely *static*.  So that I
>> can get the Windows machines to resemble the UN*X desktops better
>> I.e., I can "86" xearth in favor of a static image on the UN*X
>> desktops and apply that same sort of imagery to the Windows desktops.
>> I'm trying to get some sort of uniformity to my workspaces that
>> is easier to maintain and, more importantly, that I can relate to.
>
> There is a port of Xplanet for Windows, though obviously you couldn't
> use the scripts I wrote nor most of the tools they rely on.

So, it works just by updating a static wallpaper image instead of
"writing on the root window"?

>> With lots of physical screens and virtual desktops, this quickly gets
>> daunting!  (e.g., imagine opening an X server on a Windows machine to
>> a Solaris client. etc.  "Now which CD-ROM drive do I need to put this
>> disk in??"  :-/ )
>>
>> Different *planets* might be a good theme -- though I'm not sure I
>> could differentiate the surface of Mars from that of Venus!  :-/
>
> Indeed, it does start to get confusing quickly if your images are not
> sufficiently different from one another.  Fortunately, in the case you
> mention, telling the difference should be easy.  Mars is red.  Very
> red.  Venus, on the other hand, is entirely opaque and the surface
> cannot be seen at all.  It has a beige-greenish color.  In general,
> all of the planets are sufficiently different that they you shouldn't
> have trouble telling them apart.  A number of the Jovian and Saturnian
> moons are also quite unique looking.

Understood.  And, over time, I suspect I would be able to
"subconsciously" notice and recognize them (e.g., "I was editing
that file on the Io screen").

[Watch your mbox for a PM followup -- too much to post, here]

> Well...  what the hell.  That's all the encouragement (or lack
> thereof) that I need.  :)
>
> I'll be back in a few days with version 3.0 of the scripts which will
> make all Net using features optional, make no assumptions about what
> object the user wants to view, and will no longer assume that the
> final outcome is a wallpaper that should be displayed immediately.
> Instead, you will be able have the scripts stop as soon as the
> wallpaper image file is generated.

Just make the scripts part of a larger script that exits with a
return code that tells the caller how far it got:  success,
failed to connect to network, failure of one of the internal
conversion tools, etc.  So, you know whether to retry the
"super script" later (when connected to the outside world)
or if you need to investigate something scwoo-wy within the
script.

(Being able to *resume* a prematurely terminated script is probably
not worth the effort as too many things can change -- "not atomic".
E.g., you fetch the balance of the cloud cover imagery a few hours
later and the continents have "moved" since the earlier portion
of the job ran  :> )

Let user embed *this* script in his own script so he can prepend
any necessary actions to execute before yours -- as well as followup
with post processing that should *follow* yours.  E.g., that
post processing may be as simple as copying/moving the files
from the staging area to a place where xplanet *expects* to find
them and SIGHUP'ing (or whatever) xplanet to cause it to reexamine
them.

> If you, or anybody else, has additional ideas, now is the time to speak up.

I'll have to build a clean UN*X box that I can run those on (I only
let this Windows machine talk to the outside world) -- but, No Big
Deal (TmReg)

Thx,
--don