[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Development
. . -> [Subject]  Porting: Linux Native? MUSHclient

Porting: Linux Native? MUSHclient

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Lockewarrior   USA  (9 posts)  [Biography] bio
Date Tue 21 Sep 2010 01:00 AM (UTC)

Amended on Tue 21 Sep 2010 01:06 AM (UTC) by Lockewarrior

Message
I've been considering this on and off for a while, and I decided I might as well put it out there.

People are talking a lot about the future of MUSHclient and the future of MUDs themselves (even the future of operating systems) and when I consider it, there's this big, obvious question in my mind. Why isn't there a client as good as MUSHclient for Linux?

I've been looking in to the development of Mudlet(http://www.mudlet.org) and I hate it. I'm not knocking any of those devs or the work they've done, I'm just saying that the client is fundamentally different than MUSH and it's interface and functionality do not suit -my- needs.

Yes, MUSHclient runs (well) on top of Wine. So, if you are running a Linux operating system, it's totally feasible to use MUSHclient. However, that's about as much involvement as the Wine option allows for.

I would really like to be involved in the development of MUSH, but I'm not going to start running a Windows box any time soon, and where the hell do you even find MSVC 6.0 nowadays?

There are a lot of things in MUSH I think could be improved upon, extended, etc, regardless of which operating system it is running/developed on. Reconfiguration of the GUI, (triggers/aliases/etc), improving use of STL, extending GUI displays and script functions (wxwidgets/wxlua anyone?), modularity, etc.

I'm considering how much work it would be to fork MUSH and port it to Linux (I develop on Debian primarily.) I also want to know how such a project could be synchronized to the continued development of MUSH on windows. In other words, I'm trying to decide if I'll be writing a brand new client inspired/based-off of MUSHclient, for the Linux operating system, or if the current client could feasibly be split into a separate build for Nix.

What do you guys think about this? Twisol, you up for some practice coding? :D
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #1 on Tue 21 Sep 2010 01:23 AM (UTC)

Amended on Tue 21 Sep 2010 01:26 AM (UTC) by Twisol

Message
Lockewarrior said:
I would really like to be involved in the development of MUSH, but I'm not going to start running a Windows box any time soon, and where the hell do you even find MSVC 6.0 nowadays?

I won't knock you for not running Windows, but I help out with MUSHclient using VS2005, and Worstje uses VS2010. The main issue is that changes have to be compatible with Nick's VC6.

Lockewarrior said:
I'm considering how much work it would be to fork MUSH and port it to Linux (I develop on Debian primarily.) I also want to know how such a project could be synchronized to the continued development of MUSH on windows. In other words, I'm trying to decide if I'll be writing a brand new client inspired/based-off of MUSHclient, for the Linux operating system, or if the current client could feasibly be split into a separate build for Nix.

Mmmmm.... Not without a lot of effort. There's almost nothing in the codebase that hasn't been touched by MFC. CMUSHclientDoc is the central God Object of the program, meaning it's heavily coupled with just about everything. It would be a lot of work. I'd rather start from scratch using wxWidgets or Qt, like Nick has proposed in the past.

Lockewarrior said:
What do you guys think about this? Twisol, you up for some practice coding? :D

I definitey think it's a great idea to bring some competition to Mudlet to the Linux and Mac platforms. Unfortunately, I'm not sure writing another desktop application is the best way to do that. ;) My opinion is that there's not much ground left unbroken in the world of desktop clients. How much of what Mudlet has is truly new? I would argue "not much".

I mean, I'd help out where I could, but I wouldn't become a core contributor. I'm focusing my efforts on the web client domain. :)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Tue 21 Sep 2010 01:30 AM (UTC)
Message
I've discussed the idea of a rewritten client before, and personally I would do that rather than trying to do major improvements to the current one. Various problems with the current client are:


  • It uses MFC (Microsoft Foundation Class) libraries - which are not free and not portable to, say, Linux or OS/X.

  • Because of this it doesn't compile under g++. I think I tried to compile under g++ a while ago, but got thousands of warnings/errors about the Microsoft include files not being standard C++ (to be fair, Visual C++ 6 is quite old).

  • It uses WSH (Windows Script Host) which is a Microsoft invention.

  • The GUI interface could use work.

  • It wasn't written as a Unicode app - I would do that next time so that different character sets are handled more smoothly.

  • A lot of the earlier lists/maps/queues etc. use the MFC structures rather than STL. I would use STL next time.

  • Because Lua was added later the scripting interface is messy to say the least.

  • A lot of duplication exists in functionality (eg. things that GetInfo returns that are also available elsewhere).


As I said in an earlier thread, I would stick to Lua, which greatly simplifies the scripting part. Also Lua lets you have script function calls with optional arguments, and functions that return multiple return values.

You could save a lot of effort by using Lua as the configuration file format (rather than XML) thus letting you ignore the XML parsing/writing aspect.

You might save quite a bit of effort by either deferring, or omitting, support for MXP. The MXP standard, or ambiguity in the standard, has caused quite a lot of grief.

You could simplify the storage of line data (the output buffer) by converting incoming text straight into RGB codes initially, rather than having the current cumbersome system of a mixture of ANSI codes or RGB codes.

The miniwindows stuff could probably be converted quite easily (most of that code could stay the same) as long as you did the "primitive" operations in the new system (wxWidgets or whatever).

Certainly chunks of code could be borrowed - utility functions (like base64 encoding), or the PCRE stuff (well that is mainly an external library anyway). You could look at how it does the ANSI parsing, and the telnet negotiation, to save reinventing those wheels.


I wonder at the end of the day whether the effort can be justified, when running under Wine works pretty well. Still, if you want to have the fun of doing it, by all means.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Ruedii   (2 posts)  [Biography] bio
Date Reply #3 on Wed 27 Jul 2011 09:38 AM (UTC)
Message
I know that Windows Foundation Classes have been replaced in LibWine, however I'm am not sure about the Scripting Framework.

Replacing the include files with those from winelib should fix most, if not all of the compilation issues, and the rest (if there are any) should be easy to deal with.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Wed 27 Jul 2011 09:19 PM (UTC)
Message
Well if someone would like to demonstrate, that would be great. But somehow I doubt that swapping out MFC in favour of different libraries will be at all simple.

I can't even get the source to compile (ie. before we worry about libraries) because of the differences between g++ and Visual Studio.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


19,920 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]