Vulcanius2007-02-26 15:52:42
Hey everyone,
I really shouldn't even bother mentioning it because it's not going to happen fast but I am currently beginning work on a new Python based MUD client. More specifically a client for Lusternia, because I really don't care about other MUDs. (Lusternia, me love you long time) I aim to have the client support all types of standard features including everything found in other clients such as zMUD, cMUD, MushClient, MudMagic, Kmud, etc. The primary purpose is to create a full featured, open source, completely free in every way, cross platform, Python based client. Sound too good to be true? Well it probably is, lol. Right now I'm working on the core programming. I have been debating whether to use Tkinter, wxPython, or another GUI toolkit but I believe for ease of use by the end user I will go with Tkinter as it is the toolkit natively installed with Python. When it comes to scripting I hope to create a very easy to use scripting language similar to zMUD and I will also make it easy to run Python scripts too. If Zugg allows me I would like to add direct support for the zMUD scripting language so your scripts should work just fine in the new client. (I'm not too sure how he will feel about supporting a distant competitor) As I said before the client will be open source and free in every way possible for others to use, modify, and distribute. I will most likely create my own license that other developers must abide by. Don't take that the wrong way, the only requirement I plan to make of anyone who modifies the client is that they let me know what they changed, why, how, etc. so that I may implement those same changes. I don't mind people who want to fork off and make their own client out of mine, but I believe in some pretty communist-coding practices. So please just let me know if you change something what it was so I can improve the software.
I must say ahead of time, please don't send me a bunch of feature requests and things like that. Adding in a bunch of extra features will only be done once a solid, stable base client has been established. However at the moment I would like some input from the Lusternia community about the user interface. I am going to mimic the zMUD interface for the most part just because most people use it and it would make transitioning much easier. But what I would like to know is if there is anything you would change about the zMUD interface to make it better.
What I need:
1. Any input you have on how the user interface should change. The user interface will be as close to zMUDs as possible.
2. A name for the client.
What I don't need:
1. Everything else.
I really shouldn't even bother mentioning it because it's not going to happen fast but I am currently beginning work on a new Python based MUD client. More specifically a client for Lusternia, because I really don't care about other MUDs. (Lusternia, me love you long time) I aim to have the client support all types of standard features including everything found in other clients such as zMUD, cMUD, MushClient, MudMagic, Kmud, etc. The primary purpose is to create a full featured, open source, completely free in every way, cross platform, Python based client. Sound too good to be true? Well it probably is, lol. Right now I'm working on the core programming. I have been debating whether to use Tkinter, wxPython, or another GUI toolkit but I believe for ease of use by the end user I will go with Tkinter as it is the toolkit natively installed with Python. When it comes to scripting I hope to create a very easy to use scripting language similar to zMUD and I will also make it easy to run Python scripts too. If Zugg allows me I would like to add direct support for the zMUD scripting language so your scripts should work just fine in the new client. (I'm not too sure how he will feel about supporting a distant competitor) As I said before the client will be open source and free in every way possible for others to use, modify, and distribute. I will most likely create my own license that other developers must abide by. Don't take that the wrong way, the only requirement I plan to make of anyone who modifies the client is that they let me know what they changed, why, how, etc. so that I may implement those same changes. I don't mind people who want to fork off and make their own client out of mine, but I believe in some pretty communist-coding practices. So please just let me know if you change something what it was so I can improve the software.
I must say ahead of time, please don't send me a bunch of feature requests and things like that. Adding in a bunch of extra features will only be done once a solid, stable base client has been established. However at the moment I would like some input from the Lusternia community about the user interface. I am going to mimic the zMUD interface for the most part just because most people use it and it would make transitioning much easier. But what I would like to know is if there is anything you would change about the zMUD interface to make it better.
What I need:
1. Any input you have on how the user interface should change. The user interface will be as close to zMUDs as possible.
2. A name for the client.
What I don't need:
1. Everything else.
Unknown2007-02-26 15:59:29
I like the zMUD settings editor, for the most part. The preferences dialog is also not too terrible. As far as the user-editable things such as buttons and gauges, I'd like to see the ability to add more true Windows controls to the interface, such as checkboxes, dropdown combos, and radio buttons.
If this gets hosted on SourceForge or somewhere similar, please do post the URL.
Good luck with the project! (I know you'll need it.)
If this gets hosted on SourceForge or somewhere similar, please do post the URL.
Good luck with the project! (I know you'll need it.)
Verithrax2007-02-26 16:27:32
...I'm afraid that name is taken.
Oh, and from a purely end-user standpoint, I'd prefer python-gtk - But I am aware that GTK is a bitch to code with compared to tkinter. I'm not fond of tk; I'm relatively unfamiliar with wxPython.
ETA: Actually if I were you I'd write the code modularly and implement a purely console-based interface first, focusing on shipping a version of the client with support for all the important features (Color, aliases, triggers, highlights, conditionals, variable) and a sane (Read: Entirely unlike TinyFugue's) scripting language. A GUI can come later.
Oh, and from a purely end-user standpoint, I'd prefer python-gtk - But I am aware that GTK is a bitch to code with compared to tkinter. I'm not fond of tk; I'm relatively unfamiliar with wxPython.
ETA: Actually if I were you I'd write the code modularly and implement a purely console-based interface first, focusing on shipping a version of the client with support for all the important features (Color, aliases, triggers, highlights, conditionals, variable) and a sane (Read: Entirely unlike TinyFugue's) scripting language. A GUI can come later.
Vulcanius2007-02-26 17:02:56
Heh, I used the name System V as a play on words. I'm a *nix system admin so I figured what the hell, System V shows my background plus my name, Vulcanius. But like I said in my post, I need help with a name for it, System V just made me grin.
As for a purely console-based interface first that is what I am working on at the moment. But I want people to start thinking about how it should look and interact.
The only reason I consider Tkinter is because it is native to Python. If you have python installed, you have Tkinter installed. wxPython is probably the biggest heavyweight contender in terms of GUI toolkits. It's robust and powerful and it also resembles the Windows style programs much better. I suppose GTK is an option but your right, it is a bitch to use. I suppose though I could use Glade or pyGTK but I would most likely use Gazpacho if I was venturing that direction.
As for a purely console-based interface first that is what I am working on at the moment. But I want people to start thinking about how it should look and interact.
The only reason I consider Tkinter is because it is native to Python. If you have python installed, you have Tkinter installed. wxPython is probably the biggest heavyweight contender in terms of GUI toolkits. It's robust and powerful and it also resembles the Windows style programs much better. I suppose GTK is an option but your right, it is a bitch to use. I suppose though I could use Glade or pyGTK but I would most likely use Gazpacho if I was venturing that direction.
Verithrax2007-02-26 17:26:23
QUOTE(Vulcanius @ Feb 26 2007, 02:02 PM) 386229
Heh, I used the name System V as a play on words. I'm a *nix system admin so I figured what the hell, System V shows my background plus my name, Vulcanius. But like I said in my post, I need help with a name for it, System V just made me grin.
I figured. Just making sure. Then again, having a package called "System V" in an apt repository would be kind of confusing. Think "I'm running System V now on my Linux box virtualized under VMWare running on Windows XP, for testing purposes".
QUOTE
As for a purely console-based interface first that is what I am working on at the moment. But I want people to start thinking about how it should look and interact.
The only reason I consider Tkinter is because it is native to Python. If you have python installed, you have Tkinter installed. wxPython is probably the biggest heavyweight contender in terms of GUI toolkits. It's robust and powerful and it also resembles the Windows style programs much better. I suppose GTK is an option but your right, it is a bitch to use. I suppose though I could use Glade or pyGTK but I would most likely use Gazpacho if I was venturing that direction.
The only reason I consider Tkinter is because it is native to Python. If you have python installed, you have Tkinter installed. wxPython is probably the biggest heavyweight contender in terms of GUI toolkits. It's robust and powerful and it also resembles the Windows style programs much better. I suppose GTK is an option but your right, it is a bitch to use. I suppose though I could use Glade or pyGTK but I would most likely use Gazpacho if I was venturing that direction.
I'd like it to be extensible in Python as well as scriptable (Believe me, it's better to provide a domain-specific language rather than making people use Python for writing their aliases and such. I know I prefer it that way, and I do code Python.) That way, it would be possible to make custom wxPython (Or whatever you decide to use) tools and widgets (Ultimately, this could be more flexible than zMUD). zMUD, or at least tt++ compatibility, would be desireable.
Unknown2007-02-26 17:35:09
I don't really know much about python, so the only thing I can say is "Please make the GUI elements draggable". I hate in Zmud having to fiddle with all the numbers to make everything line up.
Unknown2007-02-26 22:40:44
I'd suggest pMud or pyMud but it seems those are taken as well.
Besides, get it done first, worry about the name later.
Besides, get it done first, worry about the name later.
Tias2007-03-02 00:00:30
There is already a pretty decent python mud client out there though support has kind of faded.
http://lyntin.sourceforge.net/
http://lyntin.sourceforge.net/
