Re: Three thoughts

[Lincoln Peters <sampln at sbcglobal dot net>]

On Mon, 2004-08-23 at 09:40, Eric McDonald wrote:
> On Sun, 22 Aug 2004, Lincoln Peters wrote:
> 
> > Here's a rather crazy possible solution: Would it be possible to use
> > TclTk *and* another toolkit, such as GTK+, simultaneously?  That might
> > allow us to not only use GTK+ to implement new features, but also to
> > "phase out" the TclTk code (since nobody seems to like TclTk anymore)
> > and replace it with GTK+ code.
> 
> I think it would be possible, but probably would be rather 
> hackish. Both Tk and GTK+ have their own window hierarchies, and 
> that would require a fair amount of bookkeeping on Xconq's part, 
> to make sure that focus gets restored after a window closes, 
> etc....
> 
> Also, the "widget styles" of the two toolkits are a bit different 
> and so the resulting UI would end up looking like Frankenstein, I 
> think.

I'm not familiar with TclTk's (Tk's?) "widget style".  Does it work
based on a grid, where widgets are positioned by coordinates rather than
through the use of containers (horizontal and vertical boxes, tables,
etc.; as per GTK+)?  From the references I can find on the Web, it looks
like Tk can use containers in a manner similar to GTK+, but it has only
had that feature since version 8.4.

Would Xconq look any worse if it used Tk code and GTK+ code
simultaneously than it looks now?  As I see it right now, we have three
possibilities:

Current TclTk interface:	ugly and unintuitive
Proposed GTK+ interface:	more intuitive than TclTk, but would look like
an Office app
In-development SDL interface:	looks cool, more intuitive than TclTk, but
more work to develop than the first two

Over the long term, it might be worthwhile to try to develop a common UI
based on SDL and GTK+/GNOME, since SDL could provide a more game-like
(i.e. less Office-app-like) interface and GTK+ could provide a bunch of
features where it doesn't particularly matter if they look like they
belong in an Office app.  For example, I think it would be fairly simple
to implement the Xconq "Welcome" screen using a GNOME Druid.

> 
> Your idea does have the merits you suggest, though. 
> Interesting....

There might be a few hardcore strategy gamers who would appreciate being
able to use Mono to link Xconq to a spreadsheet application and do some
intensive data analysis on games like advances.g (e.g. track production,
technology, offensive/defensive power, over time).  Of course, there are
a *lot* of other things to deal with before worrying about spreadsheet
applications!

Perhaps it would be possible to avoid the "hackish" aspect of using
TclTk and GTK+ simultaneously by completely switching from TclTk to GTK+
in one fell swoop, but that idea is probably even more scary for most
developers.  The closest I'd expect us to reasonably come to that
scenario would be to implement GTK+ as a separate interface and then
label the TclTk interface as a "legacy" interface.

> 
> > The situation illustrated here is the city Sausalito and a fighter
> > flying overhead.  Within the city are infantry, armor, a bomber, a
> > battleship, and a carrier.  
> 
> If the ship types corresponded to U.S. Navy naming conventions, I 
> think you would have two carriers and zero battleships. Not that 
> it really matters....

Honestly, I just used the names of the first two ships from "Star Trek"
that I could think of.  Last night, a local TV station ran "Star Trek
IV: The Voyage Home"

> 
> The closup view window that you propose is an interesting idea, 
> but I agree that we should try to avoid extra work to fish out an 
> unit, if possible (as someone mentioned in a later message in 
> this thread).  One idea that I thought of would be magnify the 
> icon of an unit if the cursor passes over it in a manner similar 
> to that little bar of icons at the bottom of the MacOS X 
> interface (IIRC). Or maybe that magnification should only happen 
> when a modifier key is being pressed when the mouse passes over 
> the unit, so that the magnified view does not normally get in the 
> way of other units in the same hex (and possibly surrounding 
> hexes).

Magnification as per the MacOS X dock would be a possibility, but an
awkward one.  Unless you have an intuitive way for the user to indicate
when to zoom and when not to zoom, the user might be rather surprised
when the mouse hovers over a cell and one unit suddenly gets bigger
while the others get smaller.  Of course, if you don't want to shrink
the unit images, you'd probably have to shrink the neighboring hexes...

In conclusion, this kind of zooming is probably more work than you had
in mind.

Another possibility might be to make the close-up dialog be a separate
window that displays each unit in the same arrangement as on the main
screen, but it draws every unit in the cell at the same size.  Something
like:

http://homepage.mac.com/lmpeters/cell_closeup2.png

(As before, I'm limited to the GTK+/GNOME stock icons, none of which
look like an Xconq unit, unless I write some actual UI code.)

---
Lincoln Peters
<sampln@sbcglobal.net>

"Conversion, fastidious Goddess, loves blood better than brick, and feasts
most subtly on the human will."
-- Virginia Woolf, "Mrs. Dalloway"