From kde-promo Tue Jun 07 10:17:08 2011 From: Pau Garcia i Quiles Date: Tue, 07 Jun 2011 10:17:08 +0000 To: kde-promo Subject: [kde-promo] Re: The Future of our Frameworks Message-Id: X-MARC-Message: https://marc.info/?l=kde-promo&m=130744189817140 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 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.