Hi. I'm agree with move to a new namespace, like Guilherme suggested. Some months ago I was thinking for my self about this.
Unfortunately InterfaceEditor have some classes working with files, xml etc, and others with GUI and I didn't create a umitInterfaceEditor.gui. But I could change it if it is the will. Are there a easy way to do this refactor? In Eclipse (with Java) there are several features to "refactoring" and it's very nice. I don't know if it works with Python too. Well, make all refactor by hand doesn't sound good. On Fri, Feb 27, 2009 at 11:52 AM, Guilherme Polo <[email protected]> wrote: > Hi, > > Can we move to a cleaner namespace in umit ? I'm hoping to change it from: > > umitCore > umitCore.radialnet > umitGUI > umitGUI.radialnet > umitDB > umitInterfaceEditor > umitInterfaceEditor.selectborder > umitInventory > umitPlugin > > to: > > umit > umit.core > umit.core.radialnet > umit.gui > umit.gui.radialnet > umit.db > umit.interfaceeditor > umit.interfaceeditor.selectborder > umit.inventory > umit.plugin > > higwidgets stay as it is, except for some files. > higwidgets.higanimates for instance is nice, but how come that got > inside higwidgets ? For this kind of widgets we could add a > umit.gui.widgets. > > Then there is the remaining issue about the umit executable file and > this new umit package. We could move all the code currently in this > umit file to a module named main inside this new umit package. The > unix installer could then create a umit executable (which could be > either a shellscript that executes "python /path/to/umit/main.py" or > something else that imports main.py and run main(sys.argv)) at the > appropriated place. > > My motivation to do this namespace move is that Umit is limiting > itself to very few packages, files related to the scheduler could move > to another package, umitInventory could be split too (and it would be > good to so). I'm also planning to create something to merge > configuration files and it would live in another package, since I > don't think it makes much sense to place it in any of the existing > packages. > Another point to consider is that it pollutes site-packages for no good > reason. > > Regards, > > -- > -- Guilherme H. Polo Goncalves > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Umit-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/umit-devel > Regards, -- Luís A. Bastião Silva ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
