If you look at kdebase-workspace/plasma in KDE trunk, it''s somewhat different than in past releases: http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/ We now have both Plasma Desktop and Plasma Netbook with at least Plasma Mobile and probably others coming in the future. We discussed this among the Kubuntu developers and have some consensus around a packaging approach for this, but want to coordinate this with Debian first and make sure both distros use a common approach. Also, slightly related, is the KDE rebranding effort: http://dot.kde.org/2009/11/24/repositioning-kde-brand This makes first class brands out of Plasma Desktop and Plasma Netbook. Our thought is to not split Plasma Desktop out into a separate binary, but leave it in kdebase-workspace as something that should always be installed (somewhat as a fallback) even if it''s not started by default on some devices. Then additional plasmas (Plasma Netbook for KDE SC 4.4) would be in separate binaries so they would only be installed on devices appropriate for the specialized plasma. The files built from: http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/ would all go in a plasma-netbook package built from the kdebase-workspace source. This approach seems reasonably scalable and future proof and also minimizes the amount of code installed on most systems. Comments? Scott K
Hello, On tre?iadienis 25 Lapkritis 2009 18:25:28 Scott Kitterman wrote:> Our thought is to not split Plasma Desktop out into a separate binary, but > leave it in kdebase-workspace as something that should always be installed > (somewhat as a fallback) even if it''s not started by default on some > devices.Why?> Then additional plasmas (Plasma Netbook for KDE SC 4.4) would be > in separate binaries so they would only be installed on devices > appropriate for the specialized plasma. The files built from: > > http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/ > > would all go in a plasma-netbook package built from the kdebase-workspace > source.plasma-netbook package makes sense.> > This approach seems reasonably scalable and future proof and also minimizes > the amount of code installed on most systems.It might be scalable, but it does not minimize amount of code installed. plasma-desktop is still uselessly installed where otherwise it is not needed. Anyway, more justification on technical grounds please. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20091125/251bf248/attachment.pgp>
> Hello, > > On tre?iadienis 25 Lapkritis 2009 18:25:28 Scott Kitterman wrote: > > Our thought is to not split Plasma Desktop out into a separate binary, > > but leave it in kdebase-workspace as something that should always be > > installed (somewhat as a fallback) even if it''s not started by default on > > some devices. > > Why? > > > Then additional plasmas (Plasma Netbook for KDE SC 4.4) would be > > in separate binaries so they would only be installed on devices > > appropriate for the specialized plasma. The files built from: > > > > http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/ > > > > would all go in a plasma-netbook package built from the kdebase-workspace > > source. > > plasma-netbook package makes sense. > > > This approach seems reasonably scalable and future proof and also > > minimizes the amount of code installed on most systems. > > It might be scalable, but it does not minimize amount of code installed. > plasma-desktop is still uselessly installed where otherwise it is not > needed. Anyway, more justification on technical grounds please. >I believe having plasma-desktop as a fallback is a perfectly reasonable ground. In addition, it would allow for the case of switching easily between desktop and netbook/mobile/etc profile, which may make sense (at least for netbook it does). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20091125/4f41e225/attachment.pgp>
> Hello, > > On tre??iadienis 25 Lapkritis 2009 18:25:28 Scott Kitterman wrote: >> Our thought is to not split Plasma Desktop out into a separate binary, >> but >> leave it in kdebase-workspace as something that should always be >> installed >> (somewhat as a fallback) even if it''s not started by default on some >> devices. > > Why?When we were discussing it, it felt safer. Considering it further, my opinion has evolved. Particularly given the rebranding move by KDE so that "Plasma Desktop" is a clearly separate entity that users might want to install and your point below about not entirely reducing code installed, I think it should be a separate binary. More beloew.>> Then additional plasmas (Plasma Netbook for KDE SC 4.4) would be >> in separate binaries so they would only be installed on devices >> appropriate for the specialized plasma. The files built from: >> >> http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/ >> >> would all go in a plasma-netbook package built from the >> kdebase-workspace >> source. > > plasma-netbook package makes sense. > >> >> This approach seems reasonably scalable and future proof and also >> minimizes >> the amount of code installed on most systems. > > It might be scalable, but it does not minimize amount of code installed. > plasma-desktop is still uselessly installed where otherwise it is not > needed.Agreed (see above). It''s less code than not breaking anything out (all plasmas installed in all systems), but it''s certainly not minimal.> Anyway, more justification on technical grounds please.In our KDE 4.3 release, we built an experimental plamsa-netbook package from playground with these contents: http://packages.ubuntu.com/karmic/i386/plasma-netbook/filelist Similarly, we''d build plamsa-netbook for KDE 4.4 with: http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/ I''m also suggesting a similar plasma-desktop package that would split out from kdebase-workspace-bin. Based on my short IRC conversation with pusling, I checked with upstream and there is a KCM that allows users to select which plasma to run if multiple plasmas are installed. It is not active if only one is installed. Here is the summary of what notmart had to say about it:> There is a kcontrol module that lets you chose the shells that starts. It > automatically gets disabled if either plasma-desktop or plasma-netbook > executables aren''t present. It uses KAutostart that basically puts > desktop files in ~/.config/autostart.> In the netbook version you could not install the desktop parts (they are > quite separated in the source dir so it should be easy to package them > separately). Then, in the netbook package, or better as a separate > package you can put an autostart desktop file that installs globally. If > the user then installs plasma-desktop and chooses it the autostart of > plasma-netbook gets disabled on a per-user basis. We are still wondering > how to avoid autostarting of both if the global autorun desktop file is > installed for plasma-netbook, perhaps installing it it could delete the > one of plasma-desktop and viceversa?It sounds to me like the upstream concept supports the idea of only installing one plasma and letting the user install an alternative one if they prefer (we have had requests for this with our Kubuntu Netbook tech preview). I was thinking that perhaps we could use the alternatives system to control which plasma is autostarted on first run, but I need to review policy on alternatives to know if it''s appropriate. Scott K