On Fri, 28 Oct 2005, forrest@... wrote:
> Except that on the Windows version, at least last I looked, there is already
> an MML folder with several MML files that have to be in there in order for
> basic game defaults to be set. On the Mac version those defaults are built
> into the app itself and any MML files just override them, so on the Mac you're
> right, users could just move and replace, but on Windows, unless the scenario
> maker included all the needed default MML files in their MML folder too,
> they'd be overwriting with an MML folder missing some files that need to be
That's changed now. Starting with the upcoming release (0.15.0 for lack of
a better name), transparent sprites and liquids MML is no longer built
into the Mac OS X build. However, text strings and interface rects are now
built into all builds. So, you only need an MML folder to enable
transparent sprites and liquids. My guess is your scenario has its own
notions of sprite and liquid transparency, so replacing the default ones
(which are designed for infinity) should be just fine.
> Or maybe they don't need to be there. I don't have easy access to Windows
> boxen and have only played with Win AO briefly... saw those files were
> included and figured they needed to be there. Can they be safely trashed (or
> overwritten by a folder that doesn't include them, as the case may be)? What
> happens if there's no MML files in with Windows AO?
In previous releases, it would break. Which means you would have needed to
include our MML along with your scenario MML. But now, it's safe to
> Right, which is why I was asking all those GPL questions, as that's what I
> intend to do. Question about "support files" though - the Windows version of
> AO seems (again, last I looked) to come with a lot of not-so-well-organized
> documentation folders. I like to keep my folder structures all nice and clean.
> Do I have to include all the default documentation with it as well, or can I
> just include my own custom Eternal documentation? (I'd copy and paste the GPL
> text into a section of my documentation, of course).
The GPL and (I believe) LGPL need to be included as they are. I just put
Speex and various other libraries there because we use them; you'll have
to read them to find out if they really need to be included.
As for the non-library documentation, that describes how to use Aleph One,
if you think your documentation is better than ours, I'd humbly ask you to
rewrite ours :)
As far as not-well-organized, I have the libary licenses in a directory
called "Library Licenses" I believe, and the rest in the root. What would
> And an auto-update would rock. Is that in the works?
Not to my knowledge.
> Right, and I appreciate that. (Although I've actually seen it confuse Windows
> users a bit - "so I downloaded this and now I have a bunch of files in a
> folder, which one's the installer?" - but that's their fault, not yours).
I'd love to be able to link all those in statically. I've checked the
licenses and we would be perfectly OK creating one big DLL-free app. But,
mingw can't do it, and I can't afford Visual Studio .NET.
> Dynamic libraries and version control I can see, and that's the one
> questionable trade-off in my mind... it would suck if, say, every media app
> that used QuickTime had its own self-contained QT libs that had to be
> separately updated, instead of just updating it system-wide. But the flip side
> of that is, what if a new universal update breaks compatibility with something
> that needs the older version... I'm not sure what the ideal resolution of this
> conflict is and from what I understand it's still an open question in many
A lot of testing and a versioning convention seem to work OK for Linux,
although you rely on individual library developers a bit too much. Apple
hasn't quite got this figured out yet, obviously (*cough* quicktime 7).
And we all know about DLL hell :)
> As for "registries", and Start Menu equivalents, those all seem like bad OS
> design to me,
The Registry, as bad as it is, is much preferable to the piles of code
wasted on incompatible preferences handling in Mac OS apps from that time.
That Microsoft doesn't have the balls (or small, faithful Mac user base?)
to do what Apple did and say "OK, everybody out of the old pool and into
the new one" is most likely the reason it's still around, when superior
solutions like plists exist.
Gnome has a similarly disastrous (though at least somewhat human readable)
registry and no such excuse. And preferences handling in Linux as a whole
is a nightmare from a consistency standpoint.
But the idea of a registry has its roots in a sound concept: code reuse
and uniformity of preferences storage.
> though given that they exist I can see why developers would need
> to work around them. I'm not so much complaining that app developers USE
> installers for their programs, but that OS's necessitate the use of them. The
> registry is a big mess I won't even go into, but there's no sane reason (from
> a HCI perspective) why programs should be adding themselves to any 'favorites'
> type lists like the Start Menu: users should be able to drag things in or out
> of any such list as they please, like they do bookmarks in a browser or icons
> on the OSX Dock.
Of course, this is how the Start menu works in Windows. It serves a dual
purpose; you've got the part on top for your true favorites, and the
programs list of all your programs. Automatically adding itself to the
programs list (which is often optional depending on the installer) in no
way affects the customizations you have chosen for the rest. And, IMO,
it's an aid to novice users to display installed applications (especially
as they may not have set up the system, installed programs, or customized
> I don't want my programs telling ME that they're so
> important I need a shortcut to them. I'll tell them so myself if I deem that
> to be the case.
Whereas I think if you installed them, it's common sense that they appear
on the list of installed applications :)
Both are valid opinions and just the result of choices made during design.
> This same argument applies to default install locations - users should be able
> to be in control of how they organize their computers, and the computers
> should facilitate those users being in control, so the closest thing to a
> default install location should be an obvious folder called "Applications" or
> "Programs" where users will go "oh, that's a good place to keep my
> applications/programs" (since installation should be drag-and-drop anyway). My
> general UI rule of thumb: if you've got some system so obtuse and complex that
> it needs to be hidden behind some 'user-friendly' "wizard" or any such thing
> (in other words, that you've got to take direct control away from the user in
> order to keep them from screwing things up)... then your system is too complex
> and obtuse.
However, we choose to use systems this complex and obtuse. Because
we want the flexibility and power that accompanies complexity and
Where we have chosen to use limited capability appliances in place of our
personal computers, I'll grant you there should be no need for complex or
subtle interfaces. Witness well-designed game consoles, old-school desk
telephones, point and shoot cameras, and conventional automobiles.
> I understand that we're stuck with some complex and obtuse systems
Not so much, rather, we prefer them. Look at the success of PDAs, the
feature creep of the ipod and modern cell phones. I'm obviously not
*stuck* with any of these, since I don't own any.
> and this is the best solution we can patch on them now, but it's still
> just putting a band-aid over the problem.
It's not a problem: it's the result of a choice we collectively made. To
suggest it's a temporary solution, rather than a tool to deal with those
consequences, is naive. As long as computers are powerful general-purpose
devices (and incapable of thinking like human beings) we will require
wizards, metaphors, and other tools to help us interface with them.
> (And of course, uninstalllers and thus lists of un-installable programs are
> only necessary for the same reasons installers are necessary).
It is nice to see at a glance that you've still got World of Warcraft
installed when you need to free up 50 GB of disk space, or whatever it
takes, rather than searching through your filesystem at random for things
to delete :)
> I'm not so sure what you mean about finer grained control over permissions and
> understanding of the OS's security peculiarities. Perhaps you're assuming an
> OS where permissions and security are obtuse and difficult to understand and
> so users need to be hand-held by the installer.
> When dealing with such OS's you've got a point, but my complaint is that
> OS's are unfriendly enough to require such user-hand-holding, not that
> developers are kind enough to write installers to hold users hands as
> need be in such cases.
Security and convenience are inversely-related. Always. You may not have
to deal with a secure operating system now, but that time is coming.
Increasing complexity demands it. And fine-grained file permissions
(unless the OS attempts to modify things intelligently when drag copying a
folder...evil!) and configuration of no-execute bits, firewall settings,
is something that is better dealt with by installer scripts.
> Also, of note: I'm not being a platform purist or anything here, saying my
> platform of choice (OSX) is above any of these problems. It's got some issues
> along these lines that bother me too, I'm just fortunate enough to almost
> never encounter them, and from my experience it seems to have fewer such
> issues than its competitors in the first place.
I just felt the need, on a usability and friendliness front, to defend the
efforts of Microsoft's UI development team (but certainly not the policy
makers!) in dealing with a huge legacy user base, and Linux desktop
environment designers' efforts in dealing with a crippling moving target
of an underlying OS and a mainly-unpaid volunteer development force. Just
as I would defend to a non-Mac user Apple's efforts to provide a better
user experience by experimentation, even if it means taking a step
backwards from the polished (but by far less complex) UI they had before.
OS designers aren't inept. I think it's just an impossibility to make one
that fits everybody. Which is why we all use different ones :)
> You have a good point about removing a scenario being easier. Modularity is
> good. That's what I've been arguing though all the above, so I might as well
> stick to it here too.
By now I think you've seen some more details about our possible
enhancement to scenario handling :)
(whose current job is UI designer for a far-too-complex video phone)