KDE Platform Profiles

[Kevin Ottens]

On Monday 12 April 2010 14:46:47 Thiago Macieira wrote:
> Em Segunda-feira 12 Abril 2010, às 13:15:08, Kevin Ottens escreveu:
> >  - Desktop: Extensive and power user usage as we know it today (the full
> > 
> > game:  multimedia, any content reading, complex content editing);
> > 
> >  - Tablet: Mostly Internet connected devices for multimedia usage,
> >  reading
> > 
> > content, some content editing;
> > 
> >  - Mobile: Very constrained devices, multimedia usage, content reading,
> > 
> > very  light content editing.
> 
> I think you're missing a Netbook/Laptop profile in-between Desktop and
> Tablet. Maybe even the two split up.

I disagree with that, details below...
 
> When I'm at home, I use my laptop as a desktop. Power is of no concern, and
> I even build code on it.

... actually if you're thinking about "green IT", it *is* a concern even on 
desktop.

> But when I'm travelling, I notice that the KDE environment sucks at power
> consumption. I would even go as far as to say that power consumption is an
> issue in any segment and applications shouldn't wake up unnecessarily, nor
> send broadcasts on D-Bus unnecessarily.

Agreed. Hence why I think there's no need for a laptop profile (especially if 
you add "green IT" to the mix that I cited above).

> Of import is the Netbook form factor: it's like the desktop, but on a
> smaller screen. So maybe it won't affect kdelibs, but the apps themselves
> that want to address this segment.

Exactly, platform wise it's not a big difference. The thing is more that 
nowadays netbooks are more for light editing and media consumption, which fits 
our current "Tablet" profile.

As I said the "Tablet" name is not ideal, but the best one we could come up 
with so far. But really from the *platform* pov Tablet==Netbook. From *plasma* 
pov though, you might want two different shells.

An ODM could ship:
 - on a netbook, the platform in a tablet profile, and plasma-netbook;
 - on a tablet, the platform in a tablet profile, and (an hypothetical) 
plasma-tablet or (the upcoming) plasma-mobile.

The way I really see it:
 - Main usage and horsepower affects the platform profile
 - Form factor and input method affects the shipped plasma workspace

> > Some dependencies can be cut by moving symbols within kdelibs further
> > down in the dependency chain. This type of change is hardly
> > "#ifdef'able" so it would affect also the Desktop profile. This is
> > binary compatible on Linux and Windows but unfortunately not BC on Mac.
> 
> Please read src/corelib/xml/qxmlstream.h:
> // These platforms do not support symbol moving but allow it to be
> duplicated: //   Microsoft Windows (COFF PE executable format)
> //      special case: Windows CE wasn't supported before 4.4.0
> 
> You can't move the symbols further down the dependency chain on Windows.
> You have to copy them.

Hm, ok in such a case we'll have to treat KDE/Windows like KDE/Mac. That is 
either they both agree in an exceptional BIC change for them as both ports are 
rather young and not tagger stable (AFAIK) or it's not going to happen. I'll 
let the decision to their hands (contacting them is on my todo list once I 
start proceeding with the plan resulting from discussions here).

> > To summarize, here are the different profiles, and the type of actions
> > they
> 
> > would imply:
> [snip]
> 
> Please address too the kded dependency issue along with the "klauncher-less
> KDE" mode.

This one we've no data for yet (much more difficult to track with all the 
modules we have), hence why it's not in this plan yet. Likely to be in a next 
phase once we got this first batch of changes in. But yeah, definitely a 
"later" thing, I want us to go iteratively on this one as far as possible.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100412/5b48fce1/attachment.sig>