Mudlet features and API requests
Re: Mudlet API requests
Didn't mean to add anything to the UI. Just that in a multiline/and trigger, if only one of the patterns is a regexp the matches table would automatically be set to that entry in multimatches. No UI cluttering required.
Re: Mudlet API requests
You can always make them be shielded regexes then, and you'll have matches on the regex. Performance is pretty much the same as tested. I just see such workarounds adding confusion while not being that overly helpful.
Re: Mudlet API requests
I keep seeing people use the term "shielded regexp" ... what's it mean? A regex further down a filter chain or something?
Re: Mudlet API requests
A regular expression pattern chained to something significantly faster (generally a "beginning of line" pattern) so that the regex is never calculated unless the beginning of line matches.WillFa wrote:I keep seeing people use the term "shielded regexp" ... what's it mean? A regex further down a filter chain or something?
Regex is slow, so keeping them from firing unless necessary is good!
Re: Mudlet API requests
Much like using anonymous functions in the temp* functions, I'd like to be able to use anonymous functions in click callbacks, as opposed to just strings.
Also, it would be nice to be able to use nested table values for click callbacks. <my_system.callback> as opposed to just <callback>.
Also, it would be nice to be able to use nested table values for click callbacks. <my_system.callback> as opposed to just <callback>.
Re: Mudlet API requests
Integration with DBus signals.
Listen for signals
Register a signal
I'd like to see this implemented basically, like the current script-events are done. I would register a dbus signal in the scripts, which Mudlet would then 'listen' for:
Match: 'im.pidgin.purple.ImMessageRecieved'
Script: <write some lua code to execute on DBus signal>
I found lua Dbus bindings here, and successfully included it with Mudlet loadup (just printing out the dbus connections. However, when trying to initiate the mainloop() to LISTEN for a signal, it locks up Mudlet.
So, I am suggesting that native support be added in Mudlet, for DBus.
Listen for signals
Register a signal
I'd like to see this implemented basically, like the current script-events are done. I would register a dbus signal in the scripts, which Mudlet would then 'listen' for:
Match: 'im.pidgin.purple.ImMessageRecieved'
Script: <write some lua code to execute on DBus signal>
I found lua Dbus bindings here, and successfully included it with Mudlet loadup (just printing out the dbus connections. However, when trying to initiate the mainloop() to LISTEN for a signal, it locks up Mudlet.
So, I am suggesting that native support be added in Mudlet, for DBus.
-
- Posts: 5
- Joined: Wed Jul 21, 2010 4:26 am
Re: Mudlet API requests
I'd just like a prototype of all mudlet functions, in alphabetical order please.
-
- Posts: 5
- Joined: Wed Jul 21, 2010 4:26 am
Re: Mudlet API requests
Just a few things....
MouseRelease event for labels (If you look at most all interfaces the things attached to mouse clicks are sounds and changing the mouse pointer... not actions. This allows a user to change their mind after the click by moving the mouse off the button. It would also be nice to know the location of the click and the release as well as what button was clicked)
Mouse rollover event for labels.
Tooltips (notes that appear over a button/label when mouse is hovering over it. Attached to a rollover event)
Set mouse pointer icon.
Current mouse location (this would seldom get used but would allow you to redraw windows/labels based on the mouse location. Example: click a label, move mouse and have label follow mouse, release mouse and have window/label assigned to a new location on the screen)
And lastly,
A simple modal dialog allowing 1-3 buttons and at least 1 text value to be entered. (This would be a tremendous help and could even be used to setup "wizards" for making aliases, triggers, buttons, .....)
Dispite my wishlist above, MUDlet has been a pleasure to use and it's strengths far outwiegh it's shortcomings.
MouseRelease event for labels (If you look at most all interfaces the things attached to mouse clicks are sounds and changing the mouse pointer... not actions. This allows a user to change their mind after the click by moving the mouse off the button. It would also be nice to know the location of the click and the release as well as what button was clicked)
Mouse rollover event for labels.
Tooltips (notes that appear over a button/label when mouse is hovering over it. Attached to a rollover event)
Set mouse pointer icon.
Current mouse location (this would seldom get used but would allow you to redraw windows/labels based on the mouse location. Example: click a label, move mouse and have label follow mouse, release mouse and have window/label assigned to a new location on the screen)
And lastly,
A simple modal dialog allowing 1-3 buttons and at least 1 text value to be entered. (This would be a tremendous help and could even be used to setup "wizards" for making aliases, triggers, buttons, .....)
Dispite my wishlist above, MUDlet has been a pleasure to use and it's strengths far outwiegh it's shortcomings.