TADS 3 mulitmedia proposal
Greg Boettcher
and I am posting my thoughts here now.
1.
In that thread, Adam Thornton mentioned the possibility of putting
together some money for whoever comes up with a multimedia TADS
interpreter for Mac OS X. I think that's a great idea, and I'd like to
get the ball rolling.
I am hereby offering $100 to whoever completes the first full HTML
TADS 2 and 3 interpreter for Mac OS X.
Furthermore, I'd like to encourage collaboration, rather than
competition. Therefore, if the interpreter in question is the result
of substantial collaboration, such that the cash would have to be
split between two or more people, then I would like to contribute $200
instead of $100, so that the money is not spread too thin.
More importantly, I'd like to ask other people to help. If you care
about getting a multimedia TADS interpreter for Mac OS X, consider
replying to this message with an additional cash pledge. No amount is
too small or too big.
So, how about it? Is anyone else willing to contribute?
2.
In the "Macintosh Terps" thread, Andrew Hunter said this:
> I guess another part of the problem is that there's no way to write a
> partial implementation of the TADS interpreter: 90% of whats in there
> could fairly easily be done with an extension to CocoaGlk, but the
> other 10% would take a very long time. Unfortunately, once you set the
> flag that says that your interpreter can support multimedia the entire
> system assumes you support everything, and that missing 10% would be
> noticable in most games. The only thing you can do if you can't support
> everything is support nothing... [snip]
I'm pretty sure this is untrue, and I'm saying so here because it
pertains to my next point.
Unless I'm really mistaken, just because an interpreter can't handle
full HTML, that doesn't mean it is duty-bound to ignore all HTML tags.
For instance, the TADS 3 interpreter for DOS pays attention to <b></b>
tags, showing bold text in a different color. I really hope I'm not
missing something here, but I always assumed that the same would be
true of most other HTML tags.
Perhaps Andrew was just trying to say, "It's not worth it for me to do
a full HTML 'terp. In fact, it's not worth for me to handle any HTML
tags at all." If so, I respect that. I'm not trying to criticize
Andrew, except to say that, unless I'm wrong, his above remarks are
not literally true.
This brings me to my point. I was surprised to see that some people
not only criticized Jim Aikin's manner of expressing himself in the
"Macintosh Terps" thread, but also scoffed at his opinion that it's a
non-trivial advantage for a 'terp to handle italics, bold, and other
text formatting. For what it's worth, I side with Jim on this point.
Apparently there are some people don't care about text formatting, but
some of us do care, and I hope that 'terp developers will take our
tastes into account when weighing the costs and benefits of
implementing such features, even in a non-multimedia 'terp.
In fact, I'd like to specify what I mean by "such features." I realize
I might be wasting my time here -- probably most interpreter
developers will ignore my input, and that's fine. They're under no
obligation to share my desires. But, in case any of them are open to
input, I've compiled a list of HTML TADS features which I think would
be worth considering *even for a non-multimedia TADS interpreter*.
The list:
1. Some "simple" font tags (in decreasing order of importance): i, b,
u, tt, sub, sup, strike/s, big, small
2. The "br" and "p" tags, for line breaks and paragraph breaks.
3. The "q" tag, for curly quotes.
4. More "complex" font tags: font, basefont
5. Unicode support. (I suppose this would include, if possible, the
stuff at http://www.tads.org/t3doc/doc/htmltads/latin2.htm.
Admittedly, I have no idea how hard this would be to implement.)
Greg
Adam Thornton
Greg Boettcher <WRITET...@gregboettcher.com> wrote:
>More importantly, I'd like to ask other people to help. If you care
>about getting a multimedia TADS interpreter for Mac OS X, consider
>replying to this message with an additional cash pledge. No amount is
>too small or too big.
>
>So, how about it? Is anyone else willing to contribute?
I'm in for $25.
Adam
Jim Aikin
$100 if the terp can also display .png files using the IMG tag, and $50
if the text styles are supported but no IMG.
With one caveat, I suppose. My iBook has never been upgraded to 10.4. If
10.4 is required to see the results, I'll have to spend $100 on an
upgrade, which would leave nothing to contribute to the developer.
--JA
Rune
wrote:
> Admittedly, I have no idea how hard this would be to implement.)
>
> Greg
I'm in for $100, and a cuddly green toy dragon [*].
(*: Monetary portion of prize only valid upon Mr. Thornton's adopting
said toy dragon into his household for a minimum period of of three -
3 - years.)
- Rune
Adam Thornton
Rune <rune...@online.no> wrote:
>(*: Monetary portion of prize only valid upon Mr. Thornton's adopting
>said toy dragon into his household for a minimum period of of three -
>3 - years.)
You bastard.
All right.
I promise I won't make it particularly easy for the dogs to get to it,
either, although I make no specific guarantees, as they're good at
finding things I didn't MEAN to leave within their reach.
Adam
PTN
wrote:
> I am hereby offering $100 to whoever completes the first full HTML
> TADS 2 and 3 interpreter for Mac OS X.
I can contribute $100 to that. I am working on the HTML TADS sequel to
1893: AWFM, which I have already decided to advertise as a Windows-
only program, given that HyperTADS is no longer a viable option. For
that matter, I've also asked Manifesto Games, who sells the
downloadable version of 1893, to advertise it as Windows-only. I even
shooed away about a dozen potential buyers of 1893 when I was
exhibiting at the Printers Row Book Fair this year. 100% of all of my
frustrated, unhappy customers have been Mac users trying to get the
darn thing to install properly. This was not the fault of HyperTADS,
which I think is an excellent program. This is just the move of the
Mac away from even having Classic Mode installed or even bundled with
their machines anymore.
I think that writing in HTML TADS is increasingly not a viable option
when trying to reach the largest possible audience. An OS X
interpreter would do wonders to get HTML TADS back on track. I'm
rather partial to TADS myself, so I will help where I can.
My dream list of features is small, though likely quite difficult. The
first is that HTML TADS would run in Spatterlight, and for Windows,
Gargoyle, to take advantage of that beautiful, beautiful typography.
The second would be that the interpreter could be bundled into the
game as a single executable, simplifying the install to the maximum
degree.
But I don't care too much about either of those. Getting the Mac back
up to where users can play HTML TADS games again would be more than
enough.
What worries me about this thread, and the one that Jim started prior,
though, is the complete absence of any voice saying that they are
working on such a project, or they are thinking about one, or might be
willing to try one.
Best,
-- Peter Nepstad
http://www.illuminatedlantern.com/if
Adam Thornton
PTN <pet...@illuminatedlantern.com> wrote:
>What worries me about this thread, and the one that Jim started prior,
>though, is the complete absence of any voice saying that they are
>working on such a project, or they are thinking about one, or might be
>willing to try one.
That is sort of weird, isn't it?
I wonder if--other than Andrew Hunter--we just no longer have anyone
around who writes Mac apps.
Don't be looking at me: I don't get this whole GUI thing. I haven't
even done Unicode support for an updated Linux terp. And I certainly
have no idea how to drive Xcode and create lickable Mac apps.
Adam
Nikos Chantziaras
> [...]
> What worries me about this thread, and the one that Jim started prior,
> though, is the complete absence of any voice saying that they are
> working on such a project, or they are thinking about one, or might be
> willing to try one.
I started it once, got derailed and never picked it up again. Was not
targeting OS X in particular; it was an HTML version of my (for TADS 3
now outdated) QTads interpreter (http://qtads.sf.net), but happens to
run fine in OS X. Though that interpreter supports italics and colors
and unicode and all that, adding Multimedia to it meant switching to a
totally different code base, and I would have to add another layer of
portability to it, especially for sound. Add to it the need to port it
from Qt 3 to Qt 4 and change the build system (Autotools, line in
FrobTADS, instead of Qt's QMake), and you have a nice, large piece of
work ;P
Rikard Peterson
ad...@fsf.net (Adam Thornton) wrote:
> In article <1183998151.3...@w3g2000hsg.googlegroups.com>,
> PTN <pet...@illuminatedlantern.com> wrote:
> >What worries me about this thread, and the one that Jim started
> >prior, though, is the complete absence of any voice saying that
> >they are working on such a project, or they are thinking about
> >one, or might be willing to try one.
>
> That is sort of weird, isn't it?
I'd like to add my voice to the other OSX users saying that this would
be nice to have, but I'm not prepared to add more money to the table.
(Sorry.)
> I wonder if--other than Andrew Hunter--we just no longer have
> anyone around who writes Mac apps.
If I only had the time... Maybe I'll give it a try when my current
game project is done, but the most optimistic time estimate on that
is at the end of the year (and that's starting to look too optimistic),
so hopefully someone more qualified (I'm a music teacher, not a
programmer) will already have done the job by then.
Rikard
Andrew Hunter
<WRITET...@gregboettcher.com> said:
Possibly you're misinterpreting what I said.
The DOS interpreter probably does what the current Glk TADS interpreter
does: claims to be text mode. This causes games to change their layout
and not attempt to use any significant multimedia features. Some
things, like bold and italic text, are passed through as normal.
There's only one other setting: multimedia. With this setting, the game
is told that all multimedia features are available and everything gets
passed through. The problem is that there are some things that are hard
to implement and make the display look completely wrong if they're not
there: in particular tables (which I think are used by default if
multimedia is turned on).
I've tried turning it on with the intention of adding HTML support to
the TADS interpreter in Zoom: things definitely go awry, so I turned it
off again.
All this means is that it's not something you can do by halves: I made
the decision that it wasn't worth holding up the release of Zoom 1.1.0
by months in order to add the necessary features to CocoaGlk when there
was already a glk port of TADS that I could use, and which shouldn't
have been any worse than any of the other ports of TADS that are
around, which tend to use the glk library. It's worth remembering that
this is the first version of Zoom to support TADS at all, and .0
releases are always a bit rough around the edge.
(Unfortunately, the glk implementation in the TADS source turned out to
be horrifically broken so it was quite a lot of work to get it to work
at all. I'd suggest that reimplementing that would be easier than
fixing it in the long run.)
> The list:
>
> 1. Some "simple" font tags (in decreasing order of importance): i, b,
> u, tt, sub, sup, strike/s, big, small
>
> 2. The "br" and "p" tags, for line breaks and paragraph breaks.
>
> 3. The "q" tag, for curly quotes.
>
> 4. More "complex" font tags: font, basefont
>
> 5. Unicode support. (I suppose this would include, if possible, the
> stuff at http://www.tads.org/t3doc/doc/htmltads/latin2.htm.
> Admittedly, I have no idea how hard this would be to implement.)
This lot is probably fairly easy to implement using CocoaGlk which can
do all of this without breaking a sweat. I'd probably need to add
something that makes it possible to pass in GlkStyle objects directly,
but that is really just a few lines of extra code. Pretty much
everything that's necessary for image support is already there as well
in the form of the cocoaglk_set_image_source() function.
The more complicated stuff also isn't impossible, but it's going to
involve a lot of work on the GlkTypesetter class. I wanted to get the
existing glk image formatting code well tested before I embarked on any
major engineering work in there.
Andrew.
Rune
> I started it once, got derailed and never picked it up again. Was not
> targeting OS X in particular; it was an HTML version of my (for TADS 3
> now outdated) QTads interpreter (http://qtads.sf.net), but happens to
> run fine in OS X. Though that interpreter supports italics and colors
> and unicode and all that, adding Multimedia to it meant switching to a
> totally different code base, and I would have to add another layer of
> portability to it, especially for sound. Add to it the need to port it
> from Qt 3 to Qt 4 and change the build system (Autotools, line in
> FrobTADS, instead of Qt's QMake), and you have a nice, large piece of
> work ;P
I still use QTads, actually, for testing a (slowly progressing) TADS3
WIP. (I can, because said WIP is still on the v3.0.8 libraries.)
I like QTads a lot: it handles what I use of HTML tags (bold, italics,
<.p> for paragraph breaks.) Also, restarting the game is just a quick,
two-key combination.
Spatterlight, I *think*, does not handle <.p> the way it should. Now
that Spatterlight has become the "default" OS X T3 terp, this gives me
a churning feeling in my stomach, as I have lots of code that'll need
to be updated to get paragraph breaks right, and ditto testing. (But I
could be wrong about what is correct <.p> behaviour.)
Italics and bold seem to work ok in Spatterlight, though.
- Rune
Blank
> Several things in the recent "Macintosh Terps" thread got me thinking,
> and I am posting my thoughts here now.
>
> 1.
>
> In that thread, Adam Thornton mentioned the possibility of putting
> together some money for whoever comes up with a multimedia TADS
> interpreter for Mac OS X. I think that's a great idea, and I'd like to
> get the ball rolling.
>
> I am hereby offering $100 to whoever completes the first full HTML
> TADS 2 and 3 interpreter for Mac OS X.
>
Given the interest that's been shown by other people willing to put up
cash, I think it might be a good idea to define exactly the features and
any other requirements necessary to make the 'terp eligible for the
prize. Just to avoid acrimony should a good-faith effort not be
considered close enough to what's wanted.
(Just to be clear: I don't have the skills to write an interpreter, so
am not a candidate.)
Oh, and thanks for getting the ball rolling!
steve....@gmail.com
> The DOS interpreter probably does what the current Glk TADS interpreter
> does: claims to be text mode. This causes games to change their layout
> and not attempt to use any significant multimedia features. Some
> things, like bold and italic text, are passed through as normal.
>
> There's only one other setting: multimedia. With this setting, the game
> is told that all multimedia features are available and everything gets
> passed through. The problem is that there are some things that are hard
> to implement and make the display look completely wrong if they're not
> there: in particular tables (which I think are used by default if
> multimedia is turned on).
>
> I've tried turning it on with the intention of adding HTML support to
> the TADS interpreter in Zoom: things definitely go awry, so I turned it
> off again.
>
I've only worked on the library side of this, so the following may be
of only limited interest.
There are actually three "classes" of interpreters: plain text, GUI
text (which may use variable-width fonts, etc.), and full html. I
think you're saying that if you're returning
(systemInfo(SysInfoInterpClass) == SysInfoIClassHTML), the library
starts assuming that it can do all kinds of things you're not
supporting. The HTML class does indeed imply some basic HTML
capabilities, like tables as you say. But on the other hand,
systemInfo(SysInfoInterpClass) is only supposed to characterize in
broad terms the system's capabilities, and the other selector codes
are for fine-tuning this. So you can select a lower interpreter class
and opt in for capabilities, or a higher class and opt out.
Mike Roberts
> Andrew Hunter writes:
>> There's only one other setting: multimedia. With this setting, the game
>> is told that all multimedia features are available and everything gets
>> passed through. The problem is that there are some things that are
>> hard to implement and make the display look completely wrong if
>> they're not there: in particular tables (which I think are used by
>> default
>> if multimedia is turned on).
>>
>> I've tried turning it on with the intention of adding HTML support to
>> the TADS interpreter in Zoom: things definitely go awry, so I turned it
>> off again.
>>
> text (which may use variable-width fonts, etc.), and full html. I
> think you're saying that if you're returning
> (systemInfo(SysInfoInterpClass) == SysInfoIClassHTML), the library
> starts assuming that it can do all kinds of things you're not
> supporting. The HTML class does indeed imply some basic HTML
> capabilities, like tables as you say. But on the other hand,
> systemInfo(SysInfoInterpClass) is only supposed to characterize in
> broad terms the system's capabilities, and the other selector codes
> are for fine-tuning this. So you can select a lower interpreter class
> and opt in for capabilities, or a higher class and opt out.
Well, not really. The classes are pretty well-defined. If a terp says it's
in the "Multimedia" class (SysInfoClassHTML), it means it supports the full
html tads markup language according to the html tads specs, which
effectively means *it's based on the htmltads code base*. Someone could
conceivably write a new code base that implements the same functionality,
and then legitimately return "Multimedia" as the interpreter class, but it's
hard to imagine anyone ever really doing this, given that it's vastly easier
to port the existing htmltads code base.
You can be a Multimedia class interpreter and then also have a few display
capabilities turned off (images, sounds, hyperlinks), which I think is what
you're getting at. But that's a red herring if you're looking for a way to
do an html tads port on the cheap. The "basic" html formatting stuff like
tables is the extremely hard part. Images are trivial in comparison. The
easy way to get tables working is to port the htmltads code base, because it
implements the heinous HTML table layout algorithms in nice portable C++
that you don't have to mess with.
--Mike
mjr underscore at hotmail dot com
steve....@gmail.com
weren't switchable. Makes much better sense now.
Greg Boettcher
> Given the interest that's been shown by other people willing to put up
> cash, I think it might be a good idea to define exactly the features and
> any other requirements necessary to make the 'terp eligible for the
> prize. Just to avoid acrimony should a good-faith effort not be
> considered close enough to what's wanted.
>
> (Just to be clear: I don't have the skills to write an interpreter, so
> am not a candidate.)
I think the specifications were pretty clear, albeit concise: I said
"first full HTML TADS 2 and 3 interpreter for Mac OS X."
The key here is that it has to be a "full HTML" 'terp. This means the
'terp has to support "the full html tads markup language according to
the html tads specs," to use the works of Mike Roberts in his last
post. This is the big thing; the 'terp has to support tables, images,
sounds, etc.
The only other thing I wish I had specified is that -- well, I hope
the 'terp programmer will be willing to either update their 'terp, or
else at least release their 'terp's source so that others can update
it to comply with future TADS developments. (But I didn't say that, so
I won't require that for sending out my prize money.)
> Oh, and thanks for getting the ball rolling!
Thanks... I appreciate the kind words.
Greg
Greg Boettcher
wrote:
> Possibly you're misinterpreting what I said.
>
> The DOS interpreter probably does what the current Glk TADS interpreter
> does: claims to be text mode. This causes games to change their layout
> and not attempt to use any significant multimedia features. Some
> things, like bold and italic text, are passed through as normal.
>
> There's only one other setting: multimedia. With this setting, the game
> is told that all multimedia features are available and everything gets
> passed through. The problem is that there are some things that are hard
> to implement and make the display look completely wrong if they're not
> there: in particular tables (which I think are used by default if
> multimedia is turned on).
>
> I've tried turning it on with the intention of adding HTML support to
> the TADS interpreter in Zoom: things definitely go awry, so I turned it
> off again.
>
> All this means is that it's not something you can do by halves: I made
> the decision that it wasn't worth holding up the release of Zoom 1.1.0
> by months in order to add the necessary features to CocoaGlk when there
> was already a glk port of TADS that I could use, and which shouldn't
> have been any worse than any of the other ports of TADS that are
> around, which tend to use the glk library. It's worth remembering that
> this is the first version of Zoom to support TADS at all, and .0
> releases are always a bit rough around the edge.
When you say "it's not something you can do by halves," I guess you
mean "you can't set your interpreter to the multimedia setting unless
you're prepared to be a be a *complete* multimedia 'terp." I know this
is true.
My point is, according to Jim Aikin, Spatterlight, which is a non-
multimedia 'terp, is able to handle some HTML tags such as <b> and
<i>. This makes me wonder whether non-multimedia interpreters could
also handle tags like <font>. If so, I hope non-multimedia TADS
interpreter authors will consider handling as many HTML tags as they
can, whenever it seems favorable from a cost/benefit viewpoint.
I'm not really saying you should change Zoom; in fact, I wish I hadn't
quoted you in this thread. I could have made my point without doing
so.
Just to clarify why I did quote you, though... I interpreted your
remarks to mean "If you're not going to make a full multimedia TADS
interpreter, then you can't handle any HTML tags at all." As far as I
can tell, Spatterlight disproves this.
Greg
Nikos Chantziaras
> [...]
> My point is, according to Jim Aikin, Spatterlight, which is a non-
> multimedia 'terp, is able to handle some HTML tags such as <b> and
> <i>. This makes me wonder whether non-multimedia interpreters could
> also handle tags like <font>. If so, I hope non-multimedia TADS
> interpreter authors will consider handling as many HTML tags as they
> can, whenever it seems favorable from a cost/benefit viewpoint.
Text-only interpreters have access to a sub-set of Multimedia Tads tags.
(Italics is a recent addition to that subset.) <font> is not part of
the text-only subset. Even if the author of the interpreter wants to
support it, it's not possible since it's part of the text-only subset.
The game (that is, the VM) will never send a <font> tag to a text-only
interpreter. It's not that interpreter ignores <font> tags; it's just
that it never receives any.
Nikos Chantziaras
> Several things in the recent "Macintosh Terps" thread got me thinking,
> and I am posting my thoughts here now.
>
> 1.
>
> In that thread, Adam Thornton mentioned the possibility of putting
> together some money for whoever comes up with a multimedia TADS
> interpreter for Mac OS X. I think that's a great idea, and I'd like to
> get the ball rolling.
>
> I am hereby offering $100 to whoever completes the first full HTML
> TADS 2 and 3 interpreter for Mac OS X.
>
> Furthermore, I'd like to encourage collaboration, rather than
> competition. Therefore, if the interpreter in question is the result
> of substantial collaboration, such that the cash would have to be
> split between two or more people, then I would like to contribute $200
> instead of $100, so that the money is not spread too thin.
>
> More importantly, I'd like to ask other people to help. If you care
> about getting a multimedia TADS interpreter for Mac OS X, consider
> replying to this message with an additional cash pledge. No amount is
> too small or too big.
>
> So, how about it? Is anyone else willing to contribute?
Almost three years have passed; does the offer still stand? Or am I too
late and did someone else get the benjamins? Cause I've now pretty much
completed a full-featured multimedia TADS 'terp for Mac OS X, Linux and
most other Unix systems.
(Though this was not the reason I wrote the interpreter; I only
remembered this thread a while ago.)
Eriorg
>
> Almost three years have passed; does the offer still stand? Or am I too
> late and did someone else get the benjamins? Cause I've now pretty much
> completed a full-featured multimedia TADS 'terp for Mac OS X, Linux and
> most other Unix systems.
>
> (Though this was not the reason I wrote the interpreter; I only
> remembered this thread a while ago.)
There's CocoaTADS, a multimedia TADS 3 interpreter for Mac OS X (but
not Linux).
In the thread http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/1695db1ad7c67211
, its author even mentioned this offer. I don't know if he received
the money.
Emily Boegheim
> Almost three years have passed; does the offer still stand? Or am I too
> late and did someone else get the benjamins? Cause I've now pretty much
> completed a full-featured multimedia TADS 'terp for Mac OS X, Linux and
> most other Unix systems.
The original offer was specific to Mac OS X, and as Eriorg said,
CocoaTADS got there first, so I guess the offer probably doesn't still
stand. However, since QTADS is the first HTML-TADS interpreter for Linux
(finally! woohoo!), I'm happy to toss a few dollars in your hat. Shoot
me an email.
Any chance you'll port the Workbench next? ;-)
Emily "Slavedriver" Boegheim
Jim Aikin
>
> Any chance you'll port the Workbench next? ;-)
>
> Emily "Slavedriver" Boegheim
I wish someone would port Workbench for MacOS!!! It sort of 98% works in
Crossover, but with a couple of annoying glitches. If I had a copy of
Win7 lying around (not free software, unfortunately) I'd try setting up
Boot Camp and see if Workbench would work better there.
The _most_ urgent necessity, however, is the ability to run HTML TADS
games in a Web browser. That just has to happen, and soon, in order for
T3 to remain competitive as an authoring system.
If I were a real programmer, I'd tackle the project myself, but I'm not.
What about it, Nikos? I've been thinking about trying to get $$$
contributions to a pool for the first person to create a working
solution to this problem. Would the possibility of money make a difference?
--JA
Nikos Chantziaras
> On 02/05/10 21:45, Nikos Chantziaras wrote:
>> Almost three years have passed; does the offer still stand? Or am I too
>> late and did someone else get the benjamins? Cause I've now pretty much
>> completed a full-featured multimedia TADS 'terp for Mac OS X, Linux and
>> most other Unix systems.
>
> The original offer was specific to Mac OS X, and as Eriorg said,
> CocoaTADS got there first, so I guess the offer probably doesn't still
> stand. However, since QTADS is the first HTML-TADS interpreter for Linux
> (finally! woohoo!), I'm happy to toss a few dollars in your hat. Shoot
> me an email.
Thanks for the offer Emily, but honestly, I didn't bump this thread to
hint at something that isn't there, namely me needing money in order to
continue supporting OS X or anything like that. Though I'll probably
activate SourceForge's "donate" functionality at some point in case
someone feels generous; pretty much the only thing I would need
donations for is to make it possible for me to buy a MacBook sooner so I
can actually test on and develop for OS X correctly; my current,
emulated "hackintosh" environment is awful to work with and looks more
like a proof of concept ("hey look, I can run OS X in a window inside
Linux, l33t!").
> Any chance you'll port the Workbench next? ;-)
Porting the Workbench itself as-is would be rather difficult, involving
"real" work since it's not written with portability in mind (in contrast
with the Tads VM, where I pretty much only had to implement specific and
thoroughly documented APIs.)
This wasn't a "no" though; I just didn't think about it much yet.
Nikos Chantziaras
> On 5/3/2010 6:15 AM, Emily Boegheim wrote:
>>
>> Any chance you'll port the Workbench next? ;-)
>>
>> Emily "Slavedriver" Boegheim
>
> I wish someone would port Workbench for MacOS!!! It sort of 98% works in
> Crossover, but with a couple of annoying glitches. If I had a copy of
> Win7 lying around (not free software, unfortunately) I'd try setting up
> Boot Camp and see if Workbench would work better there.
I'd recommend VMWare Fusion instead of Boot Camp, so you can run Windows
(XP, Vista or 7) inside OS X. Rebooting between OSes is just not very
practical. Fusion, in contrast to Crossover, actually runs Windows
itself, it doesn't try to simulate just the win32 API. It's also very
fast. This is how this looks like:
http://www.youtube.com/watch?v=jIiMX5_1Rzc
You can also drag&drop files between Windows and OS X in a seamless way.
> The _most_ urgent necessity, however, is the ability to run HTML TADS
> games in a Web browser. That just has to happen, and soon, in order for
> T3 to remain competitive as an authoring system.
>
> If I were a real programmer, I'd tackle the project myself, but I'm not.
> What about it, Nikos? I've been thinking about trying to get $$$
> contributions to a pool for the first person to create a working
> solution to this problem. Would the possibility of money make a difference?
If there was a price for this, Mike Roberts would get it since Mike
mentioned that client/server web-based deployment will be part of TADS
itself at some point. Though he didn't mention a timeframe yet (I think.)
Pete Chown
> I'd recommend VMWare Fusion instead of Boot Camp, so you can run Windows
> (XP, Vista or 7) inside OS X. Rebooting between OSes is just not very
> practical. Fusion, in contrast to Crossover, actually runs Windows
> itself, it doesn't try to simulate just the win32 API.
If you want something that is free (apart from the Windows licence) you
could try VirtualBox -- http://www.virtualbox.org/wiki/Downloads . I've
tried it on Linux and Windows, where it seems to work well.
The VirtualBox binary downloads are free to install and use on one PC.
It's also possible to build a GPL VirtualBox which lacks a few features.
This version tends to be bundled with Linux distributions, but it can
be harder to get hold of it for other platforms, unless you want to
build it yourself.
Pete