[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]