[opensuse-artwork] The ugliness of KDM (and how to solve it)
Hi all. Some of you might have followed the problem we had with KDM and domain logons. This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there. I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines. After that I had to join a machine to that newly created domain to see how the theme behaves. I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno. From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past. I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view. This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest). If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact. Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
On Tuesday 12 of February 2013 22:21:03 Marcus Moeller wrote:
Hi all.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest). Lightdm *cannot* be default for 12.3 for sure. Not just cause of the issues already mentioned, but also the KDE greeter is not in the distribution, but only in KDF and home repos. If the systemd situation resolves, we can certainly consider it for 13.1. (and nothing stops anyone to use it now already, but just not as default). It is also way too late, even without those obstacles. (if you hinted this for 12.3)
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact. I agree on this part, especially considering theme "has" to change on every release, so making a pretty, and featurfull DM theme is not easy, nor will please everyone, both aestathically and functionally.
Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Dear šumski.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest). Lightdm *cannot* be default for 12.3 for sure. Not just cause of the issues already mentioned, but also the KDE greeter is not in the distribution, but only in KDF and home repos. If the systemd situation resolves, we can certainly consider it for 13.1. (and nothing stops anyone to use it now already, but just not as default). It is also way too late, even without those obstacles. (if you hinted this for 12.3)
Yeah, that's clear ;) As mentioned I think I got it fixed for now. I was thinking about the upcoming release. Sorry for not stating it clearly.
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact. I agree on this part, especially considering theme "has" to change on every release, so making a pretty, and featurfull DM theme is not easy, nor will please everyone, both aestathically and functionally.
Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
On 12/02/13 22:35, šumski wrote:
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact. I agree on this part, especially considering theme "has" to change on every release, so making a pretty, and featurfull DM theme is not easy, nor will
On Tuesday 12 of February 2013 22:21:03 Marcus Moeller wrote: please everyone, both aestathically and functionally.
I'd like to call redoing the entire theme every release into question. We have a tight release cycle, yet rework major elements completely. Wouldn't it be a better use of resources to iteratively refine the theme during minor releases instead? It would also make new themes on major releases more interesting, rather than change for change's sake? Will -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Marcus Moeller - 22:21 12.02.13 wrote:
...
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
What about taking Brunos theme which has all the functionality and
letting only limited set of variable to be changed? We can make one
extra config file, which will be simple and contain only basic stuff
(colors, pictures, maybe few positions, ...) and in Makefile, we can
fill in some variable for the full theme. So designers will be able to
play as much as they want without breaking functionality.
Basically what I read is that there is too much freedom in design of KDM
and it is easy to break stuff you don't have. It should be possible to
limit that freedom so stuff will not get broken and designers will know
what they can change safely and what only if they are sure what are they
doing and that they are not breaking stuff...
--
Michal Hrusecky
Am 13.02.2013 09:05, schrieb Michal Hrusecky:
Marcus Moeller - 22:21 12.02.13 wrote:
...
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
What about taking Brunos theme which has all the functionality and letting only limited set of variable to be changed? We can make one extra config file, which will be simple and contain only basic stuff (colors, pictures, maybe few positions, ...) and in Makefile, we can fill in some variable for the full theme. So designers will be able to play as much as they want without breaking functionality.
The current theme now also support nearly all features. Maybe hiding of the userlist box could be added when 'Do not show userlist' option is set (patches welcome).
Basically what I read is that there is too much freedom in design of KDM and it is easy to break stuff you don't have. It should be possible to limit that freedom so stuff will not get broken and designers will know what they can change safely and what only if they are sure what are they doing and that they are not breaking stuff...
No, you are reading it wrong. The functionality should just not be driven by design, which means, every options should be available, no matter which theme is choosen. A design should NEVER be able to break functionality! This is a problem with KDM in general. Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Marcus Moeller - 9:53 13.02.13 wrote:
Am 13.02.2013 09:05, schrieb Michal Hrusecky:
Marcus Moeller - 22:21 12.02.13 wrote:
...
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
What about taking Brunos theme which has all the functionality and letting only limited set of variable to be changed? We can make one extra config file, which will be simple and contain only basic stuff (colors, pictures, maybe few positions, ...) and in Makefile, we can fill in some variable for the full theme. So designers will be able to play as much as they want without breaking functionality.
The current theme now also support nearly all features. Maybe hiding of the userlist box could be added when 'Do not show userlist' option is set (patches welcome).
Basically what I read is that there is too much freedom in design of KDM and it is easy to break stuff you don't have. It should be possible to limit that freedom so stuff will not get broken and designers will know what they can change safely and what only if they are sure what are they doing and that they are not breaking stuff...
No, you are reading it wrong. The functionality should just not be driven by design, which means, every options should be available, no matter which theme is choosen.
A design should NEVER be able to break functionality!
Still, solution is the same and easy - make few elements fixed part of
the theme and don't let designer touch them. Either you limit what you
can do with design or you can screw up functionality with theme -
imagine white text on white background, overlapping inputs, buttons
outside of the screen...
--
Michal Hrusecky
Am 13.02.2013 10:18, schrieb Michal Hrusecky:
Marcus Moeller - 9:53 13.02.13 wrote:
Am 13.02.2013 09:05, schrieb Michal Hrusecky:
Marcus Moeller - 22:21 12.02.13 wrote:
...
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
What about taking Brunos theme which has all the functionality and letting only limited set of variable to be changed? We can make one extra config file, which will be simple and contain only basic stuff (colors, pictures, maybe few positions, ...) and in Makefile, we can fill in some variable for the full theme. So designers will be able to play as much as they want without breaking functionality.
The current theme now also support nearly all features. Maybe hiding of the userlist box could be added when 'Do not show userlist' option is set (patches welcome).
Basically what I read is that there is too much freedom in design of KDM and it is easy to break stuff you don't have. It should be possible to limit that freedom so stuff will not get broken and designers will know what they can change safely and what only if they are sure what are they doing and that they are not breaking stuff...
No, you are reading it wrong. The functionality should just not be driven by design, which means, every options should be available, no matter which theme is choosen.
A design should NEVER be able to break functionality!
Still, solution is the same and easy - make few elements fixed part of the theme and don't let designer touch them. Either you limit what you can do with design or you can screw up functionality with theme - imagine white text on white background, overlapping inputs, buttons outside of the screen...
I have first tried to port the elements from the 12.2 theme 1:1 which does not work, so I had to add a few modifications. It's not that simple as you are discribing it. The only option I see, is to just replace the background and maybe the rectangle and leave everything else as is. Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Marcus Moeller - 13:00 13.02.13 wrote:
Am 13.02.2013 10:18, schrieb Michal Hrusecky:
Marcus Moeller - 9:53 13.02.13 wrote:
Am 13.02.2013 09:05, schrieb Michal Hrusecky:
Marcus Moeller - 22:21 12.02.13 wrote:
...
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed. This could be done by replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
What about taking Brunos theme which has all the functionality and letting only limited set of variable to be changed? We can make one extra config file, which will be simple and contain only basic stuff (colors, pictures, maybe few positions, ...) and in Makefile, we can fill in some variable for the full theme. So designers will be able to play as much as they want without breaking functionality.
The current theme now also support nearly all features. Maybe hiding of the userlist box could be added when 'Do not show userlist' option is set (patches welcome).
Basically what I read is that there is too much freedom in design of KDM and it is easy to break stuff you don't have. It should be possible to limit that freedom so stuff will not get broken and designers will know what they can change safely and what only if they are sure what are they doing and that they are not breaking stuff...
No, you are reading it wrong. The functionality should just not be driven by design, which means, every options should be available, no matter which theme is choosen.
A design should NEVER be able to break functionality!
Still, solution is the same and easy - make few elements fixed part of the theme and don't let designer touch them. Either you limit what you can do with design or you can screw up functionality with theme - imagine white text on white background, overlapping inputs, buttons outside of the screen...
I have first tried to port the elements from the 12.2 theme 1:1 which does not work, so I had to add a few modifications. It's not that simple as you are discribing it.
The only option I see, is to just replace the background and maybe the rectangle and leave everything else as is.
Basically yes, what am I proposing is that if it creates a lot of
trouble, reducing theming to changing colors and few fixed size images
for most of the time sounds like working solution/equivalent of
replacing it with something that doesn't let you break functionality.
--
Michal Hrusecky
On 12/02/13 22:21, Marcus Moeller wrote:
Hi all.
Some of you might have followed the problem we had with KDM and domain logons.
This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there.
I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines.
After that I had to join a machine to that newly created domain to see how the theme behaves.
I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno.
I'm glad that you were able to get it set up and provide all the features our users require.
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed.
I don't understand this part. Are you saying that it's possible to break KDM's functionality with the theming? How do other DMs separate these concerns so that even if the theming does not completely address all functions, they still work? This could be done by
replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
Perhaps adding a simulation mode in KDM so designers can test all aspects of a theme in a running system? Will -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Am 13.02.2013 10:47, schrieb Will Stephenson:
On 12/02/13 22:21, Marcus Moeller wrote:
Hi all.
Some of you might have followed the problem we had with KDM and domain logons.
This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there.
I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines.
After that I had to join a machine to that newly created domain to see how the theme behaves.
I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno.
I'm glad that you were able to get it set up and provide all the features our users require.
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed.
I don't understand this part. Are you saying that it's possible to break KDM's functionality with the theming? How do other DMs separate these concerns so that even if the theming does not completely address all functions, they still work?
Yes, it's possible to break the functionality with theming. Functions are added through elements in the theme. Take a look at the source and you will see. Most of the other DEs always offer all functions and don't let them be switched on/off within the theme. GDM e.g. is not really themable at all.
This could be done by
replacing it with LightDM (and don't argue with missing systemd patches. Afaik these are there, they are just not accepted upstream, which we could not expect as they are using upstart and ignore the rest).
If we want to stay with KDM, we should clearly define which functions must be supported. And again: don't expect that a designer will set up an Active Directory domain controller! If we want to support that, we need backed help from a technical contact.
Perhaps adding a simulation mode in KDM so designers can test all aspects of a theme in a running system?
Yes, that would be an option, too. But it would also add even more complexibility. With the current situation, even if we adopt most of the parts from a previous theme, changes must be tested. And setting up a test-scenario as it was necessary to fix the recent bug, is way to much to expect from us. Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Le 13/02/2013 13:04, Marcus Moeller a écrit :
With the current situation, even if we adopt most of the parts from a previous theme, changes must be tested. And setting up a test-scenario as it was necessary to fix the recent bug, is way to much to expect from us.
could this be automated? there is an automated test for factory that runs for every version jdd -- http://www.dodin.org http://jddtube.dodin.org/20120616-52-highway_v1115 -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
jdd - 13:07 13.02.13 wrote:
Le 13/02/2013 13:04, Marcus Moeller a écrit :
With the current situation, even if we adopt most of the parts from a previous theme, changes must be tested. And setting up a test-scenario as it was necessary to fix the recent bug, is way to much to expect from us.
could this be automated? there is an automated test for factory that runs for every version
Not really. Automated checks simulates some kind of input and produces
some output and compares reference output with actual one. Changing
theme is one of the things that brakes this stuff. At least that is what
I understood from openQA.
--
Michal Hrusecky
Le 13/02/2013 13:10, Michal Hrusecky a écrit :
jdd - 13:07 13.02.13 wrote:
could this be automated? there is an automated test for factory that runs for every version
Not really. Automated checks simulates some kind of input and produces some output and compares reference output with actual one. Changing theme is one of the things that brakes this stuff. At least that is what I understood from openQA.
sad :-( jdd -- http://www.dodin.org http://jddtube.dodin.org/20120616-52-highway_v1115 -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
On 2/13/13 1:04 PM, Marcus Moeller wrote:
Am 13.02.2013 10:47, schrieb Will Stephenson:
On 12/02/13 22:21, Marcus Moeller wrote:
Hi all.
Some of you might have followed the problem we had with KDM and domain logons.
This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there.
I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines.
After that I had to join a machine to that newly created domain to see how the theme behaves.
I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno.
I'm glad that you were able to get it set up and provide all the features our users require.
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed.
I don't understand this part. Are you saying that it's possible to break KDM's functionality with the theming? How do other DMs separate these concerns so that even if the theming does not completely address all functions, they still work?
Yes, it's possible to break the functionality with theming. Functions are added through elements in the theme. Take a look at the source and you will see.
Most of the other DEs always offer all functions and don't let them be switched on/off within the theme.
GDM e.g. is not really themable at all. As a person who has spent years writing GDM theme I disagree :-)
I do get your point and think that the first thing we need is to define who our target user is and what functionality they require. It would have prevented this situation to begin with and/or made it much easier to discuss when the problem arose. -- Ken -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Hi Kenneth,
Some of you might have followed the problem we had with KDM and domain logons.
This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there.
I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines.
After that I had to join a machine to that newly created domain to see how the theme behaves.
I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno.
I'm glad that you were able to get it set up and provide all the features our users require.
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed.
I don't understand this part. Are you saying that it's possible to break KDM's functionality with the theming? How do other DMs separate these concerns so that even if the theming does not completely address all functions, they still work?
Yes, it's possible to break the functionality with theming. Functions are added through elements in the theme. Take a look at the source and you will see.
Most of the other DEs always offer all functions and don't let them be switched on/off within the theme.
GDM e.g. is not really themable at all. As a person who has spent years writing GDM theme I disagree :-)
As a long term GNOME contributor, I disagree ;) Take a look at e.g. GDM 3.6.2. There is not much left to theme at all. I am not talking about obsolete GDM 2 stuff.
I do get your point and think that the first thing we need is to define who our target user is and what functionality they require. It would have prevented this situation to begin with and/or made it much easier to discuss when the problem arose.
As mentioned often now. This is only one aspect. We need test scenarios that don't require these amount of work and skills as it was for the domain logon fix. Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
On 2/13/13 2:25 PM, Marcus Moeller wrote:
Hi Kenneth,
Some of you might have followed the problem we had with KDM and domain logons.
This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there.
I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines.
After that I had to join a machine to that newly created domain to see how the theme behaves.
I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno.
I'm glad that you were able to get it set up and provide all the features our users require.
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed.
I don't understand this part. Are you saying that it's possible to break KDM's functionality with the theming? How do other DMs separate these concerns so that even if the theming does not completely address all functions, they still work?
Yes, it's possible to break the functionality with theming. Functions are added through elements in the theme. Take a look at the source and you will see.
Most of the other DEs always offer all functions and don't let them be switched on/off within the theme.
GDM e.g. is not really themable at all. As a person who has spent years writing GDM theme I disagree :-)
As a long term GNOME contributor, I disagree ;)
Take a look at e.g. GDM 3.6.2. There is not much left to theme at all. I am not talking about obsolete GDM 2 stuff. Right, with GDM you cannot break anything by removing functionality. It is themeable though (you can set a gtk theme, bg, icons, etc.). I do get your point and admit that the same problems cannot occur as with KDM.
I do get your point and think that the first thing we need is to define who our target user is and what functionality they require. It would have prevented this situation to begin with and/or made it much easier to discuss when the problem arose.
As mentioned often now. This is only one aspect. We need test scenarios that don't require these amount of work and skills as it was for the domain logon fix.
I would argue that knowing who our users are and what they need is how we define the test scenarios. -- Ken -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
Am 13.02.2013 15:02, schrieb Kenneth Wimer:
On 2/13/13 2:25 PM, Marcus Moeller wrote:
Hi Kenneth,
Some of you might have followed the problem we had with KDM and domain logons.
This issue should be fixed in my last commit to the related BZ, but it was a real long and ugly way to get there.
I (as a designer) had to set up an Active Directory domain controller. I had to borrow another machine as my personal box is a low power Atom which is not capable for holding Virtual Machines.
After that I had to join a machine to that newly created domain to see how the theme behaves.
I spent a few sleepless hours on that, and felt forced to do so by Kenneth and Bruno.
I'm glad that you were able to get it set up and provide all the features our users require.
From my perspective we had never defined which function-set must be supported by the theme and just remembered that ppl called for a userlist in 12.1 which I have added. Just to let you know, only a very few of KDM themes support functionalities like userlist or domain logon, even not the official ones from the KDE project. And we had all kind of themes in the past.
I have not followed the 12.2 KDM design which was driven by Bruno, but this seems to have these functions. Sadly it was not very well received from the design point of view.
This leads me to my final summary: Functionality should never be driven by design. All other Display Managers I know, split these aspects. This is why I think KDM is broken and should be fixed.
I don't understand this part. Are you saying that it's possible to break KDM's functionality with the theming? How do other DMs separate these concerns so that even if the theming does not completely address all functions, they still work?
Yes, it's possible to break the functionality with theming. Functions are added through elements in the theme. Take a look at the source and you will see.
Most of the other DEs always offer all functions and don't let them be switched on/off within the theme.
GDM e.g. is not really themable at all. As a person who has spent years writing GDM theme I disagree :-)
As a long term GNOME contributor, I disagree ;)
Take a look at e.g. GDM 3.6.2. There is not much left to theme at all. I am not talking about obsolete GDM 2 stuff. Right, with GDM you cannot break anything by removing functionality. It is themeable though (you can set a gtk theme, bg, icons, etc.). I do get your point and admit that the same problems cannot occur as with KDM.
I do get your point and think that the first thing we need is to define who our target user is and what functionality they require. It would have prevented this situation to begin with and/or made it much easier to discuss when the problem arose.
As mentioned often now. This is only one aspect. We need test scenarios that don't require these amount of work and skills as it was for the domain logon fix.
I would argue that knowing who our users are and what they need is how we define the test scenarios.
Definitely Greets Marcus -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org
participants (6)
-
jdd -
Kenneth Wimer -
Marcus Moeller -
Michal Hrusecky -
Will Stephenson -
šumski