Friday, 13 May 2011

Linux Runner

I've been working on a Linux version of ADRIFT 5 Runner, which runs using the Mono Framework. This has required a few tweaks around Window-isms and stripping out the third party libraries, but it is looking quite promising so far, and I don't anticipate any major problems.

All being well I will be releasing this shortly after the next Windows release.

Posted by at

5 comments:

  1. Unknown13 May 2011 at 17:11

    Great that you're doing this, but .Net on Linux, well, sucks major. Applications written in it look alien, not at all integrated with the look or feel of the environment. It's like they have a huge red label saying "*look at me* this is not a Linux app".

    ReplyDelete
  2. Campbell14 May 2011 at 03:06

    I suppose the answer to that is to recode and compile locally for Gtk, but that's a lot more work, and there is quite a lot of valid code that Mono is rejecting at the moment. Is there anything that would help in the meantime, for example changing the default beige to something else?

    ReplyDelete
  3. Victor Gijsbers14 May 2011 at 03:11

    I would be very happy with a native Linux ADRIFT runner, even if it doesn't look good. :)

    ReplyDelete
  4. ralphmerridew14 May 2011 at 09:45

    The ideal thing to do would be:
    1) Separate all "core" code from "UI" code.
    1a) Portability of core code is crucial; portability of UI code is not important.
    1b) The interface between core and UI should be restricted as much as possible.
    2) Make it easy to replace the UI part (say, by linking with a different library).
    3) Write (say) .NET and GTK versions of the UI code, and let porters do Qt, Glk, text only, wxWidgets, ... versions.

    I don't know how well that works with how you've organized your code, though.

    ReplyDelete
  5. Unknown16 May 2011 at 11:05

    Yes, having something that doesn't look native is way better than having nothing at all! :-) If Adrift, as a whole, in written in C#, then I guess we'll have to live with it. Otherwise, following the Glulx or TADS portability model (Glulx->Glk, TADS->osifc) would be the far better solution. Because then others can do the ports.

    ReplyDelete

Subscribe to: Post Comments (Atom)