[Kdenlive-devel] New Developer Onboard

Simon A. Eugster simon.eu at gmail.com
Sun Jun 29 20:37:39 UTC 2014


Hi Steve,

thanks for the mail, and welcome here! Great to have you working on 
Kdenlive. As Anna asked, can you make it to Randa, at least for a few 
days? https://sprints.kde.org/sprint/212 This would be a great 
opportunity to discuss those points with the developers. And to taste 
some Original Swiss Raclette!

Simon

Am 27.06.2014 00:22, schrieb Steve Guilford:
> Greetings Kdenlive developers....
>
>
>       Inroduction
>
> I'd like to introduce myself.  My name is Steve Guilford and I'm located
> in Los Angeles, Ca.  Some may have noticed my postings on the forum.
>
> I have over 32 years of programming experience.  My speciality is in
> creating frameworks, API and toolkits.  Mainly in the realm of systems
> integration tasks, hardware integration etc. In 32 years I've done a lot
> of systems programming, architecture design, user applications, systems
> integration, database design, data transformations, hardware
> integrations, software/systems conversions, forensic analysis etc. etc.
> I dropped out of college in 1982 in order to go to work.  I've been
> self-employed for 20+ years.  Computers are still like toys to me.
>
> My Oracle expertise dates back to 1984.  In 1986 I was part of a 4 man
> team that converted the Oracle DB - from source - to run on the Wang-VS
> line of mini-computers (that sure dates me).  I'm fluent in multiple
> languages, databases, operating systems and object oriented programming
> frameworks.  In the '90s I made a living selling telecommunications
> software that I created.  I had some installations that lasted, with
> lucrative support contracts, for upwards of 15 years or more.
>
> I also created the enabling technology in the '90s for a very successful
> medical services firm.  This product tracked the admission and
> discharging of patients from hospitals and provided doctors w/ a PDA
> that uploaded patient info (via an old-fashioned modem !!!) to a central
> server.  Customized, dynamic surveys were then created and reports
> generated for fax delivery to primary care physicians.
>
>
>       My Media Framework
>
> 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.  This is done in a manner
> that eliminates the need for physical files.  All assets are stored in
> the database.  The framework allows you to keep video data in any
> table.  It does not impose any 'schema' restrictions whatsoever.  This
> framework is 'ready to go' !!!
>
> I've modified Kdenlive in a very succinct and discrete manner to allow
> it to source it's project from the DB as well as edit and render content
> to-and-from in the manner just described.  My modifications are 'compile
> time' enabled via a build switch.  The modifications are contained
> within '#ifdef' statements.  I modified 8 source files as well as some
> header files.  I added 5 UI modules and corresponding UI widgets to
> allow for the sourcing of projects, access/assignment of content to a
> project and a 'render' screen. I've modified the CmakeLists.txt file to
> enable the compile time inclusion of these features.
>
> 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.
>
>
>       Kdenlive's Long-Term Viability
>
> 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.  In this model, seats on the system
> are free !!!  There would be no charge for use of the editor.  The cloud
> system however does provide secure location independent storage and
> access as well as consolidated high-performance rendering/transcoding
> services.  That's what you pay for.  This model could be attractive to
> media productions that must incorporate content from multiple locations
> with the secure delivery of "daily's" for approval by lead
> directors/editors.  There are other benefits as well but I'll leave that
> for another thread.
>
> 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.
>
> *I'd like to help !!!*  Hopefully my 32 years of practical experience
> can be useful.  Kdenlive can be a terrific platform for open-source
> collaborative work.  Developers that work on Kdenlive would get exposure
> to a wide variety of programming disciplines and concepts from
> multi-threading, multi-processing, frameworks, build systems, graphics,
> hardware, documentation etc. etc.  Not every open-source project offers
> the breadth of disciplines that Kdenlive does.  I think it could have
> strong potential as a 'teaching tool' within academia and the
> open-source community.  If that happens, the quality and support
> associated w/ Kdenlive could rival the small group of high-end
> professional NLE's.  There would also be spillover to projects such as
> Blender, Audacity etc. etc.
>
>
>       A Way Forward
>
> That said, there's some significant steps that need to be taken before
> that can happen.  Here's how I see it.
>
> We need to build a current roster of developers - a list posted online -
> w/ skills and specific areas of responsibility.
>
> We need to create a developer's roadmap and documentation.  This is
> critical.  In order to attract other coders we need to make it as easy
> for them to come-up-to-speed as possible.  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.  The roadmap would take
> somebody from start-to-finish in terms of getting them going.  Here's
> some of the things it would contain:
>
>   * 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.
>   * Kdenlive source tree layout (so you know where to find things and
>     what something is for)
>   * Details on Kdenlive's build system.
>   * 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.
>   * 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.
>
> 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.
>
> We need to advertise Kdenlive as a viable, attractive 'learning'
> platform in order to attract academia an other members of the OpenSource
> community.  We need a build a reputation of being a worthwhile project
> to be involved in.
>
>
>       Code Changes
>
> As far as code changes are concerned, I definitely have my opinions on
> that.  Please excuse me though - I have 32 years of coding habits built
> up and over time I've seen a lot and done a lot.  Kdenlive's source code
> suffers greatly from 'formatting' issues.  I know some would argue, but
> after 32 years and countless projects and teams that I've either been
> part of or led, or done by myself, 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.
>
> 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.
>
> 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 !!!
>
> 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).
>
> If you need help setting up an Oracle DB, I can help w/ that too. It's
> easier than it looks....
>
> Sincerely.....Steve Guilford...>>>
>
> --
> Steve Guilford
> http://www.dbplugins.com
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
>
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
>




More information about the Kdenlive mailing list