rails-devel

[Rails-devel] Splitting up the OR window.

[Erik V. <eri...@xs...>]

Today I found the following new feature request #3439190 in Sourceforge (by
Anonymous, dated 2011-11-16):

"Detach company list from map.

Currently, the map window also contains the list of companies.
While the motivation for having this is clear (user needs this information
simultaneously), there are constellations for which this is not desired:
I use two monitors (left-right) and have plenty of space horizontally.
Therefore, I'd prefer to have the list of companies left or right of the
map.
The proposed solution would be to detach the company list and put it into a
stand-alone window (or detach the map analogously)."

I replied as follows:

"Originally, Rails had separate windows for the map and the OR status panel.
Brett Lentz has combined the two already in a pretty early stage.

Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
really annoying having these two screens joined, because the whole OR Window
now is too high, and always resizes that way at the start of a new OR (I
don't know how to fix that).
So I'm all for a split-up."

Opinions?

Erik.

Re: [Rails-devel] Splitting up the OR window.

[brett l. <bre...@gm...>]

I'd like more layout options, especially the ability to configure what
is or isn't contained within a single window. However, I think that
this feature request could be considered pretty low priority.

IMO, adding support for new games and networked play are probably far
higher on the "most wanted" list.

---Brett.



On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
> Today I found the following new feature request #3439190 in Sourceforge (by
> Anonymous, dated 2011-11-16):
>
> "Detach company list from map.
>
> Currently, the map window also contains the list of companies.
> While the motivation for having this is clear (user needs this information
> simultaneously), there are constellations for which this is not desired:
> I use two monitors (left-right) and have plenty of space horizontally.
> Therefore, I'd prefer to have the list of companies left or right of the
> map.
> The proposed solution would be to detach the company list and put it into a
> stand-alone window (or detach the map analogously)."
>
> I replied as follows:
>
> "Originally, Rails had separate windows for the map and the OR status panel.
> Brett Lentz has combined the two already in a pretty early stage.
>
> Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
> really annoying having these two screens joined, because the whole OR Window
> now is too high, and always resizes that way at the start of a new OR (I
> don't know how to fix that).
> So I'm all for a split-up."
>
> Opinions?
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Splitting up the OR window.

[Stefan F. <ste...@we...>]

Erik & Brett:
I support allowing to split up Map and Company window. If there is a valid 
reason to keep them together, add a configuration for that. I am wondering if 
we could add another yes/no option to combine the Player and Company window, 
that would be optimal for a two-screen setup, that I am using myself here.

A more general approach is to add a docking framework, which would allow user 
to drag and drop panels as they like.
However from my (limited) knowledge there seems to be not a clear choice which 
swing docking library to select if any. 

And I am not even sure that I would still choose Swing for a rewrite of the 
user interface. I would prefer something from the ajax/gwt/jquery et.al. 
world. This would ease migration to allow play on mobile devices and have the 
server part of the cloud (e.g. using the google AppEngine). 

From my point of view google really replaced sun as the company which  
supports and encourages the java cross-platform idea most.
And just in time before it was too late...

But for now: I would like the idea of map and company panel separated.

Stefan


On Thursday, November 24, 2011 02:09:07 pm brett lentz wrote:
> I'd like more layout options, especially the ability to configure what
> is or isn't contained within a single window. However, I think that
> this feature request could be considered pretty low priority.
> 
> IMO, adding support for new games and networked play are probably far
> higher on the "most wanted" list.
> 
> ---Brett.
> 
> On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
> > Today I found the following new feature request #3439190 in Sourceforge
> > (by Anonymous, dated 2011-11-16):
> > 
> > "Detach company list from map.
> > 
> > Currently, the map window also contains the list of companies.
> > While the motivation for having this is clear (user needs this
> > information simultaneously), there are constellations for which this is
> > not desired: I use two monitors (left-right) and have plenty of space
> > horizontally. Therefore, I'd prefer to have the list of companies left
> > or right of the map.
> > The proposed solution would be to detach the company list and put it into
> > a stand-alone window (or detach the map analogously)."
> > 
> > I replied as follows:
> > 
> > "Originally, Rails had separate windows for the map and the OR status
> > panel. Brett Lentz has combined the two already in a pretty early stage.
> > 
> > Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
> > really annoying having these two screens joined, because the whole OR
> > Window now is too high, and always resizes that way at the start of a
> > new OR (I don't know how to fix that).
> > So I'm all for a split-up."
> > 
> > Opinions?
> > 
> > Erik.
> > 
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Splitting up the OR window.

[brett l. <bre...@gm...>]

Comments inline...

On Thu, Nov 24, 2011 at 9:16 AM, Stefan Frey <ste...@we...> wrote:
> Erik & Brett:
> I support allowing to split up Map and Company window. If there is a valid
> reason to keep them together, add a configuration for that. I am wondering if
> we could add another yes/no option to combine the Player and Company window,
> that would be optimal for a two-screen setup, that I am using myself here.
>
> A more general approach is to add a docking framework, which would allow user
> to drag and drop panels as they like.

I would *far* prefer this over making a single arbitrary change.
There's a high probability that while some users may like the new
layout, some will prefer the current layout and we'd be upsetting that
portion of the userbase by forcing an unwanted change on them.

So, if we're going to do anything, it needs to *add* functionality,
not simply change it for something that's different, but not
objectively better.

I'd also remind you that dual monitors are *not* the norm, so we'd be
moving *away* from a layout that best accommodates the majority of
players. That just strikes me as moving in the wrong direction. We're
already a niche hobby, there's nothing to be gained by further
reducing our userbase.

> However from my (limited) knowledge there seems to be not a clear choice which
> swing docking library to select if any.
>

Anybody with the right combination of time and interest is welcome to
investigate and/or start putting prototypes together. :-)

> And I am not even sure that I would still choose Swing for a rewrite of the
> user interface. I would prefer something from the ajax/gwt/jquery et.al.
> world. This would ease migration to allow play on mobile devices and have the
> server part of the cloud (e.g. using the google AppEngine).
>

Eh. I'm not a fan of ajax and jquery. Unless there's a compelling
feature/function that add significant value, I see no reason to go
from a single language (Java) to multiple languages (Java +
ECMAScript). I've worked on projects that are split across several
languages, and it quickly becomes a larger maintenance burden than
it's really worth and makes it difficult for new people to contribute.

If we want to support Android, we're already using the right language.
It's really a matter of just adapting our code from the stock JVM to
Dalvik's API, and getting the APK builds going. The bulk of the work
would be presenting a UI that would work on a phone/tablet screen.

That said... Supporting running game servers in the cloud is a great
idea. I'd have no problems if we wanted to try hosting game servers
out of OpenShift (https://openshift.redhat.com/app/). Keeping the
OpenShift servers running is sort of my day job. ;-)

---Brett.

> >From my point of view google really replaced sun as the company which
> supports and encourages the java cross-platform idea most.
> And just in time before it was too late...
>
> But for now: I would like the idea of map and company panel separated.
>
> Stefan
>
>
> On Thursday, November 24, 2011 02:09:07 pm brett lentz wrote:
>> I'd like more layout options, especially the ability to configure what
>> is or isn't contained within a single window. However, I think that
>> this feature request could be considered pretty low priority.
>>
>> IMO, adding support for new games and networked play are probably far
>> higher on the "most wanted" list.
>>
>> ---Brett.
>>
>> On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
>> > Today I found the following new feature request #3439190 in Sourceforge
>> > (by Anonymous, dated 2011-11-16):
>> >
>> > "Detach company list from map.
>> >
>> > Currently, the map window also contains the list of companies.
>> > While the motivation for having this is clear (user needs this
>> > information simultaneously), there are constellations for which this is
>> > not desired: I use two monitors (left-right) and have plenty of space
>> > horizontally. Therefore, I'd prefer to have the list of companies left
>> > or right of the map.
>> > The proposed solution would be to detach the company list and put it into
>> > a stand-alone window (or detach the map analogously)."
>> >
>> > I replied as follows:
>> >
>> > "Originally, Rails had separate windows for the map and the OR status
>> > panel. Brett Lentz has combined the two already in a pretty early stage.
>> >
>> > Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
>> > really annoying having these two screens joined, because the whole OR
>> > Window now is too high, and always resizes that way at the start of a
>> > new OR (I don't know how to fix that).
>> > So I'm all for a split-up."
>> >
>> > Opinions?
>> >
>> > Erik.
>> >
>> >
>> > -------------------------------------------------------------------------
>> > ----- All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Splitting up the OR window.

[brett l. <bre...@gm...>]

Oh... one other note on the OpenShift front...

I know that we talked about Continuous Integration a while back. Well,
there's pre-built support for Jenkins (aka. Hudson) in OpenShift, if
anybody is interested in taking advantage of that for Rails.

http://www.javaworld.com/javaworld/jw-11-2011/111115-red-hat-open-shift.html

---Brett.




---------- Forwarded message ----------
From: brett lentz <bre...@gm...>
Date: Thu, Nov 24, 2011 at 12:12 PM
Subject: Re: [Rails-devel] Splitting up the OR window.
To: "Development list for Rails: an 18xx game"
<rai...@li...>


Comments inline...

On Thu, Nov 24, 2011 at 9:16 AM, Stefan Frey <ste...@we...> wrote:
> Erik & Brett:
> I support allowing to split up Map and Company window. If there is a valid
> reason to keep them together, add a configuration for that. I am wondering if
> we could add another yes/no option to combine the Player and Company window,
> that would be optimal for a two-screen setup, that I am using myself here.
>
> A more general approach is to add a docking framework, which would allow user
> to drag and drop panels as they like.

I would *far* prefer this over making a single arbitrary change.
There's a high probability that while some users may like the new
layout, some will prefer the current layout and we'd be upsetting that
portion of the userbase by forcing an unwanted change on them.

So, if we're going to do anything, it needs to *add* functionality,
not simply change it for something that's different, but not
objectively better.

I'd also remind you that dual monitors are *not* the norm, so we'd be
moving *away* from a layout that best accommodates the majority of
players. That just strikes me as moving in the wrong direction. We're
already a niche hobby, there's nothing to be gained by further
reducing our userbase.

> However from my (limited) knowledge there seems to be not a clear choice which
> swing docking library to select if any.
>

Anybody with the right combination of time and interest is welcome to
investigate and/or start putting prototypes together. :-)

> And I am not even sure that I would still choose Swing for a rewrite of the
> user interface. I would prefer something from the ajax/gwt/jquery et.al.
> world. This would ease migration to allow play on mobile devices and have the
> server part of the cloud (e.g. using the google AppEngine).
>

Eh. I'm not a fan of ajax and jquery. Unless there's a compelling
feature/function that add significant value, I see no reason to go
from a single language (Java) to multiple languages (Java +
ECMAScript). I've worked on projects that are split across several
languages, and it quickly becomes a larger maintenance burden than
it's really worth and makes it difficult for new people to contribute.

If we want to support Android, we're already using the right language.
It's really a matter of just adapting our code from the stock JVM to
Dalvik's API, and getting the APK builds going. The bulk of the work
would be presenting a UI that would work on a phone/tablet screen.

That said... Supporting running game servers in the cloud is a great
idea. I'd have no problems if we wanted to try hosting game servers
out of OpenShift (https://openshift.redhat.com/app/). Keeping the
OpenShift servers running is sort of my day job. ;-)

---Brett.

> >From my point of view google really replaced sun as the company which
> supports and encourages the java cross-platform idea most.
> And just in time before it was too late...
>
> But for now: I would like the idea of map and company panel separated.
>
> Stefan
>
>
> On Thursday, November 24, 2011 02:09:07 pm brett lentz wrote:
>> I'd like more layout options, especially the ability to configure what
>> is or isn't contained within a single window. However, I think that
>> this feature request could be considered pretty low priority.
>>
>> IMO, adding support for new games and networked play are probably far
>> higher on the "most wanted" list.
>>
>> ---Brett.
>>
>> On Thu, Nov 24, 2011 at 7:45 AM, Erik Vos <eri...@xs...> wrote:
>> > Today I found the following new feature request #3439190 in Sourceforge
>> > (by Anonymous, dated 2011-11-16):
>> >
>> > "Detach company list from map.
>> >
>> > Currently, the map window also contains the list of companies.
>> > While the motivation for having this is clear (user needs this
>> > information simultaneously), there are constellations for which this is
>> > not desired: I use two monitors (left-right) and have plenty of space
>> > horizontally. Therefore, I'd prefer to have the list of companies left
>> > or right of the map.
>> > The proposed solution would be to detach the company list and put it into
>> > a stand-alone window (or detach the map analogously)."
>> >
>> > I replied as follows:
>> >
>> > "Originally, Rails had separate windows for the map and the OR status
>> > panel. Brett Lentz has combined the two already in a pretty early stage.
>> >
>> > Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
>> > really annoying having these two screens joined, because the whole OR
>> > Window now is too high, and always resizes that way at the start of a
>> > new OR (I don't know how to fix that).
>> > So I'm all for a split-up."
>> >
>> > Opinions?
>> >
>> > Erik.
>> >
>> >
>> > -------------------------------------------------------------------------
>> > ----- All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Splitting up the OR window.

[John D. G. <jd...@di...>]

> "Originally, Rails had separate windows for the map and the OR status panel.
> Brett Lentz has combined the two already in a pretty early stage.
> 
> Personally, I would have left these apart. Sometimes (e.g. in 1835) it's
> really annoying having these two screens joined, because the whole OR Window
> now is too high, and always resizes that way at the start of a new OR (I
> don't know how to fix that).
> So I'm all for a split-up."
> 
> Opinions?

I would like to see the lists of companies removed from both the map window and
the Game Status window, to become a new window I would call Company Actions.
(The remainder of the Game Status window would be Player Actions.)

Like Erik, my main motivation is the annoying tendency of the map window to
resize itself before and during operating rounds.  So maybe it would be better,
as well as simpler, just to implement a decree that once the game begins, no
window shall ever move or resize itself except manually.  If a window suddenly
needs to display data that won't fit within its existing area (as when new
companies form), let it sprout scroll bars instead of changing size.

Re: [Rails-devel] Splitting up the OR window.

[Erik V. <eri...@xs...>]

A few somewhat belated answers.

> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, November 24, 2011 3:16 PM
> 
> I support allowing to split up Map and Company window. If there is a valid
> reason to keep them together, add a configuration for that. I am wondering
> if we could add another yes/no option to combine the Player and Company
> window, that would be optimal for a two-screen setup, that I am using
> myself here.

The split itself wouldn't be easy (as the past join has proved), making it
optional would complicate matters even more.
In any case, quite some UI refactoring would be needed. 
Anyway, I was only collecting opinions, I have no plan to work on such a
split (yet).

> A more general approach is to add a docking framework, which would allow
> user to drag and drop panels as they like.
> However from my (limited) knowledge there seems to be not a clear choice
> which swing docking library to select if any.

A few years ago, someone announced to start working on an Eclipse version.
That's the last thing I heard about that (nice) idea.

> And I am not even sure that I would still choose Swing for a rewrite of
the
> user interface. I would prefer something from the ajax/gwt/jquery et.al.
> world. This would ease migration to allow play on mobile devices and have
> the server part of the cloud (e.g. using the google AppEngine).

Personally, I'd rather see *additional* user interfaces than a complete
replacement.  

> From: John David Galt [mailto:jd...@di...]
> Sent: Friday, November 25, 2011 12:55 AM
> 
> I would like to see the lists of companies removed from both the map
> window and the Game Status window, to become a new window I would call
> Company Actions.
> (The remainder of the Game Status window would be Player Actions.)

I'm not sure if this idea appeals to me.  One result would be, that all
share-trading *player actions* would have to be executed in the *company
actions* window.
Admittedly, most of the quite substantial overlap between the two windows
would be removed, but I'm not sure if that overlap is such a bad thing.
 
> Like Erik, my main motivation is the annoying tendency of the map window
> to resize itself before and during operating rounds.  So maybe it would be
> better, as well as simpler, just to implement a decree that once the game
> begins, no window shall ever move or resize itself except manually.  If a
> window suddenly needs to display data that won't fit within its existing
area
> (as when new companies form), let it sprout scroll bars instead of
changing
> size.

That's on my wish (and potential to-do) list.

Erik.

Re: [Rails-devel] Splitting up the OR window.

[Stefan F. <ste...@we...>]

Erik: see comments below

> > A more general approach is to add a docking framework, which would allow
> > user to drag and drop panels as they like.
> > However from my (limited) knowledge there seems to be not a clear choice
> > which swing docking library to select if any.
> 
> A few years ago, someone announced to start working on an Eclipse version.
> That's the last thing I heard about that (nice) idea.

Eclipse version means based on SWT (and potentially JFace)?
However this would imply to drop Swing. A Swing docking framework allows to 
keep existing code.

> 
> > And I am not even sure that I would still choose Swing for a rewrite of
> 
> the
> 
> > user interface. I would prefer something from the ajax/gwt/jquery et.al.
> > world. This would ease migration to allow play on mobile devices and have
> > the server part of the cloud (e.g. using the google AppEngine).
> 
> Personally, I'd rather see *additional* user interfaces than a complete
> replacement.
> 

The wording "Rewrite" intended to imply a new separate UI, that implies that 
it is additional. For this to work 

The main issue with the current approach is that in a few places it contains 
game logic and is tight closely to the non-UI core classes. This is especially 
true for tile/token lays and the UI classes for hexes and tiles.
Before we add another UI this coupling should be removed, otherwise there will 
be a code duplication. However I will not work on any of this 
before the Rails 2.0 has stabilized.

Re: [Rails-devel] Splitting up the OR window.

[brett l. <bre...@gm...>]

On Fri, Dec 2, 2011 at 7:19 AM, Stefan Frey <ste...@we...> wrote:
> Erik: see comments below
>
>> > A more general approach is to add a docking framework, which would allow
>> > user to drag and drop panels as they like.
>> > However from my (limited) knowledge there seems to be not a clear choice
>> > which swing docking library to select if any.
>>
>> A few years ago, someone announced to start working on an Eclipse version.
>> That's the last thing I heard about that (nice) idea.
>
> Eclipse version means based on SWT (and potentially JFace)?
> However this would imply to drop Swing. A Swing docking framework allows to
> keep existing code.
>
>>
>> > And I am not even sure that I would still choose Swing for a rewrite of
>>
>> the
>>
>> > user interface. I would prefer something from the ajax/gwt/jquery et.al.
>> > world. This would ease migration to allow play on mobile devices and have
>> > the server part of the cloud (e.g. using the google AppEngine).
>>
>> Personally, I'd rather see *additional* user interfaces than a complete
>> replacement.
>>
>
> The wording "Rewrite" intended to imply a new separate UI, that implies that
> it is additional. For this to work
>
> The main issue with the current approach is that in a few places it contains
> game logic and is tight closely to the non-UI core classes. This is especially
> true for tile/token lays and the UI classes for hexes and tiles.
> Before we add another UI this coupling should be removed, otherwise there will
> be a code duplication. However I will not work on any of this
> before the Rails 2.0 has stabilized.
>
>

I think we all agree that this part needs to be refactored, one way or
another. A cleaner MVC separation would make working on a lot of
things easier.

---Brett.

Re: [Rails-devel] Splitting up the OR window.

[Erik V. <eri...@xs...>]

> >> A few years ago, someone announced to start working on an Eclipse
> version.
> >> That's the last thing I heard about that (nice) idea.
> >
> > Eclipse version means based on SWT (and potentially JFace)?

Don't know.

> > The main issue with the current approach is that in a few places it
> > contains game logic and is tight closely to the non-UI core classes.
> > This is especially true for tile/token lays and the UI classes for hexes
and
> tiles.
> > Before we add another UI this coupling should be removed, otherwise
> > there will be a code duplication. However I will not work on any of
> > this before the Rails 2.0 has stabilized.
> >
> >
> 
> I think we all agree that this part needs to be refactored, one way or
another.
> A cleaner MVC separation would make working on a lot of things easier.

Absolutely.  The decoupling is far from complete yet.

Please note, that I have always coded from the principle, that the UI would
have direct access to all *static* object properties (a separate UI would
still load the same XML). 
(I know that this is controversial, and will probably be replaced by some
way to push static info to the UI.  But that's not my cup of tea. )
In the meantime, a lot of properties that were once thought to be static
have turned into state variables, so coupling might in fact have been
increased.

Erik.