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