Hi, > Nathan, > > Thank you for creating the new thread - this is sensible. I was only > thinking that my proposal of new functionality might impact versioning > and therefore I slipped it into the 'version number' thread. > > Some comments below. > > > On Sun, 2011-07-17 at 18:16 +1200, Nathan Jones wrote: >> I've changed the subject to start a new thread since it was off topic. >> >> On 17 July 2011 02:53, Werner van Staden <v3n...@gmail.com> wrote: >> > Dear Pytrainer developers, >> > >> > I have kind of been lurking on the list and on Trac and I would like to >> > use this opportunity to introduce myself and discuss a contribution I >> > could possibly make to the project.
Thanks Werner for your interest and feedback, welcome on board! >> > Firstly, I am a daily user of Pytainer (my unconventional usage will be >> > clarified below) and I have submitted a few bug reports (and proposed >> > solutions) in the past. My congratulations to the project team for a >> > great Python application and for the well structured and well commented >> > code. >> >> Are you sure you're looking at the right code base? >> > :) well, OK, improvements and clean-ups can be made, but the existing > code is readable and logically separated according to the MVC model. I > was able to add and modify with ease. First priority is to make stuff work, then improvements are highly appreciated. I prefer more commits and less emails ;) >> > Specifically, I use Pytrainer to record and visualize my cardio-vascular >> > and weight training. For these purposes I have added code to my personal >> > copy of 1.8.0. as follows: >> > >> > 1. Added an 'Activity Types' tab to the preferences dialog where I can >> > create categories of 'Sports', e.g. 'Weights', 'Cardio-Vascular', etc >> > >> > 2. Created different PyGTK (Glade) interfaces for each 'Activity Type' >> > e.g. M.E.T. makes sense for cardio, but for weights the Add/Edit Sports >> > dialog asks for R.M. (repetition maximum). >> > >> > 3. To implement the above I have had to add MySQL tables and a few >> > additional fields to existing tables. >> > >> > That's it. I have not extended the additional functionality to category >> > specific graphs and calculators yet, but this is my intention. >> >> This sounds like a sensible change. I'm not sure that activity types >> should be editable though since it will mean data specific to activity >> types will be stored in a name/value pair table. A predetermined set >> of activity types would make for a better schema. >> > I agree. I had run into exactly the dilemma you mention - user created > activity types would pose the problem of associating appropriate labels > and DB fields. Whilst reviewing my code last night I realized that I had > abandoned the editable activity types at some point and opted for > hard-coded categories instead: Resistive, Cardio-Vascular & Weights. > > Regarding these new categories - for the sake of agreeing on a term - > shall we use 'categories' or 'activity types'? Also, the official > Pytrainer description refers to 'Resistive' sports. Do we want to keep > this as the activity type/category for cycling, running, etc, or would a > term such as 'geo-spacial', 'cross-country' or 'distance-based' be > preferred? Please comment. >> > >> > So, is the development team keen on implementing this additional >> > functionality in a future version of Pytrainer? If yes, what can I do to >> > progress the matter? If no, would there be any objection to a project >> > fork (with a related name)? I would prefer the first option, but will >> > respect the voice of democracy (or the BDFL). >> >> I would try to avoid forking. In my experience changes from new >> contributors are submitted as a patch and dgranda will review it and >> then add the author as a project member. >> > Glad you welcome the additional functionality. I will await a few more > agreements in principle from other member of the team. David, for your > review, how do I submit my patches? Not really fan of forking but you have the freedom to do it. My preferred way will be... Please submit your changes yourself! Your enhancement seems not trivial, so I bet your code is reliable. I would ask you to send me your SourceForge account (please create one if you don't have one already) so I can grant you write access to our svn repository. Then, I would also ask you to create an enhancement ticket and paste then a summary of changes just for tracking purposes. Please address it to 1.9.0 version as we will skip 1.8.1! Database stuff worries me most. I wanted to get rid of MySQL from long time ago just for simplicity purposes but always found more interesting task to do 0:) If something doesn't go as expected, we can always roll back your commits and ban your SF account ;) Thanks! David ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Pytrainer-devel mailing list Pytrainer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytrainer-devel
