On Fri, Feb 27, 2009 at 11:06 AM, Adriano Monteiro Marques <[email protected]> wrote: > Hello Guilherme, > > Thank you for your remarks. Follows my comments on your and Rodolfo's > remarks: > >> On Fri, Feb 27, 2009 at 8: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 >> >> I agree totally with this structure. I like the idea of having a >> 'umit' central package. >> Additionaly, for UmitWeb, we can have the extra packages: >> >> umit.web >> umit.web.views > > That's a good idea, IMHO. I bought it ;-) > > >>> 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. >> >> I guess higwidgets is a separated project, owned by Cleber, but we >> need to take a look on that. > > HIGWidgets was a project started at Global Red, a company which Cleber owned > in the past. But, the company was sold, changed business and I made a fork > of it long time ago. Therefore, the changes we all have conducted are under > my copyright. > >>> 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 only concern here is that it could make the installation process a bit > harder to implement. Maybe, we could decide on a better substitutive name in > place of main.py or the umit module. >
What about creating a scripts directory (or some better name maybe) and put umit and umit_scheduler.py there ? > > Cheers! > > --- > Adriano Monteiro Marques > > http://www.thoughtspad.com > http://www.umitproject.org > http://blog.umitproject.org > http://www.pythonbenelux.org > > "Don't stay in bed, unless you can make money in bed." - George Burns > > -- -- 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
