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

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Python
. . -> [Subject]  Easy Text editor?
Easy Text editor?

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

Pages: 1 2  3  4  5  

Posted by Rakon   USA  (123 posts)  [Biography] bio
Date Mon 19 Feb 2007 02:22 AM (UTC)

Amended on Mon 19 Feb 2007 04:49 AM (UTC) by Rakon

Message
Greetings all.

I've been working on a way to sort of duplicate a composer for the standard client, of the MUD I play.
What this would do, in python, is allow easier editing of files, then send the resulting text to the main MUSH window, or discard and exit.

What I have so far is below, and well.... its not working.
When I call the 'edit' function via an alias, it opens up the TK window and all, but then it goes straight to the 'save' function. When you exit that (because It won't save no matter what, and I can't figure out why I can't even get THAT working), it'll freeze or crash Mush.

Any ideas at ALL on how to rectify one or all of these issues. Thanks


def edit(*args):
	textedit()

class textedit(Frame):
	global Root 
	Root = Tk()
	global Sb
	Sb = Scrollbar(Root)
	global Tx
	Tx = Text(Root)

	def __init__(self, parent=None):

		try:
			Tx.config(font=('Bitstream Vera Sans Mono', 9, 'normal'))
		except:
			Tx.config(font=('courier', 9, 'normal'))

		Tx.focus_set()
		Sb.pack(side=RIGHT, fill=Y)
		Tx.pack(side=LEFT, fill=Y)
		Sb.config(command=Tx.yview)
		Tx.config(yscrollcommand=Sb.set)

		menubar = Menu(Root)
		File = Menu(menubar, tearoff=0)
		menubar.add_cascade(label="File", menu=File)
		File.add_command(label="Save", command=textedit.save(self))
		File.add_command(label="Quit", command=Root.destroy)


		Root.config(menu=menubar)
		Root.title("MUSHComposer  -- "  + str(world.WorldName))
		
	def save(self):
		filename = asksaveasfilename()
	   	if filename:
			text = Tx.gettext()                      
			open(filename, 'w').write(text) 
			al_norm(text)
Yes, I am a criminal.
My crime is that of curiosity.
My crime is that of judging people by what they say and think, not what they look like.
My crime is that of outsmarting you, something that you will never forgive me for.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #1 on Mon 19 Feb 2007 06:55 PM (UTC)

Amended on Mon 19 Feb 2007 07:20 PM (UTC) by Shadowfyr

Message
Umm.. At a guess:

def __init__(self, parent=None)

I assume you are creating a window here. One of the rules in Windows is that you can only have **one** primary window for each execution thread. When you use "None", or NULL is some others, you are basically telling it to create a new primary window. The OS will attempt to do so, may even display the window (maybe), but the moment you attempt to close it the system won't have a clue which primary window you are talking about. That assumes you even get far enough to close it though, sometimes it just hangs or crashes immediately as the system can no longer tell "which" window system events for the application should go to. I am not real clear on what does go wrong, just that its not good.

You can try using the "GetFrame" function to return Mushclient's own window, then use that as the "parent". However, no one has attempted this since the "GetFrame" function became available, so no one really knows how things like button clicks, etc. will work, or even if they will work at all, in this situation. I admit, I have had other things I have been doing that have distracted me from even trying, but it all hedges on "if" events are handled right.

In other words, if its possible depends entirely on if clicking on a button on the window you create "will" actually send the event to the script, or if it vanishes into limbo because of some unknown issue. No one here knows. No one here has, sadly, really tried since it became theoretically possible, and I have found a complete lack of compassion for the ignorance we share, never mind pre-existing examples, on forums about the subject that might answer the question. I posted a request for something on it a week ago and still haven't got a response where I did. The previous one I posted they told me to talk to the people on the current forum I just posted at last week. I am getting the run around, either because the answer is so damn obvious they don't want to bother, or because they don't have a clue either.

By all means try. If it works, then at least we know "one" of them does. And that may be enough to suggest that wxLua will work to, if Nick switches to that instead of plain Lua.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Mon 19 Feb 2007 07:56 PM (UTC)
Message
Quote:

What this would do ... is allow easier editing of files, then send the resulting text to the main MUSH window, or discard and exit.


Why not just "send to notepad" (the existing editor built into the client), and then do something with that once you have edited it? For instance, GetNotepadText gets the contents of a notepad window.

Or, the notepad window has a "send to MUD" option (Edit menu) for sending the text back to the MUD.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #3 on Tue 20 Feb 2007 06:56 PM (UTC)

Amended on Tue 20 Feb 2007 06:58 PM (UTC) by Shadowfyr

Message
Sigh. Nick. Don't torpedo this before it gets off the ground. If he can get it to work, it will answer a number of questions we need answered... The problem he is trying to solve actually goes way beyond anything you can solve with, "Why not just use the notepad and some script?" And.. One good reason imho, you can't place the notepad anyplace but in the MDI frame, which severely limits your ability to use it, unless you have lots of desktop space or multiple monitors, which is currently buggy, **and** you leave the main window stretched to the entire available desktop space. Seperate windows are *far* more versitile and can be used for more than pure black and white text, if anyone can manage to make them work.

Mind you, if he doesn't want to go through the hassle to figure it out, that's another thing. But its not like making the notepad work as he wants is any less trivial, since it doesn't exactly come with buttons "specific" to the tasks he wants to perform.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Tue 20 Feb 2007 07:22 PM (UTC)
Message
Quote:

Don't torpedo this before it gets off the ground.


I wasn't torpedoing it. If the intention is to develop a generic way of doing GUI interfaces, well fine.

However sometimes what is really required is a simple solution to the problem. The requirement in the original post seemed to be a way to "edit files" and "send the resulting text to the main MUSH window". The notepad does that.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Rakon   USA  (123 posts)  [Biography] bio
Date Reply #5 on Wed 21 Feb 2007 02:31 AM (UTC)
Message
Hey, Nick:
I HAVE tried it your way. The issues I find with this is to save/quit/send the text you still have it within the MUSH main window, thus covering up anything else you have, AND would still have to use aliases and the like to try to save/quit/send the text.
Quote:

you can't place the notepad anyplace but in the MDI frame, which severely limits your ability to use it

That really is my biggest factor in trying to create a seperate window for the editor

I really AM trying to make it its own GUI window, only using TK, so that anyone with Python can use it. I mean its not going to be any super 'OMG AWESOME', Syntax highlighting, spell-checker of an editor. Just a basic one.

My goal with this project is, to learn more of TK (proper usage), make a useful GUI approach to edit simple text files, and allow the window to be a seperate entiety of MUSH.
Yes, I am a criminal.
My crime is that of curiosity.
My crime is that of judging people by what they say and think, not what they look like.
My crime is that of outsmarting you, something that you will never forgive me for.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #6 on Wed 21 Feb 2007 05:10 PM (UTC)
Message
Glade someone else is as bugged by the limitations as I am. lol

Now comes the hard/easy part. In principle, it should be as easy as doing:

def __init__(self, parent=world.GetFrame)

instead of "None". The problem is, its not clear how events are handled. Basically, we are not sure if Python, TK, or something like wxLua (which I would love to see replace Lua because of its GUI systems) have there own event handler, and more to the point, if events are correctly sent to them, instead of to Mushclient. If they have to pass through Mushclient, then its not clear how/if MFC will pass them back to the script, or if something in Mushclient itself must be changed to make this happen. I have had a question posted on a wxwidgets forum for a week, which no one has answered, about just what happens in this case. Maybe someone asking on a Python forum can get a better response... Basic problem is, most implimentations either have Python, etc. creating **all** GUI elements, not just taking them onto an existing client in which the script runs, or they are imbedded in something like Internet Explorer, which has its *own* event handlers and connection systems to create and link the objects to the scripting.

Worst case, we need to have Nick make a few changes to Mushclient to make it work, but no one here has a clue what, or even if, this is needed. Best case, it works without changes. We just don't know at the moment. *However*, I suspect that the answer is, "It will work anyway", since I am reasonably sure I read something some place about people using Events to *hook* into what someone else's application was doing and keep an eye on what was going on in it. I am less certain if that "hook" involved telling the existing object to add the application as an event sink, or if instead they used some crazy system call to latch into the main event stream. The later is damned dangerous and if things are not released back the way they where before, it *will* crash the entire OS, since the next link in the chain of application that "should" be called becomes a "Null" pointer, instead of a correct location (oops!).

Anyway, making the window *should* be as easy as replacing that one line. The real question is, "Will clicking the "save" button/menu item then correctly call 'save(self)'?" At the moment, we simply don't know, or how to fix it if it doesn't.
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Wed 21 Feb 2007 07:28 PM (UTC)
Message
Quote:

If they have to pass through Mushclient, then its not clear how/if MFC will pass them back to the script, or if something in Mushclient itself must be changed to make this happen.


As I think I may have mentioned before, as MUSHclient is written using MFC, the internals of MFC do the initial handling of events, and if MFC doesn't think an event is for the application, then it won't be given it.

The other problem here is the notion of "pass them back to the script". The script is not something that is "always alive" - it is activated at certain times, eg. when a trigger calls a script. Then MUSHclient does a "script engine call", and while that is active, then MUSHclient is dormant.

I see from the wxwidgets mailing list that you (Shadowfyr) have been pursuing this discussion there in the hope of getting some resolution to the problems we are aware of. As far as I can see, there are still unanswered questions.

Looking at the description for wxLua on the SourceForge site, we see this: "It consists of an executable for running standalone wxLua scripts and a library for extending C++ programs with a fast, small, fully embeddable scripting language.".

Notice the main aim is to run "an executable for running standalone wxLua scripts". That is, and the demos seem to support this, that you can make a GUI executable with Lua as the script language. This is fine, because the executable has its own event loop.

It still isn't clear to me how a program, like MUSHclient, that already has its own event loop, will marry with wxLua, which wants one too. The references on the mailing list to other applications (eg. Photoshop plugins) sound a little doubtful, with the poster saying "I believe there is code about how to do this".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #8 on Thu 22 Feb 2007 07:56 PM (UTC)
Message
Yes. The thing with stuff like Photoshop is that their own code contains an interface which "includes" functions to tie stuff like new windows, etc. into the application. I really wish I understood event sinks better. :(

I mean, presumably all that a "connect" function does is tell the object, "Every time *you* have this event, you need to call a function at *this* address." Its all the stuff in between that is bloody unclear, including if those entry points might "wake up" the script engine without Mushclient itself having to do so. Its bloody frustrating to not be able to get the information from wxLua forums, so having to nose around wxwidgets, which **isn't** the same thing at all. Wxwidgets isn't a scriptable implimentation, its actually a complete replacement for the normal APIs you might use to build an application, or rather a *translation* layer, which lets you port those API calls between different platforms. So, its not a surprise that they can't come up with an answer about it. But its damn frustrating that no one else can either. Even a simple, "No, that won't work without modification.", would be nice.

In any case, one can simply try and see by making the one change I suggested to the Python script. The crashing is caused by trying to create two primaries in the same application, you can crash yours just as easilly if written in plain C++ without Python doing that. And Python uses similar "connect" functions to link events to event sinks to those that wxLua would be using. Its not entirely clear if its the "base" application handling the events or the script engine.

Mind you, I have seen cases of people talking about integrating Lua, wxLua, etc. into "text based console applications", and those ***don't*** generally have event systems at all. Its quite possible that the engines supply their own event handlers and that Windows is smart enough to know that objects the engine own go there. That is why I suggest just trying it with Python to see what happens. If not, we at least know that something more needs to be done to make it happen.
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #9 on Fri 23 Feb 2007 01:50 AM (UTC)
Message
The reason you can attatch Lua into pretty much anything is because it has a nice handy C interface. You can run bits of compiled C code as Lua functions, and you can have C functions call easily into Lua's interface. Lua has it's own event handling, and doesn't rely on a specific program's.

I'm not too terribly clear on this, but a friend of mine has been explaining it to me here and there while he's been teaching me Lua. It actually does have a different interface with the C libraries than most other scripting languages, which is why it is so easy to incorporate into programs.
It is much easier to fight for one's ideals than to live up to them.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #10 on Fri 23 Feb 2007 02:26 AM (UTC)
Message
Plugging Lua into an application is an entirely different beast from setting up any kind of Windows event handling.

Lua per se doesn't really have "event handling" when you embed it into an application. When you embed Lua it simply gives your application the ability to make calls into Lua. (And let Lua make calls into your C program, but those always start by calling Lua which then calls back to C.) Lua itself doesn't open up handlers to intercept anything.

It's really not comparable to talk about adding Lua into an application, and letting Lua manage windows and so forth.

And in particular, Lua certainly does not supply its own event handler. I'm not sure if wxLua does; it probably does, one way or another. Of course, that makes it hard to mix wxLua with another piece of code that is expecting to have its own full control over the event loop.

It's undoubtedly possible; the real question is how much work Nick would have to do to make it happen. My impression is that it would require an awful lot of work, most probably far too much to justify the gain.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #11 on Fri 23 Feb 2007 06:51 AM (UTC)
Message
Really? Too much to justify the gain? See, I don't entirely agree with that. Sure, you can use Mushclient now with WINE, but there are some minor limitations. If you also want to use a custom GUI element, like a mapper, you may run into **major** limits that make it effectively impossible. The WX libraries are cross platform, so its not impossible to a) have way more portability to start with and b) even possibly at some point replace the MFC with wx, thus making the application itself completely portable. (Mind you, I am not sure how the license for wx works or if its "practical" to do that. If its some version of GPL that doesn't allow the main application to be closed source...)

And frankly, how the heck else do you manage it? Supply every person that downloads Mushclient with a copy of GCC or WMing and a book on C++ programming? Right now its simply not practical for a casual coder to design ***anything*** to work with Mushclient. I can tell you right now, there are a half dozen ideas I would implement tomorrow *if* some way to do this existed that didn't rely on writing something in a completely different language and compiling it, or creating some lame wrapper for a program or dll I want to use, just because I can't use event sinks at all right now. The problem effects nearly everything we do with this client. You can't even open a web page without wasting script time constantly looking to *see* if the page finished loading in IE, because you can't simply have it "tell you" its done directly. Music players are crippled by the need to constantly ask what song it playing, instead of being told it changed to something new, then looking "once" to find out. Office applications, graphics application, etc. Anything the *pre-exists* and supplies a means to talk to it is crippled because of this when used from inside scripts. Stuff you code yourself.. Less so, but its still absurd that you have to call callplugin or some similar Mushclient function, passing it data on what happened, because you can't simply have the "what happened" call the script needed directly.

Anything you want to do right now requires far more than the basic knowledge of scripting and some simple examples the average user has access to. By comparison, wxLua, or even Python, you could teach someone the basics of creating a window with a button on it in five minutes. I would call that a HUGE advantage. And frankly, I suspect its ignorance that is making the actual problem seem insurmountable or so complicated that its not practical to try.

I don't know near enough about it, but I have read bits and pieces on event sinks, handlers, etc. And by my estimation, which I admit could be wrong, the changes needed are probably little more than overriding a single function in the MFC interface with a new function, which itself would simply do little more than:

function blah (){
  if event.name contains "Lua"
    call wxLua.eventhandler(event)
  else
    call me::original_function;
}


In other words, you redirect the events "temporarilly" to something that can figure out that they belong to the script system, pass those that do to it, and any that don't you simply pass "back" to the original MFC event handling function. This of course assumes that such a system exists. If not, then the event source *knows* where the script function is "supposed" to be, so I would assume that part of the event fired would "include" the location of the sink its "supposed" to go to. All that would need to happen is waking the script engine up, calling the address (possibly after verifying it still existed), then continuing on from there.

Now, its been like 4-5 years since I saw an example of anyone doing this, so it could be more complex than I think, but not by the huge chasm of difficulty everyone seems to think it would be. All you are doing is creating an event intercept, without disrupting the existing event sinks. Doing so, from what I remember, is quite trivial. The only question is, "Do we need such a thing in the first place?", and if that intercept needs to handle the function call or just pass things along to the right event handler. By comparison Nick has done stuff just in the last 3-4 updates that make such a change look as simple to manage as successfully filling a glass with water.

I suspect the answer lies in asking the question the right way, in the right place. Problem is, I am notoriously bad at asking the right question the first time, let alone figuring out where the right place really is to ask it. Worse, most places that deal with these things have a notoriously bad habit of linear thinking when it comes to how they code "everything" with it. It literally wouldn't occur to 99.9% of them that one might even *try* to code part of a program in something "other" than wxLua itself. The other 0.1%... problem never imagined trying to intergrate it into and existing GUI. I have chased my tail before over some things like this, only to have the "actual" problem explained in a three page article, with example code. It can drive you slightly nuts looking for anything that isn't "standard" implimentation.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #12 on Fri 23 Feb 2007 06:58 AM (UTC)
Message
I think you missed the point. Obviously, it would make your day, week, month and year, and be the best thing since sliced bread. But it's very unclear to me that for Nick the work is worth the gain it will bring him. There are relatively few people with this demand as specifically, urgently and vocally as you, and even fewer who would put their wallet where their mouth is. So, from what I can see of the picture, in terms of the cost Nick would incur versus the gain he would obtain, if I were in his shoes, doing something like this would make rather little sense.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #13 on Fri 23 Feb 2007 07:36 AM (UTC)
Message
Shadowfyr, you have previously suggested that I change MUSHclient to use wxLua rather than Lua. But how practical is this? According to the wxLua web site the size of the installer is 5.3 Mb.

Compare this to the current size of the MUSHclient installer, which is 1.82 Mb.

It seems to me that to support wxLua, even if it were practical from a technical viewpoint, which I am not sure about, would amount to a huge "bloat" of the installation size for MUSHclient (an extra 5.3 Mb) for something that virtually no users, apart from you, have requested.

It isn't totally clear from their page whether you also need wxWidgets as an extra download.

Frankly, it all seems too much. I don't like the idea of the "core" of MUSHclient representing maybe 10% of the total download, and the other 90% being wxLua, wxWidgets, etc.

Compare the size of wxLua (5.3 Mb) to the lua DLL (available here) which is 129 Kb. It is just a huge amount larger.

Quote:

You can't even open a web page without wasting script time constantly looking to *see* if the page finished loading in IE, because you can't simply have it "tell you" its done directly.


Well, loading web pages is asynchronous, that is, it takes time to do. I don't offhand see how you could get that to work, although the luasql package might allow that to a certain extent.

Quote:

Music players are crippled by the need to constantly ask what song it playing ...


MUSHclient wasn't designed to be a music player. I am concerned that if changes were made to implement this, perhaps at considerable effort, then the client would become more unreliable (or even, just larger) for the 99% of users who are not worried about trying to do such things.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #14 on Fri 23 Feb 2007 07:40 AM (UTC)
Message
And, as I said, I don't think it will take *near* as much work as you seem to think it will. And BTW, **BINGO**:

http://msdn2.microsoft.com/en-us/library/eeah46xd(VS.80).aspx

As of MFC 4.0 there was implemented a system called "message reflection". This is a MFC specific set of functions that allow you to redirect any event messages recieved by the main window to an event handler in its children. This means you could create a class whose "sole" job was to strip out events specific to script and handle them, using nothing more than fairly standard code and existing MFC features. Now, mind you, this may still mean that Mushclient would need to keep track of which events to watch for and which sinks are to be called when doing so, but that's just a lookup table, and *maybe* some script function to call object.invoke to have Mushclient create the connection itself. If however, wxLua has its own event handling system, then in, if it follows the specification for reflection, which I admit is a big if, then it will already be recieving those. If it doesn't, but again, does have a handler, all Nick needs is a class that impliments reflection for events in general, then code in there that passes the reflected events to the script engines event handler.

The first possibility requires two functions and maybe 100 lines of code (at a guess), the second case, if event handlers exist in wxLua, would require *no* code at all, the last case... Probably about 5 lines of code. Worst case, may require something to keep track of a table that is basically identical to the tables he already implimented to support *existing" function calls for things like OnPluginSend, etc. I.e., the code already exists to handle the function calls, its just sorting out the events that is the issue. And that is imho, not that big of a deal, since all it involves it calling "Invoke" on the object a few times to get the event name, and inform it to start generating events. Everything else is simply and extension of what the client is already doing. And that is the *worst case* situation.

I'll keep looking though, to see what else might effect how it works. Heck, assuming that the version of C++ I have can create at least MFC4.0 application (its very old), I might even try to see if I can get an example working. Maybe. Its not like I am that good at C++. lol
[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.

140,748 views.

This is page 1, subject is 5 pages long: 1 2  3  4  5  [Next page]

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]