程序接口
其实设计初衷是无需使用源代码，直接使用下方提供的jar包即可进行二次开发。因为毕竟通过XML就可以对界面元素进行定义了。如果要把这个框架集成到你的应用程序中，并执行你的具体动作，只需要对free.Shell这个类进行一个函数重载即可。
String message = "Perform action " + action + ".";
this.lbStatusMessage.setText(message);
在Shell这个类中，界面上所有的按钮、菜单、列表等被点击后，都会回调这个Shell的command方法，并传回action字符串，也就是我们在XML中定义的动作码。接着你就用if else或者case啥的进行处理动作吧!当然也可以调用addTab方法在Shell界面中添加一个tab页面。其使用方法会下次详细阐述。
关于效率、内存、布局和其他
有朋友说很担心执行效率、内存占用。这是对Swing常被攻击的的一个老话题了。简单直接的回答是：Swing效率没问题。内存占用没问题。满眼哗哗一片字符串，就一定占内存吗?table有1000行，渲染的花里胡哨，就内存问题吗?完全不是这么一回事。例如，如果你了解Swing的table的renderer机制，其实无论表格有多少行，一个列是用同一个renderer实例来paint的。注意，是一个实例哈。editor也是一样。很多初学者以为这一列用JComboBox编辑，1000行就会create成1000个ComboBox。那就完全错了。Renderer就是一个“橡皮章”，一个章，不停的在每个格子里面“盖章”，重绘就重新盖;Editor就是当一个“萝卜”，哪个“坑”需要编辑时，table动态把它“放”在这个单元格(坑)上面，下次下个单元格需要编辑，再被挪过去。对于一个列来说，就一个萝卜，一个橡皮章。怎么会说“占用内存”?如果说1000行字符串占用内存，那这些字符串用什么语言和平台不占用内存呢?同样字符串在不同的语言和平台上可以说占用内存几乎没什么差别。这个以后可以专门讨论。
在这个本程序中，状态栏上有一个封装好的内存监控工具条：
它的作用是监测目前Java的总的申请的堆内存以及使用的内存。相关代码如下：
long usedMemory = memorymbean.getHeapMemoryUsage().getUsed();
long totalMemory = memorymbean.getHeapMemoryUsage().getMax();
上面图片中的“18M/63M”标明默认Java堆大小是64M目前使用了18M。尝试多打开一些表格界面、拓扑图界面，可见内存使用并不是很多。
说Swing的效率低，也不是很有说服力。其实Swing本质还是Java2D在paint东西，看看那些杂乱的Metal***UI源码就知道了。不过Swing确实设计的够复杂啰嗦，一个LnF就能绕死人。这些机制会导致Swing慢一些。不过说到底程序的快慢瓶颈还不是在Swing上，还是在如何设计和使用上。例如线程的处理等等，这些都不是初学者很容易搞定的东西。这也导致Swing总是被贴上“慢”的标签。
