[Kde-bindings] Twine2 (PyKDE* code generation tool) Naming

[Scott Kitterman]

On Monday, April 13, 2015 08:03:47 PM Scott Kitterman wrote:
> On Monday, April 06, 2015 12:45:36 PM Scott Kitterman wrote:
> > I've started looking at refactoring twine2 into a common module that can
> > be
> > used in (and shipped with) kf5 and the legacy KDE SC bindings.  It seems
> > reasonably tractable.
> > 
> > I need a Python module name for the common module.  I don't think twine2
> > is
> > a good name since twine is already in use for a popular tool on pypi:
> > 
> > https://pypi.python.org/pypi/twine/1.5.0
> > 
> > My intent, unless someone objects is to do the following:
> > 
> > 1.  Move all the current hard coded file locations to a configuration file
> > to make it easier for everyone to use twine2 without having to edit
> > source.
> 
> This is done (and once I push what I have locally in git) also includes the
> ability to specify an alternate config file location.
> 
> I'm on to #2 and #3 below.   For TBD, the last thing I suggested is
> 'kbindinggenerator' for the Python module name.  No on objected since I
> suggested it almost a week ago, so I plan to consider that a reasonable
> color for a bike shed and move on.
> 
> Scott K
> 
> > 2.  Move the non-binding specific code into a module with TBD name.  It
> > doesn't need to be pretty, just distinct, so I'm thinking perhaps
> > ksipbindings, but I'd love better suggestions.
> > 
> > 3.  Refactor kf5.py, kdelibs.py, and kdeedu.py to use the module.

#2 and #3 are done now.  kdelibs.py and kdeedu.py still use hard coded file 
locations though.

> > 4.  Add more command line options to make things generally more
> > configurable.

I do have some additional ideas in terms of making is easier to use, but the 
biggest thing that would make it easier to use is if it could actually 
successfully parse everything.  Help still desired on that (see previous 
messages to the list).

Scott K