This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Three thoughts
Lincoln Peters wrote:
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".
You're reading too much into what I meant by "widget style" (which was
in parentheses for a reason). Perhaps another way to put it is simply,
look-n-feel.
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.
Well, it was not too long ago that I revived this suggestion (having
first made it during the Great Flame War of November 2003), and some of
those who read it infused assumptions into its implications, such as
that I would recommend using GTK components without "redecorating" them
to fit their environment. It took a while to untangle that thread, and I
would rather not go there again any time soon.
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).
These are some of the benefits that crossed my mind as well when we last
discussed this (last year).
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.
I have thought about this on and off in the past few weeks. After
reviewing the SDL API and GTK API, and looking at the existing SDL code,
I think that I am going to give SDL a try first. (After reading portions
of both API's yesterday, I actually did sit down and fix some bugs in
the SDL app.)
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).
Unless you have an intuitive way for the user to indicate
when to zoom and when not to zoom,
See my suggestion above about pressing a modifier key.
the user might be rather surprised
when the mouse hovers over a cell and one unit suddenly gets bigger
while the others get smaller.
Well, I never suggested that other get smaller....
Does the MacOS X icon bar have that property?
I was just thinking in terms of making one image larger than the others,
and then partially or totally obscuring its neighbors for the duration
of the magnification.
In conclusion, this kind of zooming is probably more work than you had
in mind.
I didn't have any amount of work in mind. It was just a suggestion. But,
now that you mention it, I am not sure that it would be so much work.
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.
I think that is what Elijah and Matthew were suggesting (or something
similar), and it is certainly what I had in mind until the "icon
magnification" idea occurred to me.
http://homepage.mac.com/lmpeters/cell_closeup2.png
404.
Eric