On Friday, June 8, 2012 13:47:18 Aurélien Gâteau wrote: > My goal with this diagram was to illustrate end-user products and how they > are grouped under umbrella terms, rather than teams.
then it isn't an architecture diagram, and it shouldn't include things like kdelibs. how products are presented to the public and how the architecture is designed is not a 1:1 relationship. at least not in Plasma, and that is 100% purposeful. > It makes total sense > to me that Plasma developers are responsible for libplasma from kdelibs, > Plasma components in kde-runtime, plasma-desktop, plasma-netbook from > kde-workspace indeed. and the architecture is such that those shared components are shared and there is not a huge delta between desktop, netbook and workspace. another fun tidbit: did you know that the search & launch (aka SAL) containment was designed for Netbook, but is also used for the Plasma KPart now and is very popular amongst Desktop users? :) > and, I guess, the Active UI part of applications like Okular > and Marble (at least to bootstrap the process of having Active-friendly > applications) we are not responsible for Marble's Active UI at all. we invited Marble to get involved and they have. we are also not responsible for Kontact Touch or Calligra Active. we are big supporters of them and do help as we can, but then many of us do that in general because that's what we do in KDE :) we contributed the Okular UI to Okular itself, and we hope that in future more of the apps will have touch UIs maintained by their respective teams in future because this does not scale for us. we're doing it now because we have to. that said, this is a team structure issue, not an architecture or even a product issue. btw... every time someone says "I guess..." and then instead of asking a question makes a statement of "fact" a kitten dies a horrible, horrible death. please, stop guessing and start asking. we'll save a lot of pain that way. > > Food for thought: How many Linux kernel developers do you know that try to > > divide the Linux kernel in subprojects for servers, desktops, embedded > > systems? > > This comparison is not adapted IMO: the kernel is one single product, with > many modules. Your comparison would work if we were shipping only one shell > with many applets. plasma is a single product with many modules. that's one of the core design concepts. we ship one set of applets (with a few specific to different shells), share code between shells (libplasmagenericshell's name is a good hint there :). this is not completely unlike the various arch/ implementations found in the kernel source tree. so it is a very accurate comparison. it is a comparison that drove the design of plasma, so that's unsurprising. perhaps instead of the comparison being not adapted, your understanding is incorrect. perhaps we offered that comparison to help improve your understanding. instead of arguing for your understanding to the people who actually designed and wrote the code in question, you could consider the comparison made and think about how that may require adjustment in your understanding. > And actually, the kernel is very much based on subprojects: you won't find a > lot of filesystem developers working on usb support or network-stack > developers debugging the arm device-tree mess. and it's exactly the same in plasma. lots of people work only on specific things. we have one guy who only works on folderview bugs and performance, for instance. it's still one whole project from which products are derived based on the modules used and the build configuration. let's try this: Linux is an OS kernel technology from which products are derived based on the modules used, which are worked on by various people in sub-projects with sharp focus, and the build configuration selected. Plasma is a UX technology from which products are derived based on the modules used, which are worked on by various people in sub-projects with sharp focus, and the build configuration selected. both are accurate high-level overviews of the respective projects. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
