minutes Monday Plasma hangout

[Aaron J. Seigo]

On Monday, November 4, 2013 15:21:27 Martin Klapetek wrote:
> On Mon, Nov 4, 2013 at 3:04 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Monday, November 4, 2013 13:19:37 Martin Klapetek wrote:
> > > On Mon, Nov 4, 2013 at 1:06 PM, Sebastian Kügler <sebas at kde.org> wrote:
> > and means more
> > maintenance for us.
> 
> How is that more maintenance for us if the code lives standalone (compared
> to being part of SDDM or whatever)? It would be moreless the same codebase,
> just in a different directory.

a) everything that isn’t dedicated to showing the splash. there is application 
bring up (did you know the 3 standard fd’s all must be closed when the splash 
screen shows, otherwise stardkde locks?), multi-screen support, theme 
location. the DM already has that. 

b) currently to test the log in process one needs to test the DM -> splash -> 
desktop process. this removes one of those variables

it’s not going to save us 1000s of man-hours, but reduced complexity is 
reduced complexity.

> > The worst case scenario is that users do not get a splash screen.
> 
> Which is actually "we're going to make the user experience worse".

Non-standard / non-supported configurations do not qualify. 

we’ve been through this already with things like “how much do we rely on 
having a compositor?” if you switch out kwin for another window manager, right 
now today you will have a worse experience and features will start to 
disappear from plasma-desktop.

Compiz supports a number of these features which helps if you choose compiz 
instead of kwin. 

the analogy to SDDM / other DMs should be evident.

> > This is
> > similar to a growing number of features which don’t work (at all or as
> > well)
> > without required system components.
> 
> I'm not aware of those...can you give some examples?

KAuthorized, Phonon, Networking plasmoid, autohide panel animations, window 
thumbnails, ... there’s quite a list

> > SDDM and LightDM, btw, use the same D-Bus interface, and that’s not an
> > accident, so if there is needed DBus communication I’m sure we can
> > continue
> > that trend.
> 
> Note that I don't have anything against putting it into DM, I'm just
> worried about putting it into *one* DM only as a custom extension.

this is not a good enough reason to make the splash screen its own process.

obviously we can’t go patching every DM out there, either. we’ll document what 
we do and hopefully other DMs (and perhaps desktop shells) will see the value 
in it and adopt it.

> Btw. is SDDM going to be a required thing for PW2?

no, but you may experience feature degradation without it. you might not. we 
just only guarantee the configuration we test with.

-- 
Aaron J. Seigo