QtDay and FOSDEM are over and I finally took some time to update the plans for the next Hawaii version.
First things first. Next Hawaii iteration will be the 0.3.0 release.
At first I thought to do minor improvements in a 0.2.1 version and release shortly after 0.2.0 but then I decided to do more work.
Most of the stuff is already implemented at this point, but it needs further improvements.
So what should you expect for Hawaii 0.3.0?
Weston 1.4 is here now so the plugin was ported to the new version, some code refactoring is needed though to make the code more manageable.
The plugin will also support drop-down windows and a whitelist for trusted clients that need to access some Wayland interfaces (a possible usage is a screenshot application).
Shell is going to be improved with better multiple screen management, multiple panels (you can have one panel for each edge), configuration directly accessible from the panel, elements in panels can be reordered.
There was also a major refactoring, components such as dialogs, popups and overlays were moved to a plugin that can be used by external QML applications.
This was necessary in order to separate the PolicyKit agent and notifications daemon from the shell.
Other desktops (I'm thinking about LXQt here) can use these components more easily now if they wish.
Both are not launched by the shell automatically and currently there's no switch to turn them on and off but there are units for the systemd user session so you can manage them from the command line or with a graphical frontend. I can't exclude a service manager integrated in Hawaii in the future but there are no plans yet.
Compositor and deamons now notify systemd upon startup and as I mentioned above there is support for systemd user session however I'm having some problems running weston.
Screensavers. Yes it's a bit anachronistic but some people might enjoy it.
It's disabled by default and currently there is no switch to turn it on and off, later a preferences applet will be available.
As I showed during FOSDEM, now Hawaii can switch between different layouts on the fly.
This is one of the main goals of this project and goes by the name of convergence these days.
I will talk more about it in another post but the idea is to have a dedicated user interface for different devices and even react to things like input devices or screen resolution changing.
This work also make it easier to implement animated wallpapers because the shell is now much modular and can load different components.
Currently the background is implemented by a QML component that according to the settings draws a picture, a solid color or a gradient.
Animated wallpapers are just loadable QML components that does nice stuff such as animations, react to mouse click and tap to change the background and so on.
At this point it becomes clear that Hawaii needs a generic way to deal with this things, hence the standard background is going to be split in a wallpaper plugin, a solid color plugin and a gradient plugin and will be no more different than animated wallpapers.
Here you can see the task list.
domenica 16 febbraio 2014
martedì 4 febbraio 2014
Hawaii responsive user interface
This was written after FOSDEM but never had the time to finish it and do the video so with too many months of delay I've got some time in my hands to post about the Hawaii desktop environment responsive user interface.
Hawaii is currently focused on desktops and laptops but it's always been a goal to get ready for other devices as well supporting screens with different DPIs.
Why bother, can't we just do the same user interface and let the controls scale according to DPIs and expand contents to fit the screen size? No, we can't because there are differences between devices.
Desktops and laptops have a keyboard and most of the time a mouse and to complicate things even further they can also have a touchpad, for example I own an Apple Magic Trackpad. Mobile devices, on the other hand, have touch input, no keyboard and higher DPIs.
The same user interface cannot be used for different devices, the user expects it to suit the device.
On a tablet the user expects to see an application at a time and use several gestures, there is also less screen space so you have to design interfaces with fewer things on screen.
The opposite is true on desktop where you can show multiple windows and some tiling feature is more than welcome and since the mouse is more precise you can put more controls on the screen.
Today there are some devices like the Yoga that can alternatively be turned into either a tablet or a laptop. The only problem is that it's not cheap, I will have to save money before buying one :)
That's why I prefer calling this responsive user interface rather than convergence.
Hawaii should react on events such as screen resolution change, mouse plugged in or touch input device plugged in and load the user interface that is willing to step in and show a user interface for the current setup.
To make development easier the switch happens reading settings with the QtConfiguration library that supports changes notifications. That's enough to simulate an event. In the future I plan to use Solid to determine what's the current setup like, but maybe QScreen and QTouchDevice will be sufficient.
Most things that a desktop environment need can be shared between shells, for example lock screen management, idle state management, notifications, power management and sounds are all features that need to be done once.
With Green Island, the QML compositor, one can also plug in different ways to manage windows and panels all with their Wayland protocol interface.
This is not all. Applications need to switch the user interface too, so I've been experimenting with QFileSelector and QQmlUrlInterceptor.
In the application demo I have used QQmlUrlInterceptor.
The application has a content directory with the QML code for the desktop with the following subdirectories that override files for specific profiles: +phone, +tablet, +touch
The +touch subdirectory contains code for all touch user interface, one example is the list view delegate, +phone and +tablet override the main view (the tablet version has a menu that can be pulled from the left with a gesture while the phone version has it always visible).
For demo purpose, the user has to pass all the relevant profiles to the application so for example if I want the tablet version both touch and tablet are passed as arguments.
Here's a little video showing the switch from a tablet UI to a desktop UI and different layouts for the same application.
As you can see the tablet user interface has two panels (launcher at the bottom edge and a smaller panel with indicators on top), it also have a desktop view with a search bar and application icons. Stacked below there's the background view. The desktop user interface is the classic Hawaii shell that has a bottom panel with more elements.
Hawaii is currently focused on desktops and laptops but it's always been a goal to get ready for other devices as well supporting screens with different DPIs.
Why bother, can't we just do the same user interface and let the controls scale according to DPIs and expand contents to fit the screen size? No, we can't because there are differences between devices.
Desktops and laptops have a keyboard and most of the time a mouse and to complicate things even further they can also have a touchpad, for example I own an Apple Magic Trackpad. Mobile devices, on the other hand, have touch input, no keyboard and higher DPIs.
The same user interface cannot be used for different devices, the user expects it to suit the device.
On a tablet the user expects to see an application at a time and use several gestures, there is also less screen space so you have to design interfaces with fewer things on screen.
The opposite is true on desktop where you can show multiple windows and some tiling feature is more than welcome and since the mouse is more precise you can put more controls on the screen.
Today there are some devices like the Yoga that can alternatively be turned into either a tablet or a laptop. The only problem is that it's not cheap, I will have to save money before buying one :)
That's why I prefer calling this responsive user interface rather than convergence.
Hawaii should react on events such as screen resolution change, mouse plugged in or touch input device plugged in and load the user interface that is willing to step in and show a user interface for the current setup.
To make development easier the switch happens reading settings with the QtConfiguration library that supports changes notifications. That's enough to simulate an event. In the future I plan to use Solid to determine what's the current setup like, but maybe QScreen and QTouchDevice will be sufficient.
Most things that a desktop environment need can be shared between shells, for example lock screen management, idle state management, notifications, power management and sounds are all features that need to be done once.
With Green Island, the QML compositor, one can also plug in different ways to manage windows and panels all with their Wayland protocol interface.
This is not all. Applications need to switch the user interface too, so I've been experimenting with QFileSelector and QQmlUrlInterceptor.
In the application demo I have used QQmlUrlInterceptor.
The application has a content directory with the QML code for the desktop with the following subdirectories that override files for specific profiles: +phone, +tablet, +touch
The +touch subdirectory contains code for all touch user interface, one example is the list view delegate, +phone and +tablet override the main view (the tablet version has a menu that can be pulled from the left with a gesture while the phone version has it always visible).
For demo purpose, the user has to pass all the relevant profiles to the application so for example if I want the tablet version both touch and tablet are passed as arguments.
Here's a little video showing the switch from a tablet UI to a desktop UI and different layouts for the same application.
As you can see the tablet user interface has two panels (launcher at the bottom edge and a smaller panel with indicators on top), it also have a desktop view with a search bar and application icons. Stacked below there's the background view. The desktop user interface is the classic Hawaii shell that has a bottom panel with more elements.
Iscriviti a:
Post (Atom)