[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    [kde-promo] Re: The Future of our Frameworks
From:       Pau Garcia i Quiles <pgquiles () elpauer ! org>
Date:       2011-06-07 10:17:08
Message-ID: BANLkTiket4Eb4MtVJU6HGmk7aQP+5C9xZA () mail ! gmail ! com
[Download RAW message or body]

Hi,

I had exactly the same question because IMHO there is a confusion
between "framework" and "library" here.

Library = set of related functions and helper methods and classes

Framework = Library + a "way" of working with it (i. e. workflow,
tools you need to use, conventions, etc). For instance, Rails is a
framework because it imposes a set of conventions you cannot change
(and you webapps will not work unless you follow them)

I'd say with the modularization we are splitting into *libraries*, not
into *frameworks* because we do not impose a set of rules, tools,
workflow, etc to work with it.




On Tue, Jun 7, 2011 at 12:05 PM, Anne-Marie Mahfouf
<annemarie.mahfouf@free.fr> wrote:
> Hi Sebas,
> 
> For promo and translation of future announcements I'd like to get a basic
> explanation of what the English word "framework" refers to. It can be quite
> fuzzy in French for exemple depending on the meaning. Other translators would
> also welcome a explanation on why you chose this word and what should it
> describe
> "we want to consistently use the term "Frameworks",
> this includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime,
> kdepim-runtime and kdesupport."
> Are these the libs that workspaces and KDE applications (software? Software
> Compilation?) will be built on? Which would make "framework" = "basic blocks"
> or something like that or something else?
> 
> A definition "framework = ..." would help to ensure we convey this correctly in
> all languages.
> 
> Thanks in advance,
> 
> Anne-Marie
> 
> Le Monday 6 June 2011 19:26:38, Sebastian Kügler a écrit :
> > Hi all,
> > 
> > You've probably been aware that a rather sizable group of KDE developers
> > and stakeholders in our development platform is meeting in Randa,
> > Switzerland to discuss the future of our development frameworks, with the
> > big topic being "modularization of kdelibs". We've had a number of great
> > discussions here about various technical and process-related topics. We
> > are still in the process of making the results digestable, transforming
> > our notes into something that is understandable for those that haven't
> > been able to participate in these -- very productive -- sessions in
> > person.
> > 
> > Let me already give you some information on the bigger picture we came up
> > with here, as you are all probably very curious about that. The overall
> > theme was the modularization of kdelibs, kde-runtime, kdepimlibs,
> > kdepim-runtine and kdesupport. With Qt5 -- a change in binary interface --
> > having been announced, it is a good point in time to introduce some
> > changes to our frameworks that are only possible if we change the ABI --
> > which Qt5 will do for us anyway.
> > 
> > 
> > What is the scope?
> > 
> > Instead of Platform, we want to consistently use the term "Frameworks",
> > this includes what we currently refer to as kdelibs, kdepimlibs,
> > kde-runtime, kdepim-runtime and kdesupport. We explicitely are not talking
> > about our apps and workspaces, but read on.
> > 
> > 
> > What do we want to achieve, and why?
> > 
> > We want to make it possible to use our frameworks in Qt projects without
> > significant additional dependencies. This means:
> > 
> > * We reach out to the Qt development community in a more focused way
> > * We make it easier to use our frameworks
> > * We lower the barrier for contributions
> > * We make our frameworks more suitable for mobile and device-spectrum use
> > cases
> > * We make it possible to select a specific set of features developers would
> > like to use
> > * We improve our QA processes, leading to better quality apps and
> > frameworks
> > 
> > We want this to happen with ...
> > * ... no disruption for our users
> > * ... little to no source incompatibilities
> > * ... most apps not needing any significant changes
> > * ... changes, if at all necessary being kept to a minimum
> > 
> > 
> > What does it mean for users?
> > 
> > * No disruption
> > * Most probably invisible
> > * Short term: Iit becomes easier to run kDE apps outside of the Plasma
> > workspaces, including other operating systems
> > * Longer term: We will probably see more apps using KDE technology
> > 
> > 
> > What does it mean for developers?
> > 
> > * We will maintain source compabitility as much as possible
> > * The impact for existing apps will be minimal
> > * We will provide a compabitility library as additional measure to reduce
> > the impact of these changes
> > 
> > 
> > What does it mean for packagers?
> > 
> > * We make it possible to ship our frameworks in a more modular way
> > * We also plan to provide "monolithic tarballs" much as we do now,
> > depending on the needs and preferences of downstreams
> > 
> > 
> > Please note that this is *not* KDE5, as it doesn't refer to our community,
> > but about our development frameworks. At this point there is also no
> > benefit in talking about KDE 5, since that just opens the door to
> > misinformation. This is also clearly not about our workspaces, or
> > applications. (See
> > http://vizzzion.org/blog/2011/06/there-is-no-kde5/ for a quick
> > explanation.)
> > 
> > In order to prevent this thread from growing into an unmanageable load of
> > hundreds of emails, please post specific questions as separate threads.
> > (You can of course reply with praise to this, but anything that is likely
> > to spark a more detailed discussion is probably better off in a separate
> > thread.)
> > 
> > Thanks for your attention, and cheers from a wonderful Switzerland,
> 
> _______________________________________________
> This message is from the kde-promo mailing list.
> 
> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
> or temporarily stop your subscription. 



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
or temporarily stop your subscription.


[prev in list] [next in list] [prev in thread] [next in thread]