Merging Hawaii Login Manager with sddm

[Pier Luigi Fiorini]

Hi,

I'm the lead developer of the Hawaii desktop environment.

Here's some information about the project:

http://www.phoronix.com/scan.php?page=news_item&px=MTIxMzc

http://www.phoronix.com/scan.php?page=news_item&px=MTI4ODA

Basically Hawaii is a lightweight desktop environment based on Qt 5/QtQuick 2 and Wayland.

Main component is Green Island, the Wayland compositor and shell. If you are interested in this topic I would be glad if you consider joining the effort.

Here's some links if you are interested in discussing this on IRC and mailing lists http://www.maui-project.org/en/get-in-touch/

Hawaii is part of a bigger project Maui, which is a distro that relies on OSTree for atomic upgrades and rollbacks.

Hawaii has also a login manager and sddm recently made a theme based on our design. This led me to think about merging my login manager with sddm.

Hawaii Login Manager main differences compared to sddm are:

1. Uses systemd (it's not limited on providing a .service file, it uses logind DBus interface for seats and sessions)

2. Has initial Wayland system compositor integration that will be finished once someone will port the early Canonical work to Wayland 1.x

3. Uses QtQuick controls (formerly known as Qt Desktop Components)

#1 might be interesting for you, guess that you would like to make sddm work on non-systemd systems as well as on distros with full systemd support such as Arch Linux so we need to figure out how to do it.

#2 is another topic that might be interesting too but it's something I would like to introduce later.

#3 I have no problems using sddm's components until QtQuick controls are released (hopefully with Qt 5.1) and later we might want to consider using "standard" controls from Qt.

Both projects has basically the same goal, merging the two efforts shouldn't be a problem.

Contributing to sddm rather than developing Hawaii Login Manager will off load some work to you, my plan would be to send patches for #1 and #2 and close my github repo (https://github.com/hawaii-desktop/login-manager).

What do you think?

http://www.maui-project.org

http://wiki.maui-project.org

[Abdurrahman AVCI]

Hi Pier,

I agree with you on most parts, see inline notes please.

2 Mart 2013 Cumartesi 22:36:14 UTC tarihinde Pier Luigi Fiorini yazdı:

Hi,

I'm the lead developer of the Hawaii desktop environment.

Here's some information about the project:

http://www.phoronix.com/scan.php?page=news_item&px=MTIxMzc

http://www.phoronix.com/scan.php?page=news_item&px=MTI4ODA

Basically Hawaii is a lightweight desktop environment based on Qt 5/QtQuick 2 and Wayland.

Main component is Green Island, the Wayland compositor and shell. If you are interested in this topic I would be glad if you consider joining the effort.

Here's some links if you are interested in discussing this on IRC and mailing lists http://www.maui-project.org/en/get-in-touch/

Hawaii is part of a bigger project Maui, which is a distro that relies on OSTree for atomic upgrades and rollbacks.

Hawaii has also a login manager and sddm recently made a theme based on our design. This led me to think about merging my login manager with sddm.

I had the very same goal of creating a complete interface based on QtQuick2, and started SDDM as the first step. I discovered hawaii later and following development for a while already. Working together, can make realizing this goal easier.
 

Hawaii Login Manager main differences compared to sddm are:

1. Uses systemd (it's not limited on providing a .service file, it uses logind DBus interface for seats and sessions)

 

Providing multi-seat support is already on our roadmap (https://github.com/sddm/sddm/wiki/Roadmap). In fact I am currently refactoring SDDM code to be more multi-seat friendly. There were some issues I need to fix first, after that I will push code upstream. With these changes sddm would be pretty similar to hawaii login manager architecture-wise. For example, split daemon-greeter, socket based communication etc.

By the way, we already use systemd login manager interface, where available, for power management. If it is not available we fallback to upower. So it is not just installing a service file ;)
 

2. Has initial Wayland system compositor integration that will be finished once someone will port the early Canonical work to Wayland 1.x

My plan was to add wayland support after finishing X11 support. I guess we can work together in this part.
 

3. Uses QtQuick controls (formerly known as Qt Desktop Components)

#1 might be interesting for you, guess that you would like to make sddm work on non-systemd systems as well as on distros with full systemd support such as Arch Linux so we need to figure out how to do it.

#2 is another topic that might be interesting too but it's something I would like to introduce later.

#3 I have no problems using sddm's components until QtQuick controls are released (hopefully with Qt 5.1) and later we might want to consider using "standard" controls from Qt.

SDDM components have two versions 1.1 and 2.0 based on QtQuick1.1 and QtQuick2.0 respectively. I think we will have to support version 1.1 as long as we support Qt4. But we may consider implementing version 2.0 on top of QtQuick Controls when they are released. At the end, I think we need to provide some custom components to ease theme creation, like a face item, a clock etc.

 

Both projects has basically the same goal, merging the two efforts shouldn't be a problem.

Contributing to sddm rather than developing Hawaii Login Manager will off load some work to you, my plan would be to send patches for #1 and #2 and close my github repo (https://github.com/hawaii-desktop/login-manager).

What do you think?

I agree with you. We can start accepting patches after I finished my refactoring, probably in a few days. Are you OK, with that?
 

http://www.maui-project.org

http://wiki.maui-project.org

[Pier Luigi Fiorini]

Il giorno domenica 3 marzo 2013 15:39:38 UTC+1, Abdurrahman AVCI ha scritto:

Hi Pier,

I agree with you on most parts, see inline notes please.

2 Mart 2013 Cumartesi 22:36:14 UTC tarihinde Pier Luigi Fiorini yazdı:

Hi,

I'm the lead developer of the Hawaii desktop environment.

Here's some information about the project:

http://www.phoronix.com/scan.php?page=news_item&px=MTIxMzc

http://www.phoronix.com/scan.php?page=news_item&px=MTI4ODA

Basically Hawaii is a lightweight desktop environment based on Qt 5/QtQuick 2 and Wayland.

Main component is Green Island, the Wayland compositor and shell. If you are interested in this topic I would be glad if you consider joining the effort.

Here's some links if you are interested in discussing this on IRC and mailing lists http://www.maui-project.org/en/get-in-touch/

Hawaii is part of a bigger project Maui, which is a distro that relies on OSTree for atomic upgrades and rollbacks.

Hawaii has also a login manager and sddm recently made a theme based on our design. This led me to think about merging my login manager with sddm.

I had the very same goal of creating a complete interface based on QtQuick2, and started SDDM as the first step. I discovered hawaii later and following development for a while already. Working together, can make realizing this goal easier.

Yeah! :)

 

 

Hawaii Login Manager main differences compared to sddm are:

1. Uses systemd (it's not limited on providing a .service file, it uses logind DBus interface for seats and sessions)

 

Providing multi-seat support is already on our roadmap (https://github.com/sddm/sddm/wiki/Roadmap). In fact I am currently refactoring SDDM code to be more multi-seat friendly. There were some issues I need to fix first, after that I will push code upstream. With these changes sddm would be pretty similar to hawaii login manager architecture-wise. For example, split daemon-greeter, socket based communication etc.

By the way, we already use systemd login manager interface, where available, for power management. If it is not available we fallback to upower. So it is not just installing a service file ;)

Nice, didn't see it last time I checked.

 

 

2. Has initial Wayland system compositor integration that will be finished once someone will port the early Canonical work to Wayland 1.x

My plan was to add wayland support after finishing X11 support. I guess we can work together in this part.

Yep. I'm asking on the Wayland IRC channel if someone is working on the system compositor.

With system compositor ported to Wayland 1.x and a working XWayland we can run greeter as a X11 application and start X sessions pretty easily.

IMHO This is the first step to get it working and offers compatibility to existing world.

 

 

3. Uses QtQuick controls (formerly known as Qt Desktop Components)

#1 might be interesting for you, guess that you would like to make sddm work on non-systemd systems as well as on distros with full systemd support such as Arch Linux so we need to figure out how to do it.

#2 is another topic that might be interesting too but it's something I would like to introduce later.

#3 I have no problems using sddm's components until QtQuick controls are released (hopefully with Qt 5.1) and later we might want to consider using "standard" controls from Qt.

SDDM components have two versions 1.1 and 2.0 based on QtQuick1.1 and QtQuick2.0 respectively. I think we will have to support version 1.1 as long as we support Qt4. But we may consider implementing version 2.0 on top of QtQuick Controls when they are released. At the end, I think we need to provide some custom components to ease theme creation, like a face item, a clock etc.

Face items and clocks have to be implemented as custom controls of course.

BTW QtQuick controls offer nice theming capabilities using QML code (without a theme they use standard QtWidgets themes).

 

 

Both projects has basically the same goal, merging the two efforts shouldn't be a problem.

Contributing to sddm rather than developing Hawaii Login Manager will off load some work to you, my plan would be to send patches for #1 and #2 and close my github repo (https://github.com/hawaii-desktop/login-manager).

What do you think?

I agree with you. We can start accepting patches after I finished my refactoring, probably in a few days. Are you OK, with that?

Yes I'm OK. Going to post the agreement on G+ :)