Projects/Usability/Meetings/2009Feb21
The KDE Usability Project meeting took place on Feb 21 2009 at 20UTC and lasted for 1 hour 40 minutes. We discussed 5 agenda items which primarily had to do with HIG topics.
The following is a summary of meeting items discussed and their resolutions:
This discussion is about the current location of the toolbar visibility option, currently in Settings, and the proposal for moving that option to View. The discussion expanded to discuss the purpose of the View, Settings, and Window menus. Details of the discussion can be found in the meeting transcript.
Resolution
- Toolbar visibility will be moved to the View menu.
- The purpose of the Window menu was discussed and decided that it should be removed. Functionality should be split between the File and View menu, a la Dolphin
- It was also noted that some applications put statusbar, menubar, panel, etc. visiblity options in Window or Settings (e.g. Kopete). This is incorrect and all of these options should always reside in the View menu.
Actions
- seele will write a draft guideline proposal for moving the toolbar visibility option to View, and splitting the options in Window and removing Window. She will send it to the kde-core-devel and kde-usability mailing lists for comment before committing.
System Tray: Default action of service icons
There were some concerns about the behavior clicking on an application service icon in the systemtray. Applications are inconsistent, some will always bring the application to the foreground, others will toggle visibility in the taskbar regardless if it is in the foreground, background, or other desktop. Details of the discussion can be found in the meeting transcript.
Resolution
- Many of these problems should be resolved with the new system tray in 4.3
Actions
- Plasma team is working on system tray and will address the behavior issue
Proposed guideline: "most applications should have only one toolbar"
Some people had concerns about the number of individual toolbars in applications. We discussed the usability problems of toolbars and the proposal that applications should only have one toolbar that users can configure. Details of the discussion can be found in the meeting transcript.
Resolution
- It was agreed that some toolbars were in too many pieces which made it easy for users to accidentally create strange toolbar layouts
- Having a single toolbar would make it more difficult for users to customize their toolbars
- It made sense that some toolbars were probably in too small groping and so instead of a single toolbar, it might make more sense to have larger toolbar groupings
- Also, the toolbar configuration UI wasn't so great and could use improvement
- The suggestion of making sure toolbars are locked by default was also made
Actions
- agateau is to look at some applications he was concerned with and propose merging smaller toolbars together
- seele and agateau will look at the merges and create guidelines on how to create better toolbar groupings
- colomar and agateau will work on improving the toolbar configuration UI
Get hot new stuff: Should description text be wrapped?)
It was noted that the description in the GHNS UI is on a single line, and in order to read the entire description, you have to stretch the window. Details of the discussion can be found in the meeting transcript.
Resolutions
- Everyone agreed this is a valid issue and up to 3 wrapped lines would be an improvement
Actions
- seele to contact jwhiting about GHNS
KDE design patterns: Are they known/useful/being used?
Several design patterns were developed and proposed during the 2008 Season of Usability. The people who worked on the patterns wanted to see if they were useful for developers and if standardized classes could be created.
Actions
- colomar is working with agateau on the toolbar configuration UI and will use one of the patterns as a test, and see if they can develop a class for it.
Meeting Transcript
[20:03:39] <seele> ok, let's get this party started
[20:03:55] <seele> welcome to what i hope will become a productive and regular activity: kde usability project meetings
[20:04:11] <DreadKnight> :)
[20:04:34] <seele> my goal for these meetings are to work on specific design and usability problems
[20:04:50] <seele> and hopefully reach a conclusion or action item at the end
[20:04:59] <seele> there is a wiki page with some meeting ideas: http://techbase.kde.org/Projects/Usability/Meetings
[20:05:01] --> eean (n=ian@amarok/developer/eean) has joined #kde-usability
[20:05:04] <leinir> present
[20:05:19] -*- Nightrose will get something to eat and then join in
[20:05:24] <seele> there are several HIG-related issues, a few bugs, and then some larger design problems
[20:05:43] <seele> for this first meeting i want to talk about a few of those HIG problems and the bug issues and save the larger design problems
[20:05:58] <Peter007> erm...
[20:06:01] <seele> i think a few people couldnt make it for a saturday evening. next time we will do it in the middle of the week
[20:06:13] <seele> Peter007: question?
[20:06:16] <Peter007> yes
[20:06:28] <Peter007> could we begin with a outline of the irc itself
[20:06:37] <Peter007> the meeting format etc
[20:06:38] --> mpyne (n=kde-svn@kde/mpyne) has joined #kde-usability
[20:06:46] <DreadKnight> agree
[20:06:47] --> vandenoever ([email protected]) has joined #kde-usability
[20:06:48] <seele> right, getting to that
[20:07:05] <seele> so for this meeting, i'm going to act as moderator/meeting master to keep discussions on track.
[20:07:09] <DreadKnight> perhaps wait 5 more minutes? people usually are a bit late on stuff
[20:07:25] <seele> the meeting wont last longer than 2 hours, esepcially since it is late on the other side of the pond
[20:07:28] <eean> in the 5 minutes seele can get the meeting started :)
[20:07:37] <DreadKnight> ok
[20:07:47] <seele> for each of these issues, i will list the issue, and any pros/cons/other information necessary for discussion
[20:07:50] --> nixternal (n=nixterna@ubuntu/member/nixternal) has joined #kde-usability
[20:08:06] <nixternal> thanks aseigo for the heads up there :)
[20:08:13] <seele> also, if there is a particular developer who is concerned about the issue in particular, or had listed the meeting topic they will be able to contribute any missing information
[20:08:25] <DreadKnight> you miss all the good stuff if you don't follow me on twitter :P
[20:08:45] <seele> if it seems like there is not enough information to maintain a useful discussion, or the problem itself is too big to discuss on IRC, i will defer it
[20:09:00] <aseigo> nixternal: yay for identi.ca huh? ;)
[20:09:06] <nixternal> yup :)
[20:09:07] -*- lfranchi says thank you seele for your iron fist
[20:09:10] <aseigo> DreadKnight: boo hiss on twitter ;)
[20:09:19] <seele> lfranchi: lol
[20:09:24] <seele> it wont be that bad
[20:09:31] <seele> but having some rules will help make the meeting more productive
[20:09:35] <lfranchi> i wasn't kidding
[20:09:43] <lfranchi> seriously, thank you, it is needed in IRC meetings :P
[20:09:48] <seele> if it is obvious we arent going anywhere, it is better to move on to an easier problem so *something* gets done
[20:09:48] <eean> unrun irc meetings suck
[20:09:50] <DreadKnight> i use kdetwitter... since it's not trunk i don't have identi.ca support, aseigo; and choqok is useless with it as well
[20:09:56] <seele> lfranchi: thank me after.. who knows how this will go..
[20:10:29] <Peter007> will the meetings be logged?
[20:10:36] <seele> so.. anyone else missing? i know agateau and annma couldnt make it today and they had two issues
[20:10:40] <seele> Peter007: are you volunteering?
[20:10:45] <-- mpyne (n=kde-svn@kde/mpyne) has left #kde-usability
[20:10:55] <Peter007> heh, I can bearly type on irc
[20:10:56] <seele> to start, if someone could volunteer to log and post the meeting to the wikipage, that would be very helpful
[20:11:15] <seele> anyone? *crickets*
[20:11:18] <DreadKnight> seele: it will go just great :) i'm sure of it
[20:11:37] <lfranchi> seele: sure
[20:11:40] <lfranchi> quassel logs it anyway
[20:11:48] <seele> lfranchi: thanks for volunteering
[20:11:52] <lfranchi> np
[20:12:02] <seele> ok, let's get started
[20:12:03] <seele> http://techbase.kde.org/Projects/Usability/Meetings
[20:12:04] --> fredrikh (n=fredrik@kde/fredrik) has joined #kde-usability
[20:12:26] <seele> the first issue is a long running discussion on the kde-usability mailing list
[20:12:40] <seele> View vs Settings in the menubar, and what should go in them
[20:12:49] <seele> specifically, where does the toolbar toggle option go
[20:12:57] <seele> i've written up more information about this issue here: http://techbase.kde.org/Projects/Usability/HIG/Menu_Bar/View_Menu
[20:13:07] <seele> The option to toggle the visibility of toolbars is currently in the Settings menu. There have been several discussions over the years about whether toolbar visibility should be in Settings or View. One of the arguments is that the configuration option for configuring toolbars resides in the Settings and so the two related options should be together. However, there are several arguments for why toolbar visibility should be in View.
[20:13:22] <seele> Conceptually, toolbars are "window elements", the same as menubar, statusbar, and panels in a window. These other window elements currently reside in the View menu. This is important to note for two reasons. One, it establishes that View seems to be a logical place to put this type of configuration options. Two, since toolbars are conceptually similar to the mentioned window elements. Users will think of them as the same and use what they have learned with
[20:13:29] <seele> Also, non-KDE applications which are often coinstalled with KDE applications, such as Firefox and OpenOffice, place the toolbar visibility controls in the View menu. The argument is not that Firefox and OpenOffice do it the "right way", simply that an added benefit of changing KDE toolbar visibility to View would increase consistency with non-KDE applications, and improve the overall experience.
[20:13:39] <seele> [end]
[20:13:52] <seele> the proposal i would like to discuss is to move the toolbar toggle option to the view menu
[20:14:02] <seele> i will give everyone a few minutes to read the arguments
[20:14:11] <eean> (thinks toolbars shouldn't be toggable :P)
[20:14:18] <seele> feel free to speak up why or why not you think moving the option to view is a good idea
[20:14:27] <Nightrose> eean: yes they should!
[20:14:34] <seele> eean: removing the functionality is not up for discussion
[20:14:35] <Nightrose> i don't need a toolbar in quassel for example
[20:14:49] <Nightrose> and it wastes a lot of space on the eeepc
[20:14:55] <seele> where the functionality goes, View or Settings is what we are talking about
[20:14:56] <eean> quassel doesn't have one
[20:15:00] <Nightrose> it does
[20:15:19] <DreadKnight> i think the menu bar is overated and too 70's
[20:15:21] <Nightrose> seele: i vote for view but it is mostly a gut feeling
[20:15:28] <seele> eean: in 0.4.0 theyve added a toolbar. but let's stay on track
[20:15:44] <DreadKnight> i think the menu bars should be killed, just like in chrome web browser
[20:15:54] <seele> DreadKnight: that isn't up for discussion at the moment either
[20:15:57] <eean> whoa lol
[20:16:14] <eean> yes I agree View makes more sense, for all the reasons you outline there.
[20:16:23] <eean> I mean if you have a 'view' thats what its for
[20:16:26] <Chani> View makes sense to me...
[20:16:27] -*- lfranchi agrees with the View, seems to fit logically
[20:16:28] <leinir> i would vote View, however we then run into the problem that not all the KDE applications have View menus
[20:16:33] <seele> anyone else? in particular does anyone not agree with the proposal?
[20:16:43] -*- aseigo reads...
[20:16:44] <colomar> Just a thought: What if we put a visibility checkbox in the "Configure toolbars" dialog in addition to an item in the view menu?
[20:16:46] <leinir> Kopete and Konversation, for example, both lack that top level menu item
[20:16:50] <lfranchi> leinir: good point
[20:16:51] <Nightrose> leinir: do you know which one doesn't?
[20:16:51] <seele> leinir: can you find some examples and put them on the page?
[20:16:57] <Chani> when I started reading my first thought was 'view'... well, second. the first was 'what happene to right-clicking the toolbar itself?'
[20:17:10] <leinir> Nightrose: Those two in particular, i don't know of any others :)
[20:17:12] <Peter007> I'm not in favour, the toolbars don't change as often as views and whatever non-kde apps do, they shold to kde, not the other way
[20:17:16] <Nightrose> k
[20:17:17] <aseigo> konversation doesn't have a view menu (he says looking at the app he's in) (doesn't have a toolbar either..)
[20:17:18] <lfranchi> colomar: checkbox to enable a toggle in a menu?
[20:17:27] <lfranchi> colomar: that seems like option overkill imho :)
[20:17:36] <colomar> no
[20:17:37] <seele> lfranchi: i think he means putting the option in two places
[20:17:42] <colomar> yes
[20:17:43] <leinir> aseigo: by default, though it does have a toolbar (i use it :) )
[20:17:46] <lfranchi> oh sorry
[20:17:49] <colomar> np
[20:18:20] <seele> colomar: i think that could be confusing, users might wonder what the difference between the two options are
[20:18:30] <aseigo> so it would mean an extra menu entry in some apps just for toolbars
[20:18:50] <eean> seele: but another user might wonder why they can't hide the toolbar in "configure toolbar" dialog
[20:19:02] <colomar> If they're labeled the same and synchronize automatically they might get it
[20:19:20] -*- Chani likes having more than one way to do it
[20:19:25] <seele> how many of those applications also have visibility settings for the statusbar and menubar? i see kopete doesnt have a View menu, but a lot of options in the settings menu ought to be in a view menu
[20:19:34] <lfranchi> personally i don't like cluttering options
[20:19:41] <Chani> people dont get confused by options that are both on hte toolbar and in a menu
[20:19:53] -*- aseigo notes that there a lot of apps with both a window and a view menu..
[20:20:02] <eean> aseigo: :|
[20:20:03] <seele> so in addition to the toolbar option, there are several additional options which are not categorized consistently in the environment
[20:20:08] <Nightrose> seele: the problem with kopete is probably that they want to keep the number of menues small due to lack of horizontal space
[20:20:08] <Chani> kopete's got a scary amount of settings, iirc ;)
[20:20:29] <aseigo> Nightrose: yes
[20:20:32] -*- DreadKnight thinks kopete is the mosts ugly app from kde
[20:20:38] <DreadKnight> *
[20:20:43] -*- Nightrose loves kopete ;-)
[20:20:46] <seele> Nightrose: the first half of their settings menu has options which are normally in a view menu too :-/
[20:20:59] -*- aseigo frowns at DreadKnight wondering what the deal is there
[20:21:31] <seele> so there seems to be yet a larger issue here, inconsistency in element visibility options
[20:21:58] <seele> there are three things we can consider:
[20:22:09] <aseigo> Nightrose: i don't think a View menu would be a horizontal burden in kopete, looking at it now
[20:22:18] <seele> 1) dont do anything about it <-- not in favor of this because inconsistency makes me itch and it reduces discoverability and learnability
[20:22:34] <seele> 2) Force apps without a View menu to use a view menu and put the proper items in there
[20:22:44] <Nightrose> aseigo: mine is wide enough for adding a view as well - dunno
[20:22:49] <seele> 3) Come up with a different solution, such as moving visiblity of window elements to Settings instead
[20:23:24] <Chani> of the apps that don't have a view menu, how many don't have one because they're abusing Settings instead?
[20:23:26] <aseigo> seele: well, 3 would be difficult for apps like onqueror
[20:23:31] <seele> the View label is very strong, and so I still think it is a good place to put elements you can toggle the visibility for, but obviously we have to consider the apps which dont have a view menu
[20:23:36] <seele> aseigo: yes
[20:23:37] <DreadKnight> why do you guys want to hang on to a 70's crappy concept while you revolutionize the rest of the desktop? "all obey HIG"?
[20:23:41] <leinir> i would most likely be for a better designed Settings menu... Make all settings (visibility, feature toggles...) sit in a Settings menu, and all other menus are feature activation
[20:23:42] <aseigo> seele: everything in its view menu could be viewed as a setting, really
[20:23:47] <seele> DreadKnight: please stay on topic or get out
[20:24:20] <aseigo> seele: so i don't think #3 is an option, tbh
[20:24:47] <seele> aseigo: that's fine and i agree
[20:25:01] <aseigo> seele: #2 is plausible, just means some work to be done ... note that the default location of the toolbar settings is actually set in kdelibs
[20:25:13] <aseigo> so for most apps it should be a fairly simple matter really
[20:25:18] <aseigo> (changing it in one place)
[20:25:26] <aseigo> then it would down to hunting all the apps that put it there manually (if any)
[20:26:09] <aseigo> personally i'm torn between the View and Window menus we have as well. there needs to be clear definitions laid down for each of the three menus; View, Settings and Window
[20:26:28] -*- Chani never uses the Window menu and isn't really sure what it's for
[20:26:42] <eean> kubuntu gets rid of the window menu
[20:26:43] <aseigo> Chani: tabs and splitting windows
[20:26:44] <seele> aseigo: can you give me an example of a window app? i dont have one option and cant think of one
[20:26:53] <eean> konqueror
[20:27:04] <aseigo> eean: so where are the split window options?
[20:27:07] <Chani> hmm. some of that stuff is duplicated in File
[20:27:16] <aseigo> seele: konqueror, konversation
[20:27:22] <eean> aseigo: I guess they didn't have them
[20:27:27] <eean> (not sure what they're doing now)
[20:27:41] <seele> ah, yes.. the window layout and tabs do make sense in window..
[20:27:45] <eean> konqueror has *a lot* of menu items. but this is off topic :)
[20:27:49] <seele> aseigo: so that would mean dolphin would get a window menu?
[20:27:56] <aseigo> eean: which is sort of a problem, yes? ;)
[20:28:25] <seele> well, currently view holds some of these "window" options as well
[20:28:38] <seele> so if we define view we might have to define window too
[20:28:42] <colomar> But at least in Konversion those are not toggles (all but "Enable notifications, which I htink should go somewhere else anyway)
[20:28:57] <eean> konqueror has some crazy stuff in the 'view' menu, include 'reload'.
[20:28:59] <Peter007> Setttings are used to set app, which affects the features and functions (i.e. toolbars), while view affects the content (find, zoom)
[20:29:23] <seele> Peter007: statusbar, panels, and menubar visibility is in View
[20:29:25] <Chani> hmm. all dolphin's panels stuff (and in my mind panels and toolbars are nearly the same) is in View. along with the split-window action (but dolphin does have much simpler splitting)
[20:29:44] <seele> and i think toolbars are perceived as the same type of window element as those mentioned, so they need to stay together
[20:29:49] <Peter007> seele: maybe they shouldn't be either
[20:30:02] <Nightrose> (hmm my konqueror on kubuntu has a window menu)
[20:30:42] <Peter007> if we keep the view clean from non content elements, we can populate it with more content orientated ones
[20:30:57] <seele> Peter007: i dont think toggling the visibility of a windowing element is on the same level as actively configuring something
[20:31:27] <seele> also, i really think users go to view before they go to settings when they think to turning off window elements like that
[20:31:29] <eean> Nightrose: its probably just changed, I was remembering from kubuntu circa kde3
[20:31:38] <Nightrose> ah k
[20:31:48] <Peter007> seele: I'm thinking about the frequency of change, the settings is seldom changed, but views more often
[20:32:28] <seele> Peter007: i dont know if everyone makes that specific distinction between the two, and also, i'm not sure what your point is
[20:32:50] <-- aseigo (n=aseigo@kde/aseigo) has quit (Read error: 54 (Connection reset by peer))
[20:32:53] <seele> toggling the status bar or menu bar should be something you can do quickly, and probably do more often than configuring an application once the first time you use it
[20:33:06] --> Godot ([email protected]) has joined #kde-usability
[20:33:07] <Peter007> my point is the frequently used functions should be on view, the less on settings, users prefer view
[20:33:13] --> aseigo (n=aseigo@kde/aseigo) has joined #kde-usability
[20:33:29] <aseigo> gah
[20:33:35] <aseigo> what was the last thing the channel got from me?
[20:33:37] <colomar> Seems to me that Peter007 and seele actually share the same opinion, right?
[20:33:51] <seele> aseigo: 15:24 < aseigo> eean: which is sort of a problem, yes? ;)
[20:34:02] -*- aseigo sighs
[20:34:12] <seele> colomar: i think they happen to intersect but not for the same reasons :0
[20:34:16] <aseigo> seele: well ... i don't know. the "New Window", "New Tab" entries seem to be in both the File and the Window menus...
[20:34:22] <aseigo> (in other apps, that is)
[20:34:27] <aseigo> it's things like moving tabs around, splitting the window... meh
[20:34:30] <aseigo> in dolphin it treats splitting as part of the view
[20:34:36] <aseigo> and puts tabs with new window in File
[20:34:40] <aseigo> which also makes sense
[20:34:45] <aseigo> konqueror's Window menu could probably be split up and merged into File and View
[20:34:59] <aseigo> and konversation's Window menu could probably become View
[20:35:03] <seele> ok, so in that case we shouldnt use konqueror as a model to look in to
[20:35:08] <Peter007> hmm, usually the toolbars are setup once, but views more often, your point fast access is taken
[20:35:20] <seele> the way dolphin does it by splitting up the options is what we should use as example
[20:35:38] <seele> Peter007: i dont agree, especially with netbook users
[20:35:42] <eean> seele: its an example of why a HIG is needed :)
[20:35:53] <seele> they may toggle toolbars on and off in order to get an extra line or two of text
[20:36:03] <seele> but them might need the toolbars to work on something
[20:36:12] <aseigo> seele: probably; killing of the Window menu in the process of defining View properly would probably a good idea imho
[20:36:32] <seele> aseigo: noted. i'll use dolphin as the example for organizing the options in to File and View, yes?
[20:36:48] <Chani> cool.
[20:37:02] -*- seele makes a note
[20:37:04] <Chani> the ones that belong in file are already there anyways, just stop duplicating them :)
[20:37:15] <Peter007> seele: essentially that kind of toggling exposes another problem toolbars were not designed to solve
[20:37:39] <aseigo> seele: sounds good
[20:37:50] <Chani> hrm, n/m, only two are duplicatd
[20:38:20] <seele> Peter007: regardless, this issue has come up over the past few years because experienced users have failed to remember that toolbars are in Settings, not View and continually make mistakes
[20:38:37] -*- Chani nevr uses the menu options for tabs, there are easier ways, like keyboard shortcuts and buttons and doubleclicking and dragging
[20:38:47] <seele> this is because you have a very active label "View" and within it related options, that's probably why the error occurs
[20:39:27] <DreadKnight> i added a button for new tab in dolphin
[20:39:29] -*- Chani actually hardly ever uses menus at all. I used to hide all hte ones that would let me, buut that's too buggy in kde4 and my screen's not as cramped
[20:39:33] <seele> i'm not suggesting we change something for the sake of changing it, people are making mistakes. that is a very real reason to fix something
[20:39:39] <Peter007> hmm, I don't see that as a problem with the design, or HIG
[20:40:05] <Peter007> I see that as a lack of standardisation
[20:40:20] <seele> Peter007: i'm still not sure what you mean
[20:40:35] <seele> all kde apps have the toolbar visibility option in settings
[20:40:37] <Peter007> Some toolbars are in view, others who knows?
[20:40:41] <seele> no
[20:40:47] <seele> afaik there are no toolbar options in veiw
[20:40:50] <seele> however that brings up another point
[20:40:54] <Peter007> firefox
[20:41:02] <seele> firefox and openoffice, two very popular open source applications, put toolbars in view
[20:41:07] <seele> Peter007: yes, getting to that
[20:41:12] <Peter007> heh
[20:42:06] <seele> so following what they do just for the sake that it is firefox and openoffice is not what i suggest, nor do i think we should change the option just because we can't change the option in firefox and openoffie
[20:42:09] <aseigo> while i'm cool with that argument in this case, since it's not something that moves around much and makes sense for other reasons as well, following other app's guidelines isn't great
[20:42:22] <seele> yes i agree
[20:42:23] <aseigo> seele: :)
[20:42:39] <seele> that's why i didnt bring it up until now
[20:42:48] <seele> (although i think it is on the wiki page)
[20:42:50] -*- eean thinks following other apps makes a lot of sense when its somewhat arbitrary anyways
[20:43:03] <Peter007> I don't think the HIG can reach into other apps, so there will always be this kind of situation
[20:43:16] <seele> Peter007: i wasn't suggesting changing those apps, they have nothing to do with kde
[20:43:28] <seele> this is simply for kde
[20:43:50] <seele> regardless of what the option apps do, i still think it would be good to group all of the similar objects together and put them in the same place
[20:44:03] <Peter007> I understand, my point is, that where other apps change other things, exp users will again make mistakes
[20:44:03] <seele> and i think toolbars go with the menubar, statusbar, panels, etc.
[20:44:24] <seele> Peter007: relearning and cognitive dissonance are two different issues
[20:44:41] <seele> relearning is a small cost, having something in a place that doesnt make sense is a higher cost
[20:45:04] <seele> so this discussion is also dragining on
[20:45:07] <Peter007> Sorry, I am questioning the worth of HIG here, based on users exposure to other apps
[20:45:20] <seele> i want to wrap this up in 5 minutes, with or without a solution
[20:45:45] <seele> final comments: who does not think the toolbar visibility option should be moved in to the view menu and why
[20:46:39] <DreadKnight> i think it should be in view... because i go to there if i want to "VIEW" something or stop viewing it; it's going the same way of thinking like kickoff menu
[20:46:47] <seele> ok, so i will take it that either a) people don't care where the option goes or b) they would like it to be in view
[20:46:50] <Peter007> I think should stay, I haven't made the mistakes referred to
[20:47:06] <seele> hmm. next time 3 minutes fo silence instead of 2 :P
[20:47:24] -*- lfranchi votes View
[20:47:35] <seele> anyone else NOT comfortable with the proposed change (and why)
[20:47:40] <DreadKnight> "to view or not to view.... that is the question!"
[20:47:47] <eean> well we're not Quakers we don't have to be in complete agreement :)
[20:48:14] <seele> eean: sure, but it is still good ot know if someone has a good reason not to do something :)
[20:48:40] <seele> ok. Peter007 your opinion is noted, but i think the proposed change will be beneficial, although minor
[20:48:49] <Chani> ok. next item?
[20:48:54] <Peter007> ok
[20:49:01] <seele> i will write up a summary and send it to the kde-core-devel mailing list and followup with whoever needs to make the change
[20:49:17] <seele> Aurelian is not here so we will skip item 2
[20:49:26] <DreadKnight> "Most applications should have only one toolbar"
[20:49:30] <DreadKnight> argh
[20:49:32] -*- Peter007 sighs loudly and lights another ....
[20:49:44] <seele> Item 3: Default actions of service icons (application icons running in the system tray)
[20:50:19] -*- Peter007 coughs and turns red
[20:50:34] <seele> two issues here, we might want to discuss only one
[20:50:55] <seele> the first is what the default behavior should be for all service applications because currently it is not
[20:51:06] <Chani> hmm. the dreaded system tray.
[20:51:07] <seele> however, what i would like to talk about first (which is the second issue) is what happens when you click on the icon
[20:51:34] <seele> currently it acts as a toggle. if the application is in the foreground and you click on the icon, it disappears to the system tray
[20:51:45] <seele> if the application is in the background and you click on the icon, it disappears to the system tray
[20:51:58] <seele> if the application is in the system tray and you click on the icon, it appears in the foreground
[20:52:15] <seele> a problem with this behavior has presented with our new panels, they can hide
[20:52:34] <Nightrose> also it is inconsistent across apps
[20:52:36] <colomar> Hm since the tray is somewhat standardized by freedesktop.org, isn't that behavior standardized as well?
[20:52:38] <seele> and with the new ideas for the system tray, it is usually more available than the task bar
[20:52:42] <aseigo> colomar: no
[20:52:51] <Chani> seele: are you referring to the systray icons that act as a secondary taskbar for an app with a mainwindow (like kopete), or the systray apps that are their own apps (like rsibreak), or system service ones, or all of them, or what?
[20:52:57] <aseigo> colomar: the only thing standardized in the fd.o spec is how to get an entry into a tray
[20:52:59] <seele> the problem is when the panel is hidden and you dont know if the application is in the task bar or hidden in the systray
[20:53:06] <aseigo> colomar: it says exactly zero about interaction policy
[20:53:18] <aseigo> seele: why does that matter exactly?
[20:53:25] <seele> if you click on the systray icon, if the application is in the taskbar but not in focus, nothing happens visually (the application disappears to the systemtray)
[20:53:39] <Nightrose> seele: you also need to distinguish and think about what happens if you clock
[20:53:41] <Nightrose> *click
[20:53:50] <seele> aseigo: apparently a lot of people click on the systemtray icon twice because they forget/miss that the application is already open in the taskbar
[20:54:05] <seele> because they are hiding panels
[20:54:06] -*- Chani thinks that if you click hte systray icon when the app isn't visible, it should, ideally, become visible somehow.
[20:54:10] <Nightrose> if it were like in amarok it would always come to the foreground no matter if it is in the systray or taskbar
[20:54:19] <Chani> seele: or it's on another desktop?
[20:54:32] <colomar> aseigo: Oh :( Than maybe it should be since it might be confusing to have different icons from different desktop apps behave differently...
[20:54:35] <seele> Chani: that too, i didnt ask about if the problem was another desktop or not
[20:54:40] <faemir> Sorry, what is wrong with if it's in the background then clicking on it brings it to the foreground?
[20:54:44] <Nightrose> Chani: yes that is what amarok does and i think kopete or ktorrent
[20:54:44] <aseigo> seele: ah.. ok.. so this whole conversation needs to shift a little i think.
[20:54:54] <seele> aseigo: i may not have explained it well :)
[20:55:04] <Nightrose> faemir: not all apps do it
[20:55:06] <Nightrose> ;-)
[20:55:06] <seele> faemir: the problem is when it is in the background and you click the icon and it disappears to the system tray
[20:55:08] <aseigo> because it's not a problem that will be solved imho by sticking with the current system
[20:55:14] <seele> faemir: the intent was to bring the application in to focus
[20:55:35] <seele> faemir: so you have to click the icon twice in order to bring the application in to focus
[20:55:51] <aseigo> seele: hm. that's only true if the window is the currently active window, of course
[20:56:12] <aseigo> if it's not the active window or another desktop (same thing really) it makes the window the active window
[20:56:14] <eean> the way amarok does it makes sense to me. clicking on the icon only hides amarok when its the top window. Otherwise its brings amarok forward.
[20:56:26] <aseigo> eean: that's the standard functionality in kdelibs
[20:56:37] <Nightrose> aseigo: try amarok/ktorrent against kopete/skype
[20:56:40] <eean> well this makes sense. I guess I miss what the problem is?
[20:56:41] <Chani> oh, that's already standard?
[20:56:44] <seele> aseigo: for kopete it always brings it to the foreground. for kmail it toggles the taskbar
[20:56:53] <eean> oh I see
[20:57:02] <eean> well people should be like amarok/ktorrent :)
[20:57:07] <Chani> ok, so kmail is doing it wrong
[20:57:14] <leinir> The biggest problem i've run into with this is the icons for the elements in Kontact
[20:57:15] <DreadKnight> i really like how apple guys unified shortcuts with open applications and system tray....
[20:57:36] <DreadKnight> an easier to understand concept for the average people...
[20:57:39] <leinir> (in particular akregator and kmail)
[20:57:42] <seele> so this is more of a verification so something can get written down
[20:58:13] <seele> If you click on the systemtray icon, if an application is not in the foreground it should appear in the foreground, regardless if it is hidden, on another desktop, or in the background?
[20:58:20] <seele> does this make sense? are there any cases where it wouldnt?
[20:58:23] <eean> seele: yes
[20:58:28] <Peter007> If the window is focused it should hide, otherwise focus
[20:58:33] <Nightrose> makes sense to me
[20:58:40] <seele> this seems like the most favored behaviro, but there are some apps which do not do this so i would like to write it down
[20:58:47] --> kuadrosx ([email protected]) has joined #kde-usability
[20:58:50] <eean> good plan
[20:59:01] <aseigo> seele: ah, well, yes. that's due to whether the tray icon has an associated parent window or not
[20:59:06] <seele> Peter007: right, so the opposite would be if it is in focus, clicking on the icon will make it disappear to the system tray
[20:59:21] <leinir> Yes, something like "do not override the kdelibs policy on systray icon click"?
[20:59:30] <seele> aseigo: is that something that is fixable or is it a bigger problem?
[20:59:42] <aseigo> seele: and in turn, that's dictated by whether it's the sort of app that's a "service" and which you'd expect to show up whenever you ask for it (e.g. IM), or if it's an application that you really don't want relocating from one desktop to another (kmail)
[20:59:44] <Peter007> seele: ok, head is spinning, correct
[20:59:51] <aseigo> so there's the "bring it to me" scenario an the "take me to it" scenario
[21:00:05] <Chani> hmm.
[21:00:13] <seele> aseigo: ah, good case
[21:00:17] <aseigo> this stems, imho, from the problem that we put all such status icons in the system tray
[21:00:24] <aseigo> really, the "take me to it" icons belong in the taskbar
[21:01:00] <aseigo> if we bolted the system tray and task bar widgets together, we could sort of make that happen now, though it would still lead to false positives (kopete being a good example there)
[21:01:03] <Chani> ok, so when the systray icon is clicked, if the app is open elsewhere you should be taken to it. if the app isn't in hte taskbar at all...
[21:01:04] <Peter007> Actually, my problem is that I don't expect a focused systray item to hide when I click it, I expect it to close
[21:01:21] <aseigo> Peter007: close?
[21:01:28] <eean> o.O
[21:01:35] -*- Chani would be fine with the app reopening on whatever desktop it was last on, and me being taken there to see it
[21:01:38] <Peter007> The only place the window appears is on the systray
[21:01:50] -*- aseigo goes looking for the whiteboard photo of this from tokamak
[21:02:11] <eean> you can't focus systray items
[21:02:11] <aseigo> Chani: even for, say, kmix? :)
[21:02:15] <seele> Peter007: disappear to systray might be what you are thinking of as "close" minimize to the taskbar is what most applications do
[21:02:17] <Peter007> erm, the only icon control is on the systray
[21:02:30] <Chani> aseigo: oh... kmix counts as a window?
[21:02:51] <Peter007> seele: yes, you can minimise, but that isn't a good idea - to me anyway
[21:02:53] <Chani> aseigo: when I click the kmix icon and the little volume slider pops up, I don't think of that as an application...
[21:03:19] <DreadKnight> aseigo: false positives in what way?
[21:03:35] <Peter007> somehow systray items are distinct beasts to normal windows
[21:03:38] <aseigo> DreadKnight: how would it differentiate between kopete and kmail?
[21:03:54] <DreadKnight> aseigo: ever usen mac os?
[21:03:58] <DreadKnight> used*
[21:04:00] <Peter007> They seem always active and therefore no need to minimise
[21:04:06] <aseigo> DreadKnight: yes. why?
[21:04:34] <seele> Peter007: macos has an "always on" policy. applications are never closed or open, they jsut are
[21:05:14] <seele> that is a great idea, but doesnt make sense for the current environment -- yet
[21:05:19] <DreadKnight> aseigo: we can have the icons actually differentiate; running apps for example have a dot or something under them compared to the ones that are not running; we could have a green dot for running ones and a red one for things like kopete like for when receiving a msg.. or just have the icon change like it does now or have it bounce
[21:05:22] <seele> it makes sense when applications can start in a second or two
[21:05:33] <Peter007> to me the systray runs servers, or similar, while taskbar are transitory windows
[21:05:52] <DreadKnight> seele: how come they are never closed? they have a mark in the dock :P
[21:05:53] <seele> but when an app takes longer than a few seconds to load, then the cost of closing is too high, and users begin thinking of resources
[21:06:12] <seele> DreadKnight: if an application is not running, clicking on the application will start it
[21:06:22] <seele> DreadKnight: if an application is running, it will bring you to the open window
[21:06:35] <DreadKnight> seele: yes, it's like a shortcut like a mentioned a while ago
[21:06:52] <DreadKnight> like the silly ubuntu's configuration leaves a lot of room on the top panel for shortcuts
[21:06:59] <Chani> there are also some apps that lose state when you close them. less and less, thankfully
[21:07:10] <DreadKnight> some people don't even make use of that space; makes sense with things like gnome-do etc
[21:07:41] <Chani> so.... where were we going with this?
[21:07:51] <aseigo> hm.. ok, so i can't find the photo atm, but here's a mostly-complete round up:
[21:07:52] <seele> DreadKnight: what is your point? i think moving to an "always on" concept like macosx is beyond the scope of this meeting
[21:07:53] <aseigo> http://techbase.kde.org/Projects/Plasma/NewSystemTray
[21:07:59] <DreadKnight> i say brinde the stuff into a single panel;
[21:08:05] <DreadKnight> bridge* argh
[21:08:07] <aseigo> DreadKnight: that's a completely different issue
[21:08:11] <seele> DreadKnight: and intersting idea, but i dont think here and now is appropriate
[21:08:18] <aseigo> not even related in the least
[21:08:35] <DreadKnight> it's related to the system tray :P
[21:08:46] <aseigo> no, it's not
[21:08:48] <DreadKnight> it's taking one step back and seeing the whole picture
[21:08:53] --> yaroslav__ ([email protected]) has joined #kde-usability
[21:08:58] <Nightrose> seele: let's go on?
[21:09:00] <DreadKnight> :)
[21:09:02] <Peter007> DreadKnight: you want to remove the systray completely?
[21:09:04] <seele> to refocus, we are discussing the behavior of clicking on an icon which happens to be in the systemtray
[21:09:10] <aseigo> you're talking about active launcher icons, or taskbar as launcher, which is not at all related to the tray
[21:09:10] <seele> Nightrose: yest
[21:09:12] <DreadKnight> Peter007: yes
[21:09:18] <aseigo> so: http://techbase.kde.org/Projects/Plasma/NewSystemTray
[21:09:26] <leinir> DreadKnight: It is doing what seele mentioned earlier as "delaying the larger design issues" :)
[21:09:31] <leinir> So, not for tonight :)
[21:09:43] <aseigo> with the new system we're implemnting for 4.3, the idea is to have 4 categories of icons
[21:09:52] <aseigo> Indicators of application status
[21:09:54] <aseigo> Communications
[21:09:55] <aseigo> System services
[21:09:57] <aseigo> Hardware
[21:10:08] <aseigo> app status indicator will move into the taskbar and be associated with their entries there
[21:10:22] <Nightrose> like?
[21:10:28] <DreadKnight> cool
[21:10:30] <aseigo> communication (IM, e.g.) will stay in the tray for now, but hopefully will move into a communications specific area
[21:10:44] <-- yaroslav_ ([email protected]) has quit (Read error: 104 (Connection reset by peer))
[21:10:44] --> yaroslav ([email protected]) has joined #kde-usability
[21:11:07] --> agateau ([email protected]) has joined #kde-usability
[21:11:12] <seele> aseigo: ok, so should we punt this issue then? it seems like youre on your way to fixing it in 4.3
[21:11:14] <DreadKnight> i like the areas idea, just hit my mind we could have the panel with just icons, roughly the same size, so only the areas will distinguish them
[21:11:23] <agateau> hello
[21:11:31] -*- Chani forgets what makes communication apps different from other app status icons.
[21:11:34] <agateau> i am very late for the meeting
[21:11:36] <Chani> but anyways...
[21:11:37] <agateau> is it over ?
[21:11:39] <seele> agateau: hi! we can talk about your issue next if you like
[21:11:44] <seele> agateau: no, probably for another hour ;)
[21:11:46] <aseigo> system services will remain in the tray
[21:11:52] <DreadKnight> gimmie project did this stuff for gnome; some even proposed having it default in ubuntu
[21:11:53] <aseigo> hardware items should be replaced by plasmoids
[21:11:55] <aseigo> that's sort of the idea
[21:11:57] <agateau> seele: great
[21:12:19] <Chani> ok, so what was agateau's item?
[21:12:26] <seele> Chani: one moment
[21:12:30] <Nightrose> aseigo: can you give an exapmle for app status indicator?
[21:12:47] <seele> aseigo: so i can write a note that plasma team is working on it, however you decide to implement and set the behavior?
[21:12:50] <agateau> Chani: i would like to propose this guideline "most applications should have only one toolbar"
[21:13:13] <-- yaroslav__ ([email protected]) has quit (Read error: 104 (Connection reset by peer))
[21:13:14] <aseigo> Nightrose: kmail
[21:13:20] <Nightrose> ah ok
[21:13:24] <agateau> i wanted to prepare some shots to show guilty (imho) apps, but I was too busy today
[21:13:27] <agateau> :/
[21:13:34] <Chani> oh
[21:13:41] <Nightrose> agateau: parley iirc
[21:13:51] <eean> agateau: I don't see how that would work with amarok at all
[21:13:53] <Chani> what I like aabout multiple toolbars is that it's easy to turn things on & off
[21:13:56] <aseigo> seele: i think we can come back to this once the new system is in place yes
[21:14:04] <Chani> eg. the bookmarks toolbar in konq
[21:14:08] <seele> agateau: do you want describe what you think is the issue with multiple toolbars and why you think one toolbar is better
[21:14:11] <seele> aseigo: ok
[21:14:14] <aseigo> seele: but we are aware of this "annoyance" and are working on it
[21:14:17] <agateau> seele: yes
[21:14:25] <aseigo> reason being that it's not really 100% fixable with the current system
[21:14:40] <aseigo> we just don't get enough information about applications with the current system to know what to do, and we can't set policy in the tray
[21:14:54] <agateau> first i would like to say it should not be a 100% rule, but I think a lot of apps use multiple toolbars without a good reason
[21:15:00] <agateau> examples : konqueror
[21:15:06] --> juan--d-_-b (n=juan--d-@unaffiliated/juan--d--b/x-561435) has joined #kde-usability
[21:15:07] --> yaroslav_ ([email protected]) has joined #kde-usability
[21:15:11] <agateau> not the bookmark bar,
[21:15:19] <agateau> but the buttons + url
[21:15:26] <agateau> should be only one bar imho
[21:15:43] <agateau> other example : akregator
[21:15:48] <Chani> why?
[21:16:07] <agateau> 1. multiple bars add visual clutter
[21:16:22] -*- eean doesn't see multiple toolbars in akregator
[21:16:38] <agateau> 2. it's easy for a not so tech savvy user to get a weird toolbar layout
[21:16:44] <agateau> eean: let me post a shot
[21:16:59] <aseigo> agateau: agreed ... getting those down in number would be good
[21:18:25] <eean> oh I found them for akregator
[21:18:28] <Chani> hmm. I dunno.
[21:18:39] <leinir> Now, i am not entirely sure that i see the defaults, but does KDE ship with locked toolbars?
[21:18:40] <agateau> eean: just when I press the upload button :)
[21:18:47] <seele> agateau: is this by default or technically limit?
[21:19:11] <Peter007> I think a one toolbar is good, provided it is customisable, the current situation is to use multiple tb to do that
[21:19:16] <agateau> seele: in most case, it's a deliberate choice i think
[21:19:29] <Chani> I have a vague memory of back when the location *was* on hte same toolbar, and sometimes this would force the entire toolbar onto a second line... but maybe that's fixed now?
[21:19:30] <agateau> Peter007: toolbars are customisable
[21:19:32] <aseigo> leinir: no
[21:19:47] <Peter007> cool
[21:20:03] <leinir> In that case, my question would be wether there is any reason for KDE to ship with the toolbars unlocked?
[21:20:28] <agateau> Chani: never happened to me (which does not me it never happened :)
[21:20:38] <agateau> s/not me/not mean/
[21:20:40] <seele> leinir: i think locking them could provide the benefit of preventing users from messing them up by accident :)
[21:20:47] -*- Chani had a lot of trouble with konq's toolbars in kde3
[21:20:58] <seele> agateau: are we waiting for a screenshot?
[21:21:08] <leinir> Since i've been silly enough to have a couple of beers tonight, i am not sure my reasoning is entirely sound, and as such would rather bring it up for discussion in this context than immediately suggest it as a solution ;)
[21:21:23] <agateau> seele: hmm no, I was about to upload one for eean, but he found out what I was talking about
[21:21:35] <leinir> seele: But yes, that was my reasoning (and i do believe that i've reasoned that way without alcoholic assistance before ;) )
[21:21:52] <eean> agateau: well there's the browser toolbar, but it kind of makes sense for that to be seperate
[21:21:55] <Chani> having multiple toolbars does make it a lot easier to do simple customisation. if I want to put a group elsewhere or delete a whole group I don't have to remove or move icons one by one (and moving things is a pita in the toolbar config dialog)
[21:22:22] <Peter007> chani: agree
[21:22:39] <leinir> Chani: An example is my toolbar layout in Konqueror, where i've got a few more icons in the navigation toolbar than there's room for, which then folds out to allow for extra actions...
[21:22:50] <leinir> not too well described, but i hope you get the idea :)
[21:22:59] <Chani> actualy, I think my biggest problem with toolbars is those weird <merge> things. I can't move them to another toolbar, I can't always get rid of them, and if I do get rid of them they're gone forever which might not be what I want :/
[21:23:10] <seele> so maybe the issue is more that many applications just have too many unnecessary toolbars that should be combined, and not that all applications should have one toolbar?
[21:23:18] <agateau> Chani: the toolbar config dialog could be improved, but I would argue this is something you don't do often, this does not sound like a reason to impose multiple toolbars to everyone
[21:23:20] <seele> because koffice is another example where multiple toolbars make sense
[21:23:36] <Chani> which applications have unnecessary toolbars?
[21:23:39] <agateau> seele: yes I believe it makes sense here
[21:23:54] <agateau> Chani: let me gather some
[21:23:56] <Nightrose> Chani: parley should be looked at imho
[21:23:57] <agateau> konqueror (imho)
[21:24:02] <agateau> akregator
[21:24:09] <agateau> kopete
[21:24:18] <Chani> agateau: I guess I don't see it as much of an imposition. like applet handles; if you don't like it, lock them.
[21:24:19] <colomar> So wee need - at least relatively - clear rules for when multiple toolbars make sense and when they don't
[21:24:54] <Peter007> erm... would it be possible for apps to ship with a default tb, and allow users to create their own?
[21:25:05] <seele> colomar: yes, i think that is probably the more practical solution.
[21:25:13] <-- juan--d-_-b (n=juan--d-@unaffiliated/juan--d--b/x-561435) has left #kde-usability
[21:25:17] <agateau> Peter007: I believe it can be done, if you are not afraid of xml editing
[21:25:18] <seele> i'm sure a lot of toolbars could be merged, but there are a lot of cases where separate toolbars make sense
[21:25:38] <agateau> seele: yes, that's how I feel
[21:25:43] <seele> has anyone seen how mac osx does it's toolbar configuration?
[21:25:48] <seele> with the drag n drop?
[21:25:53] <Peter007> agateau: not what I had in mind, more like a tn creator:)
[21:25:54] <agateau> like firefox iirc
[21:25:56] <Chani> agateau: I AM afraid of xml editing.
[21:26:03] <seele> any libs/qt experts know how impossible that is?
[21:26:16] <agateau> Chani: this is where the toolbar config dialog could be improved, maybe :)
[21:26:19] <Peter007> s/tn/tb/g
[21:26:24] <Chani> agateau: true.
[21:26:35] --> michaelrudolph ([email protected]) has joined #kde-usability
[21:26:38] <seele> ok, so that begins to lead in to another topic which is sortof related
[21:26:50] <seele> and i have a feeling i'm going to assign agateau and colomar to work together on this if they would like :)
[21:26:56] <Chani> my biggest fear here is of multiple <merge> thingies all in one toolbar, and I don't want them, but don't want to delete them forever either...
[21:27:04] <agateau> :)
[21:27:16] <seele> colomar (Thomas Pfeiffer) was one of our SoU students this past year, and he worked on some ui patterns for things like configuring lists
[21:27:18] <Chani> actually, the one akregator has is outright broken anyways
[21:27:18] <leinir> seele: Yes, the macos x toolbar editing feels extremely powerful and pleasant to use - also with the defailt layout pseudo-token, very nifty :)
[21:27:28] <seele> an application of this could be the toolbar configuration tool
[21:27:35] -*- Chani has no buttons on hte browse toolbar :( and can't do anything because it's a <merge>
[21:27:49] <-- yaroslav ([email protected]) has quit (Read error: 110 (Connection timed out))
[21:28:03] <-- yaroslav_ ([email protected]) has quit ("Konversation terminated!")
[21:28:13] <agateau> colomar: didn't you present your work at akademy?
[21:28:17] <seele> he did
[21:28:26] <agateau> ok, was there :)
[21:28:30] <seele> so. i dont think "one toolbar" is a practical solution, but the problem does exist
[21:28:41] <seele> agateau: you have sortof volunteered yourself for this one because you brought it up
[21:28:47] <Peter007> having suggested creating tb, I am very lazy and leave the tb as is, so I don't like my own idea;)
[21:28:48] <seele> if anyone else is intersted in this, please speak up
[21:28:53] <agateau> i would say, "one toolbar unless you have a good reason"
[21:28:54] <colomar> agateau: Cool, people actually rembered that :)
[21:29:01] <leinir> Well, one toolbar may not be a practical solution, but making it *look* like a single toolbar...
[21:29:05] <seele> but perhaps agateau and anyone else could get together and find toolbars that could be merged
[21:29:07] <leinir> i.e. shipping with toolbars locked
[21:29:14] <seele> leinir: yes
[21:29:23] --> yaroslav_ ([email protected]) has joined #kde-usability
[21:29:24] <agateau> seele: I can do this, yes
[21:29:33] <Chani> leinir: makes sense to me
[21:29:36] <seele> once the toolbars are fixed, we can look at what existed as problems, and write down guidelines on how to create toolbar groupings
[21:29:59] <seele> also, agateau if you want to work with colomar on this (or anyone else), colomar designed some patterns for list administration
[21:30:12] <leinir> That could even be used as a hack to provide those different size buttons...
[21:30:17] <seele> so maybe there is a way to improve the existing toolbar UI so that if people want to configure their now larger toolbars, they can do that easily
[21:30:21] <leinir> But that's for another day :)
[21:30:21] --> heowHoew ([email protected]) has joined #kde-usability
[21:30:26] <agateau> seele: you are thinking about the toolbar config i guess
[21:30:30] <seele> agateau: yes
[21:30:43] <seele> colomar: are you ok with this, i just volunteered you :)
[21:31:02] <agateau> seele: i would like to give a try to the macosx/firefox config style
[21:31:03] <colomar> Uhm, I
[21:31:11] <agateau> to see if it's technically possible
[21:31:21] <colomar> am not exactly sure what to do yet, but I'm okay with it I guess ;)
[21:31:27] <agateau> it feels the most natural way to configure the bar
[21:31:29] -*- Peter007 wonders about auto adding a toolbutton based on user usage, and removal of unused buttons
[21:31:31] <seele> ok great
[21:31:33] <seele> agateau: sounds good
[21:31:47] <Chani> agateau: what's that?
[21:31:59] <leinir> Peter007: That's the same as personalised menus, the single most hated (mis-)feature in Windows XP ;)
[21:32:00] <seele> so agateau and colomar are going to work on the toolbar issue and i will follow up with them after a bit
[21:32:16] <agateau> seele: fine with me
[21:32:24] <Peter007> leinir: lol, my bad
[21:32:28] --> notmart ([email protected]) has joined #kde-usability
[21:32:37] <DreadKnight> perhaps we should have the application send data to a server about the most used/clicked actions and such
[21:32:41] <agateau> Chani: start firefox, then right click a toolbar and select "customize"
[21:32:43] <seele> ok, let's see where we are on the list..
[21:32:56] <Chani> oh right. I have firefox installed now...
[21:33:12] <seele> colomar: did you want to talk anymore about the design patterns? or do you want to focus on working with agateau on the toolbar UI and formalize that pattern first?
[21:33:14] <leinir> Peter007: Hey, someone has to suggest it at least once during every discussion on usability, it's something like a rule ;) Kinda like the whole basic/expert settings thing, someone has to bring it up so someone can hit them over the head with a brick ;)
[21:33:31] <seele> colomar: (maybe you guys can create a standardized class for list editing out of it.. *g*)
[21:33:41] <Peter007> leinir: yea but why me, you the one drinking;)
[21:33:52] <leinir> i've been doing it for a while ;)
[21:34:00] <seele> oh, the next one is colomar's too
[21:34:02] <leinir> (not the drinking, the usability thing ;) )
[21:34:05] <seele> # Get hot new stuff: Should description text be wrapped? (Thomas Pfeiffer)
[21:34:09] <agateau> Peter007: throwing brick is easier when drunk, maybe?
[21:34:10] <leinir> Right, sorry, shutting up now :)
[21:34:16] <seele> colomar: do you want to describe the issue and how you suggest to fix it?
[21:34:22] <colomar> Yes
[21:35:02] <Chani> agateau: ooh, that firefox things deals with the bookmark toolbar items in a way that I can actually use! no horrid <merge> beasts :)
[21:35:14] <agateau> :)
[21:35:27] <colomar> The issue is that in the ghns dialog long descriptions do net get wrapped so one has to make the dialog very wide to be able to read them.
[21:35:39] <agateau> TBH, I guess Firefox does not have to implement <merge> beasts :)
[21:36:28] <Nightrose> colomar: any reason not to do it?
[21:36:32] <Chani> colomar: wordwrap is a pretty obvious feature to me... any reason *not* to have it?
[21:36:41] <colomar> So i'd suggest to apply wrapping there so that long descriptions go over multiple lines instead
[21:36:53] <agateau> colomar: agreed
[21:36:57] <seele> anyone working on ghns?
[21:37:12] <seele> hmm.. i dont see jeremy online
[21:37:32] <seele> is a change like this easy enough to make or is there a technical reason we can't do it?
[21:37:45] <Nightrose> he has a new gf since a few days
[21:37:52] <Nightrose> don't expect him to show up on irc
[21:38:00] <Nightrose> email will do probably
[21:38:02] <seele> also to consider is can we limit the number of lines. so while having 2 or 3 lines of description would be good, having a very long description would be bad
[21:38:25] <Peter007> wrap and scroll?
[21:38:29] <agateau> seele: the tricky thing is rows will have different heights, but this should not be a blocker
[21:38:32] <seele> and so we would need something that can show 1 > n < 4 lines of text
[21:39:10] <seele> ok
[21:39:25] <agateau> anyone now where ghns code is in svn?
[21:39:45] <agateau> s/now/know/
[21:39:55] <seele> not sure. is jeremy whiting still maintaining ghns?
[21:40:12] <Nightrose> yes
[21:40:12] <agateau> nevermind I found it (kdelibs/knewstuff)
[21:40:21] <-- notmart ([email protected]) has quit ("Leaving")
[21:40:41] <seele> ok. so no one seems opposed to this design suggestion
[21:40:53] <seele> i will make a note to talk to jeremy about it
[21:41:02] --> notmart ([email protected]) has joined #kde-usability
[21:41:14] <colomar> cool. Finally I can read whole descriptions ;)
[21:41:29] <colomar> or will be, once it gets done
[21:41:39] <seele> ok. so we've gotten through 4 items today, which i think it pretyt productive
[21:41:49] <seele> we havent hit the 2 hour mark, but i think this is a good stopping point for today
[21:42:05] <leinir> *nods* People are slowly drifting, i would agree yes :)
[21:42:06] <seele> i will post the summary of actions on the wiki page and probably to the usability mailing list
[21:42:17] <seele> the next meeting will probably be in the middle of the week for those of you who go out on the weekend
[21:42:20] <DreadKnight> ghns is a bit scary because of the thumbnails.. no actuall quick preview of plasma themes or desktop wallpapers without actually installing /trying them out for yourself, which takes more energy and time
[21:42:27] <Peter007> thanks seele, good job
[21:42:29] <seele> thank you everyone to coming to the meeting and participating, i think we were very productive
[21:42:32] <leinir> Cheers! :)
[21:42:38] <seele> i'm thinking another meeting in one month
[21:42:44] <seele> until then, feel free to add items to the meeting page
[21:42:47] <DreadKnight> linux mint even provides screenies for packages from the package manager (add/remove thingy)
[21:42:47] <seele> cheers everyone!
[21:42:57] <DreadKnight> bye!
[21:42:59] -*- notmart sad having missed it
[21:43:06] <notmart> phew, damn real life :p
[21:43:16] <seele> notmart: someone should be posting logs and i will provide a summary of what happened :)
[21:43:28] <notmart> :)
[21:43:44] <Chani> seele: I was surprised that this meeting was at noon for me. normally I have to put up with awkward meeting times
[21:43:46] <Peter007> notmart: not the same, is it?
[21:44:33] <notmart> Peter007: no, indeed, until one can go back in time to be able to argue :p
[21:44:35] <seele> Chani: better than at 6am :)
[21:45:03] <Peter007> notmart: next month I'll let you make up for it
[21:46:22] <Peter007> so is this summary going to be posted on kde-usability list?