[Kdenlive-devel] New Developer Onboard

[Vincent Pinon]

Hello Steve,

Thanks a lot for your enthusiastic mail...
sorry if my replies (inline) don't sound so optimistic:
not your fault, it's just that I haven't been very successful last times with 
this code and my hanger may leak into these lines :-)

Le jeudi 26 juin 2014, 15:22:00 Steve Guilford a écrit :
> [...]
> Lately, I been working on a very compact and powerful framework for the
> Oracle database that allows it to be used as a warehousing, streaming,
> transcoding, editing and rendering platform.
I know almost nothing about DB, but is it hard to make it run on other(s) DB 
engines that would come from the FOSS world?
And why is your work focused on Kdenlive and not MLT in general?

> [...]
> Kdenlive now has the potential to be the first cloud enabled, location
> independent, database capable video editing platform.  Given that the need
> for physical files has been eliminated, it also qualifies as potentially
> the most secure architecture available.  I hope to be able to post my
> modifications upstream in the near future.
I'm kind of a old school boy, and cloud is *for me* not a priority at the 
moment. But it may interest many other people, so if both versions can coexist 
smoothly why not?

> [...]
> In my opinion, the only way that Kdenlive can survive is to have a
> 'corporate sponsor'; one that has a vested interest in seeing the project
> supported and improved.  I am trying to build just such a business model. 
> I am looking to build a location independent, cloud enabled video editing
> environment.
Corporate sponsor can be comfortable for sure, and generally a good basis for 
quality, but as in your example, it can drive the app in mainly one special 
direction.

> [...]
> I've become somewhat familiar with Kdenlive's internals.  From what I've
> been seeing in the forum/dev-list traffic, there are not many that have an
> in-depth knowledge of Kdenlive.  That's obviously a big problem.
Agreed :-/

> I'd like to help !!!
Hurray! Please, jump into the boat ;-)

> [...]
> We need to build a current roster of developers - a list posted online - w/
> skills and specific areas of responsibility.
I think from the last 2 years of (low) activity, it is clear that there a 
flagrant lack of coders motivated by Kdenlive maintenance :'-(

> [...]
> We need to create a developer's roadmap
need to merge and sort ideas, will be discussed in Randa
> and documentation.  This is critical.
100% agree: it took me so long to roughly understand what happens where, and 
there are still many dark areas.
The problem is that there is an obvious need for code refactoring, almost the 
1st thing to do, so if we write a doc now it will be quickly (?) obsolete.

> We also need to dispel the myth that
> a video editor is way to complicated 'for me' when somebody approaches this
> project for the first time.
Hum, it's true that it is not so easy in its globality! But I hope that with 
another code organization it would be easier to play with internals...

> [...]
> Specific and tested instructions for creating a local
> source-tree from GIT. Instructions on how to upload your
> changes/mods/bug-fixes.
> Details on the bug system used, how to take responsibility for and post a
> fix for a bug. Instructions on how to utilize an IDE (i.e. Kdevelop,
> QtCreate, Eclipse) and create an appropriate IDE project. Details on using
> a UI builder such as QtDesigner.
> Coding standards.
I think the essentials are in KDE docs, we would mainly need links on our 
techbase page.

> Kdenlive source tree layout (so you know where to find things and what
> something is for)
Things are moving :-)

> Kdenlive data sources - a description of where Kdenlive keeps it's files
> (i.e. project, proxies, temp files) A description of the Kdenlive editing
> project file layout.
Right that it's useful to edit XML by hand sometimes, even for users.

> Details on how signals and slots are connected together in order to
> implement UI tasks and other asynchronous tasks within Kdenlive. A UI
> interface gallery so that one can flip through a group of images in order
> to find the desired UI and controlling 'view' module.

> A description of how
> multi-threading and multi-processing is used within Kdenlive (i.e.
> generating proxies, thumbnails, rendering etc). Details on Kdenlive's
> internal data structures.
> A C++ class layout/diagram.
I would love to have these at the moment!

> The developer's roadmap would be an evolving set of documents w/ provisions
> for user comments and contributions etc.  I think some of these items in
> the roadmap need to be in place before we start altering code.  Other items
> can be filled in as we go along.
Problem: this is boring, and good wills have their limits ;-)

> [...]
> there's really no way to brace and indent
> code other than GNU style.  Yes, it increases the vertical size of code
> somewhat but do remember that when K&R style was introduced, we were coding
> on VT-102 terminals w/ 80x24 screens.  (I have an original edition of K&R's
> Learning to Program in 'C' book - a classic - but I digress)  So, vertical
> size was an issue then.  Now - not so much.  However, in my mind, K&R
> style's legacy of hard to read code and style-induced bugs prevails.
> As you might have surmised, Kdenlive uses K&R style.  So, that would be the
> first code change I'd recommend - and it really would not involve any logic
> changes whatsoever.  It would be relatively straightforward and easy. 
> Braces on separate lines and 2 character indent levels.  I think that
> making these changes would be very important to our ability to attract
> other coders.  Hard to read code is always a turn-off.
Just a run of "indent" away...
But actually the free time I'm giving is mostly in the transportations, on a 
small 10" (600px height) display, so size matters (a bit) to me!
I didn't think formatting could be such an important issue...
If only we had the same as "go format"?!

> Once that is done the next area I'd address are the 'massive' routines and
> the kludgey if/else/if/nested-forever statements  that appear throughout
> the code.  In this instance I'm speaking of routines that accomplish way
> too much (they need to be broken up into smaller chunks) and 'if'
> statements that have too many levels to them.  Breaking up routines that
> are too big has a direct benefit of making the code more 'self
> documenting'.  This also tends to make it easier, later on, to modify
> sections w/out adversely impacting other areas of code.  Making these
> changes would serve as a lead-up and the beginnings of a refactoring
> effort.
Agree (after sorting "who does what" & gathering MVC things)

> Refactoring the code so that its easier to understand and modify will be
> crucial if we are to have a platform that is conducive to encompassing new
> features and capabilities.  The refactoring effort would also include a
> re-organization of the source code tree.  This provides a means of
> splitting the code into distinct MVC sections and have source files
> organized within separate subdirectories. Thanks For Reading This Far !!!
How long does the last technical discussion date back on this list? :-)

> That's all I've got for right now.  I hope some find this interesting and I
> look forward to possibly helping out w/ Kdenlive.  If anybody has access to
> an Oracle DB (you can download and install one for free for
> evaluation/development purposes) I'll set you up w/ my Multimedia
> framework.  It's all of 1.5Mb in size (I rounded up).
"free" here is not the one I like, sorry for being sensitive on the topic :-)

> If you need help setting up an Oracle DB, I can help w/ that too.  It's
> easier than it looks....
> 
> Sincerely.....Steve Guilford...
Thanks again for offering your help.
Don't hesitate to go forward: have a look at how to get involved in KDE in 
general; you must have a KDE account for forums, so I gess you also can edit 
docs in userbase/community wikis. You will have to ask an upgrade to developer 
account to be able to push to git (create your branch :-) )...
You can find some help on this list, but also a lot in the global KDE 
community.

Enjoy!

Vincent.