freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FR-devel] Updates to System_Command stuff


From: Rich Kilmer
Subject: [FR-devel] Updates to System_Command stuff
Date: Sun, 15 Sep 2002 23:09:07 -0400

Laurent (and Curt),

I have completed study of the code to date on the FreeRIDE GUI and want
to pursue a bit of refactoring.  My main goal is to preserve the
functinality that's implemented, but restructure the way that the
FreeBASE DataBus is used.  If there's one thing I think we need to use
consistently is the DataBus.

I will use the System_Command plugins as a working example.

Right now for each command we store an instance of a GenericCommand
object as the .data of the command's slot.  That object accepts a String
as a constructor that encodes a bunch of stuff (menu, accelerator, hint
text) seperated by \t (tabs) and pass a block/proc to call when the
command is executed.  All of this data could be represented within the
DataBus itself in slots like:

cslot = bus['/system/ui/commands/FileNew']
cslot.set_proc {|*params| ... }
cslot['./Text'].data = '&New'
cslot['./Accelerator'] = 'Ctl-N'
cslot['./Description'] = 'Create new edit pane'

This seems more complex, but it can be simplified by adding a manager
that presents an API to create commands:

cmgr = bus['/system/ui/commands'].manager
cmgr.add("FileNew", 
         "&New", 
         "Ctl-N", 
         "Create new edit pane" ) {|*params| ...}

and...

cmgr.each_command {|slot| ...}

and...

cmgr.delete("FileNew")

etc...

I know this messes with the whole CommandManager structure but I have
some thoughts there too...

This is only one example of how the DataBus could be used to store a
structure that would otherwise require an object. 

Thoughts about these changes, and my refactoring directions?

BTW:  We can also delete the file System_Commands.rb and change the
plugin.xml file...remove the entry for System_Commands and changing the
name of the subsystem to System_Commands.  Since a Subsystem is itself
represented as a plugin and it waits/depends on all plugins within it,
it can serve the same purpose that the System_Commands.rb file does
right now.  I did this on my machine and it works the same.

Regards,

Rich






reply via email to

[Prev in Thread] Current Thread [Next in Thread]