Re: wxpythonui.py update

Will,

I believe that it would be a good idea also.  In order to re-use the
Alias dialog for Actions, I ended up adding a mode paramater. Since the
display widgets were the same on each form, I just decided to use the
same form and change the labels based on which mode we are in. If we are
ALIAS mode, the widgets reflect one thing.. ACTION mode, they reflect
another.  So I have several places  where I check the modes and do
different things (See Defendents Exhibit A below for an example).  I
think it would simplify the code below and also allow for a flow like
the pseudocode that follows...

Query for all managers
Store name of all *configurable* managers in ui builder class
build menu based on list of available managers.
When menu item is selected,
    call getParameters for selected manager
    build data entry form from results of getParameters
When list type widget needs updated,
    call getInfoMappings
    build row info from results
    use list of rows to update widget


I maintain two seperate dictionaries now, one for aliases and one for
actions.  These are mainly used for rebuilding the list interface.  I
can easily see these being managed by a python class similar to....

[NOTE: this is off the top of my head.. so it needs alot of work still]
class DynamicUI:
    def __init__(self):
        self.managed = []
    def addManager(self, managername):
        self.managed.Append(managername)
    def getMenuEntries(self):
        return self.managed
    def getDataFields(self, managername):
        return exported.getParameters(managername)
    def getListCtrlContents(self, managername):
        heading_order = self.getDataFields(managername)
        mappings = exported.getInfoMappings(managername)
        contents = []
        for entry in mappings:
            row = []
            for heading in heading_order:
                row.append(entry[heading])
            contents.append(row)
        return contents
    def buildEntryForm(self):
        #snipping for brevity
        #make container classes
        #make list control
        widget_names = self.getDataFields()
        for widget in widget_names:
            label = wxStaticText(self, -1, widget)
            text_ctrl = wxTextCtrl(self, -1, '')
            #add widgets to container

LOL.. my mind is already thinking of how I have to change the ui code to
handle the class I just mentioned and the things the class still would
need.  Looks like a good project for the weekend if time permits...


#Exhibit A - snippet showing usage of mode
def getCommandsFromMud(self, mode):
        ses = exported.get_current_session()
        cm = exported.get_manager("command")

        if mode == ALIAS:
            am = exported.get_manager("alias")
        elif mode == ACTION:
            am = exported.get_manager("action")
            
        defined_commands = am.getInfo(ses)

        for mem in defined_commands:
            command, args = mem.split(" ", 1)

            argumentparser = cm.getArgParser(command)
            if argparser == None:
                args = args.split(" ")

            else:
                fixedmem = mem
                if len(fixedmem) > 0 and fixedmem.startswith("^"):
                    fixedmem = fixedmem[1:]

                try:
                    args = argumentparser.parse(args)
                    args["command"] = command
                except ValueError, e:
                    print "ack--valueerror!"

                except argparser.ParserException, e:
                    print "ack--parserexception"
            
            if mode == ALIAS:
                self.alias_dict[args['alias']] = args['expansion']
            elif mode == ACTION:
                self.action_dict[args['trigger']] = args['action']

This idea of yours would also help with part of something else I have
been thinking of.  When I make my character files, I often put things
like speedwalking directions into a single file.  Then my character file
just has to #read in the speedwalking file but I only have to update one
file when I add more directions.  One of the reasons I hesitated to put
save capability in the gui is because a #write just dumps to a simgle
file.  With the above, I could at least split up the saves a little
easier, and save a file by manager type.  It wouldnt solve all the
difficulties.. but it is a step closer.

Of course on the other hand,  if this isn't something that would help
alot of people, it may not be worth spending the time on it.  


just my 2cents..

Bryan Muir


On Fri, 2003-09-26 at 12:14, will wrote:
> 
> Managers manage data--but it's somewhat difficult for an outside source to
> know about what the data being managed is and what it means.  I'm
> wondering if it would help for me to add some introspective methods to the
> manager api that tell you what the data being stored means.
> 
> For example, with an alias, you have the alias and its expansion.  When
> you call getInfo, it returns a list of lyntin commands to rebuild the data
> item.  But what if we had a getInfoMappings which return a list of
> mappings?  So if I had an alias:
> 
>    #alias {ddk} {unlock door with key;open door}
> 
> then getInfoMappings would return:
> 
>    [ { "alias": "ddk", "expansion": "unlock door with key;open door" } ]
> 
> Then we could add another function getParameters which returns a list of
> all the thigns we store for a given data item (taht aren't calculated
> internally).  For alias, this would return:
> 
>    [ "alias", "expansion" ]
> 
> (It would be order sensitive--probably match the comand line arguments.)
> 
> Then we add getParameterDesc which takes in one of those parameters and
> returns a string describing it:
> 
>    getParameterDesc("alias")
> 
>    could return
> 
>    "The name of the alias."
> 
> Or something along those lines.  If we did that, then you would only have
> to build one dialog to handle all the managers.  You coudl figure out what
> managers were available by using exported.get_engine()._managers.keys()
> (I might have an exported functino for getting a list of all the managers
> available--if not, I can add that too).  Then you maintain an itnernal
> list of all the managers you are capable of configuring.  Alternatively,
> we could have managers tell you whether they are configurable in this
> manner (getConfigurable returns a 1/0 or something).
> 
> Any thoughts?  It would definitely make sophisticated gui interfaces much
> easier in respects to building user-friendly data-entry dialogues.  (At
> least, I think it would.)
> 
> /will
> 
> 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf