<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Greetings Kdenlive developers....<br>
    <h3>Inroduction</h3>
    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.<br>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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.<br>
    <h3>My Media Framework</h3>
    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' !!!<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <h3>Kdenlive's Long-Term Viability</h3>
    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.<br>
    <br>
    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.<br>
    <br>
    <b>I'd like to help !!!</b>  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.<br>
    <h3>A Way Forward</h3>
    That said, there's some significant steps that need to be taken
    before that can happen.  Here's how I see it.<br>
    <br>
    We need to build a current roster of developers - a list posted
    online - w/ skills and specific areas of responsibility.<br>
    <br>
    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:<br>
    <ul>
      <li>Specific and tested instructions for creating a local
        source-tree from GIT.</li>
      <li>Instructions on how to upload your changes/mods/bug-fixes.</li>
      <li>Details on the bug system used, how to take responsibility for
        and post a fix for a bug.<br>
      </li>
      <li>Instructions on how to utilize an IDE (i.e. Kdevelop,
        QtCreate, Eclipse) and create an appropriate IDE project.  </li>
      <li>Details on using a UI builder such as QtDesigner.</li>
      <li>Coding standards.<br>
      </li>
      <li>Kdenlive source tree layout (so you know where to find things
        and what something is for)</li>
      <li>Details on Kdenlive's build system.<br>
      </li>
      <li>Kdenlive data sources - a description of where Kdenlive keeps
        it's files (i.e. project, proxies, temp files)</li>
      <li>A description of the Kdenlive editing project file layout.</li>
      <li>Details on how signals and slots are connected together in
        order to implement UI tasks and other asynchronous tasks within
        Kdenlive.</li>
      <li>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.</li>
      <li>A description of how multi-threading and multi-processing is
        used within Kdenlive (i.e. generating proxies, thumbnails,
        rendering etc).</li>
      <li>Details on Kdenlive's internal data structures.</li>
      <li>A C++ class layout/diagram.<br>
      </li>
    </ul>
    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.<br>
    <br>
    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.<br>
    <h3>Code Changes</h3>
    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.<br>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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.<br>
    <h3>Thanks For Reading This Far !!!</h3>
    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 <b>1.5Mb</b> in size (I
    rounded up).<br>
    <br>
    If you need help setting up an Oracle DB, I can help w/ that too. 
    It's easier than it looks....<br>
    <br>
    Sincerely.....Steve Guilford...>>><br>
    <pre class="moz-signature" cols="72">-- 
Steve Guilford
<a class="moz-txt-link-freetext" href="http://www.dbplugins.com">http://www.dbplugins.com</a></pre>
  </body>
</html>