Usability: WineCfg Part 1 -- Desktop Integration tab
Hi, Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list. I have attached a mockup of my ideas, which I have added to since my original mail. == APPEARANCE == NOTE: Ignore the groupbox being called "Theme", it should be "Appearance". 1. The "(No Theme)" text is replaced with "Wine Default". No theme does not make sense -- there is a theme, it is just the default one that Wine is using. 2. The "Install theme..." button is now "Load...". 3. There is a "Save..." button to save a users theme modifications. This makes it easier to create custom themes (especially colour-based themes). 4. There is a divider between the theme and appearance settings. This is to make it clearer that these are separate, but related. 5. The "Item" list field always has an item selected (currently does not select an item by default). This helps keyboard navigation. 6. The "Font" button has an elipsis at the end. This button brings up another dialog, so should have an elipsis. == FOLDERS == 1. The term "Shell folders" is replaced with "Folders". Using the word "shell" is too confusing for users, as they don't know what the shell is. 2. The "Map the Wine folders to the default locations" option allows the user to set all known folder types to be mapped to their Linux desktop equivalents. 3. The list has been replaced with a dropdown and restructured. This should provide a better user experience (no more link to) and accessability. 4. There is a "Reset to default" option that sets the current folder to its Linux desktop equivalent. 5. The "Browse" button now has an elipsis. This is because it launches a dialog. == OTHER == 1. We may want to provide a set of colour themes (e.g. Windows 95, Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a better experience for the user by default - i.e. not just have the "No Theme" option initially. 2. We may want to be able to load a theme using the command line. This would allow - for example - distributions to setup Wine with a theme that matches their desktop, providing a more integrated experience to the user. 3. We may want to have a "Use the system's appearance" checkbox to enable Gnome/KDE/other integration, so that the colours and/or appearance is picked up from (and updated with) the native Linux environment. This would go above the theme drop-down. Comments welcome. - Reece
Reece Dunn wrote:
Hi,
Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list.
1. We may want to provide a set of colour themes (e.g. Windows 95, Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a better experience for the user by default - i.e. not just have the "No Theme" option initially.
+1. You could even add the Apple 'metal' look to the theme list.
2. We may want to be able to load a theme using the command line. This would allow - for example - distributions to setup Wine with a theme that matches their desktop, providing a more integrated experience to the user.
+1.
3. We may want to have a "Use the system's appearance" checkbox to enable Gnome/KDE/other integration, so that the colours and/or appearance is picked up from (and updated with) the native Linux environment. This would go above the theme drop-down.
+1. Don't forget MacIntosh and other UNIX flavors as well. Wine is not just for Linux, you know. :) James McKenzie
2008/10/8 James McKenzie <jjmckenzie51(a)earthlink.net>:
Reece Dunn wrote:
Hi,
Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list.
1. We may want to provide a set of colour themes (e.g. Windows 95, Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a better experience for the user by default - i.e. not just have the "No Theme" option initially.
+1. You could even add the Apple 'metal' look to the theme list.
Sure. That was an example list.
3. We may want to have a "Use the system's appearance" checkbox to enable Gnome/KDE/other integration, so that the colours and/or appearance is picked up from (and updated with) the native Linux environment. This would go above the theme drop-down.
+1. Don't forget MacIntosh and other UNIX flavors as well. Wine is not just for Linux, you know. :)
You're right ^_^. We could even move the "Let the system manage the window frame" option(s) here as well, because that fits with desktop integration. Selecting the "Use the system's appearance" option would possibly also imply a managed frame. - Reece
On Tue, Oct 7, 2008 at 6:26 PM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
Hi,
Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list.
Woot.
Hi all,
Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list.
Ah, lovely. This is something I'm planning on doing some work on, once I get a bit more free time.
== APPEARANCE ==
I've currently got some code that splits the Appearance and Theme sections of Winecfg out into separate control panels. I've not yet submitted this code (I hope to do so relatively soon), but your suggestions can certainly be incorporated into them.
1. The "(No Theme)" text is replaced with "Wine Default". No theme does not make sense -- there is a theme, it is just the default one that Wine is using.
That makes sense.
2. The "Install theme..." button is now "Load...".
3. There is a "Save..." button to save a users theme modifications. This makes it easier to create custom themes (especially colour-based themes).
That's a good idea, indeed.
4. There is a divider between the theme and appearance settings. This is to make it clearer that these are separate, but related.
Currently, my control panel code has these split onto separate tabs. Perhaps some sort of text explaining the link between the two may be a good idea here.
5. The "Item" list field always has an item selected (currently does not select an item by default). This helps keyboard navigation.
6. The "Font" button has an elipsis at the end. This button brings up another dialog, so should have an elipsis.
Sensible suggestions indeed. It's little things like these that are important when designing a user interface, so thanks for picking those up. :-)
== FOLDERS ==
Just for information, my current plan is for this section to remain within winecfg. But your changes would certainly be good to implement, too.
1. We may want to provide a set of colour themes (e.g. Windows 95, Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a better experience for the user by default - i.e. not just have the "No Theme" option initially.
Well, the way Windows does it is to have themes, and colour schemes within those. For instance, the Windows Classic theme has all the old colour schemes that have been in Windows since Windows 3.x, whereas the Windows XP theme has the different variations of "blue", "silver", etc. The desk.cpl/winecfg code supports themes to a certain degree, but I don't think it has support for the colour schemes (from memory). This is something that I can work on once I get my basic code finished.
2. We may want to be able to load a theme using the command line. This would allow - for example - distributions to setup Wine with a theme that matches their desktop, providing a more integrated experience to the user.
There are various configuration-based things that we want to be able to control by command line (appearance, uninstallers, etc) - this was brought up at WineConf in the desktop integration talk. It would probably be best to try to unify such things as much as possible - a command-line based extension to winecfg may be most sensible. This will require a bit more thinking, based on what sort of things we are going to want to configure.
3. We may want to have a "Use the system's appearance" checkbox to enable Gnome/KDE/other integration, so that the colours and/or appearance is picked up from (and updated with) the native Linux environment. This would go above the theme drop-down.
Something like that may be sensible, or alternatively, have a "(No theme, use system appearance)" item in the theme drop-down (which would then disable the appearance tab, or replace it with a "to modify appearance, please use your window manager's configuration panel" message). Cheers, -- Owen Rudge http://www.owenrudge.net/
2008/10/8 Owen Rudge <owen(a)owenrudge.net>:
Hi all,
Reading up on the wineconf WWN issue, I noticed that it mentions usability and winecfg. Therefore, I decided to dig up my RFC relating to some ideas I had about winecfg that I sent to the list.
Ah, lovely. This is something I'm planning on doing some work on, once I get a bit more free time.
Great.
== APPEARANCE ==
I've currently got some code that splits the Appearance and Theme sections of Winecfg out into separate control panels. I've not yet submitted this code (I hope to do so relatively soon), but your suggestions can certainly be incorporated into them.
I was thinking of creating a control panel applet that invokes winecfg to only display the appearance/theme tab. This is to allow the theme selection command-line to share the code with the displaying of the configuration UI. That would be harder to do using a control panel. That said, I am happy to go with your approach and move the logic into a separate control panel application with an appearance and a theme tab.
4. There is a divider between the theme and appearance settings. This is to make it clearer that these are separate, but related.
Currently, my control panel code has these split onto separate tabs. Perhaps some sort of text explaining the link between the two may be a good idea here.
Sounds good.
6. The "Font" button has an elipsis at the end. This button brings up another dialog, so should have an elipsis.
Sensible suggestions indeed. It's little things like these that are important when designing a user interface, so thanks for picking those up. :-)
^_^
== FOLDERS ==
Just for information, my current plan is for this section to remain within winecfg. But your changes would certainly be good to implement, too.
Sure. In that case, we could probably drop the "Folder" groupbox, rename the tab "Folders" and just have the content of what is currently within the Shell folders section here.
1. We may want to provide a set of colour themes (e.g. Windows 95, Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a better experience for the user by default - i.e. not just have the "No Theme" option initially.
Well, the way Windows does it is to have themes, and colour schemes within those. For instance, the Windows Classic theme has all the old colour schemes that have been in Windows since Windows 3.x, whereas the Windows XP theme has the different variations of "blue", "silver", etc. The desk.cpl/winecfg code supports themes to a certain degree, but I don't think it has support for the colour schemes (from memory). This is something that I can work on once I get my basic code finished.
The winecfg code supports colour schemes. I know because I added some fixes to support importing a Ubuntu Human colour scheme based theme file :). In my screenshot, I kind of munged the two together.
2. We may want to be able to load a theme using the command line. This would allow - for example - distributions to setup Wine with a theme that matches their desktop, providing a more integrated experience to the user.
There are various configuration-based things that we want to be able to control by command line (appearance, uninstallers, etc) - this was brought up at WineConf in the desktop integration talk. It would probably be best to try to unify such things as much as possible - a command-line based extension to winecfg may be most sensible. This will require a bit more thinking, based on what sort of things we are going to want to configure.
Sure. Also, if the code is being moved out into a control panel application, it makes it trickier. However, a cpl is essentially just a DLL with a specific export for displaying a control panel IIRC. Therefore, the desk.cpl DLL could have: LoadThemeFromFileW(LPCWSTR filename, THEMEDATA * theme); SaveThemeToFileW(LPCWSTR filename, const THEMEDATA * theme); where THEMEDATA is a data structure representing things like the element name, colour and size metric data from the theme and a HTHEME handle to the XP-style theme if one is present. That way, winecfg and desk.cpl can be kept in sync with each other, we can avoid copy/paste-style duplication and winecfg can be used to provide the command-line functionality. A similar thing could be done for install/uninstall/etc. when providing command-line access to that.
3. We may want to have a "Use the system's appearance" checkbox to enable Gnome/KDE/other integration, so that the colours and/or appearance is picked up from (and updated with) the native Linux environment. This would go above the theme drop-down.
Something like that may be sensible, or alternatively, have a "(No theme, use system appearance)" item in the theme drop-down (which would then disable the appearance tab, or replace it with a "to modify appearance, please use your window manager's configuration panel" message).
Or simply "Current system theme", since there is always a "theme", it may just be a colour scheme-based theme, but it is still a theme. So, coordinating this: I'm happy to hold of on doing major changes in this area until you land desk.cpl. Thanks, - Reece
I was thinking of creating a control panel applet that invokes winecfg to only display the appearance/theme tab. This is to allow the theme selection command-line to share the code with the displaying of the configuration UI. That would be harder to do using a control panel.
Well, this is actually what I originally implemented during the summer - I wrote some code in winecfg to allow certain applets to be invoked depending on which arguments were passed, and had a desk.cpl as just a wrapper. I was advised that it'd be better just to move the code into a separate cpl entirely though, so that's what I did. The theory is that the Desktop control panel could of course grow to feature other desktop-related settings, too.
Sure. In that case, we could probably drop the "Folder" groupbox, rename the tab "Folders" and just have the content of what is currently within the Shell folders section here.
Yep, that was pretty much my plan.
The winecfg code supports colour schemes. I know because I added some fixes to support importing a Ubuntu Human colour scheme based theme file :).
Ah, good. :-) Then in theory this should be quite straightforward.
That way, winecfg and desk.cpl can be kept in sync with each other, we can avoid copy/paste-style duplication and winecfg can be used to provide the command-line functionality.
Yes, this is something we were thinking about at WineConf - whether to have all the command-line features in one app (winecfg would seem sensible here), or whether to manipulate individual applets/programs (reg.exe, uninstaller.exe, etc) separately. My opinion is that it's probably best to keep them all in one app, and have that app import whatever logic is needed from individual applets, etc.
So, coordinating this: I'm happy to hold of on doing major changes in this area until you land desk.cpl.
I shall try to get this done over the next couple of weeks - I've not really had much time to think about wine recently due to a whole pile of academic work, but I'm hoping things might quieten down for at least a weekend so I can get some hacking done. :-) Cheers, -- Owen Rudge http://www.owenrudge.net/
participants (4)
-
James McKenzie -
Owen Rudge -
Reece Dunn -
Zachary Goldberg