Projects/Usability/Meetings/2009March18

Meeting theme: Usability Bugs!

Proposed window bar layout (part of Bug 187233)

• Bug: https://bugs.kde.org/show_bug.cgi?id=187233
• Proposed layout: http://bugi.oulu.fi/~slougi/files/dolphin.png
• Action: slougi to write script to allow users to switch between their current and proposed window bar layouts, so we can test lots of users
• Action: slougi to organize meeting with KWin folks to review other issues

Make often used/primary actions (e. g. "empty trash") more prominent

• Issue: In context and menubar menus, the most common actions could be more prominently displayed to help users more quickly identify them, and to help them make a decision
• Action: NSaibot to coordinate with others and come up with mockups/screenshots of different design ideas to be discussed at the next meeting.

Konqueror's "save password" dialog is unintuitive

• Bug: https://bugs.kde.org/show_bug.cgi?id=168060
• I think this is in progress, I've seen new screenshots recently

Keyboard's "Super" key doesn't launch Kmenu

• Bug: http://bugs.kde.org/show_bug.cgi?id=154564
• Issue: Cannot launch Kmenu from single key because the System key is a modifier. Needs to be fixed at the kdelibs level (kdeui/dialogs/kshortcutsdialog.cpp?).
• Action: seele to contact mjansen to discuss problem

Select/enter newly created folder/file automatically

• Bug: http://bugs.kde.org/show_bug.cgi?id=155706
• Proposal: When a new folder is created, the user should automatically be entered in to the new folder.
• Resolution: On new folder creationg: Dolphin selects folder, File Save enters folder. New folder functionality will be removed from File Open.
• sreich to discuss with dfaure and submit patch

Log of the discussion (UTC+1 timestamps)

[21:00] <seele> welcome everyone to the kde usability meeting

[21:00] <seele> http://techbase.kde.org/Projects/Usability/Meetings

[21:00] <seele> for those of you who were not here last time, please read over that page and familiarize yourself with the format

[21:01] <seele> first i need a volunteer to post the meeting log to the wiki

[21:01] <seele> anyone?

[21:01] <tsdgeos> i can do that

[21:01] <seele> ok thank you

[21:02] <seele> today's meeting theme are usability bugs. there are a number of bugs listed on the meetings page that we will try to go through and discuss

[21:02] <seele> there are *a lot* of bugs listed, and i don't expect to get through all of them

[21:02] <leinir> present

[21:02] <seele> also, many of the bugs may not be resolvable today, so we will try to find the right people to contact (if they are not here) to look in to them further

[21:02] <seele> but before we do that, first i would like to provide an update from some of the action items from the last meeting

[21:03] <seele> regarding Settings vs. View menu in the toolbar, I haven't had a chance to draft the guideline yet, but i expect to get to it by the end of the month

[21:03] <seele> regarding the System Tray, the plasma team is working on a new systray and how application services will be handled. expected for 4.3

[21:04] <seele> regarding the number of application toolbars, agateau has started a wiki page to collect examples of applications with multiple toolbars

[21:04] <seele> http://techbase.kde.org/User:Agateau/TooManyToolbars

[21:05] <seele> hopefully we will be able to get together and review them by the end of the month and make progress on that item

[21:05] <seele> regarding text wrapping in GHNS, i talked with jwhiting and he said that it should be already fixed in SVN

[21:06] <seele> that is the end of updates from the last meeting

[21:06] <leinir> Good updates there :)

[21:06] <sreich> GHNS?

[21:06] <seele> sreich: get hot new stuff, the get new.. functionality in a lot of applications

[21:06] --> colomar ha entrat aquest canal ([email protected]).

[21:06] <sreich> ah, gotchya

[21:07] <seele> ok.. so there are lots of bugs listed on the wiki page with no names

[21:07] <leinir> Arguably, adding a functionality directly in kmainwindow might make sense, re the question about search fields on Agateau's page there :)

[21:07] <seele> who here posted a bug on the page and would like to talk about it (to see who is here and who isn't)

[21:07] <leinir> Sorry, off topic :)

[21:07] --> agateau ha entrat aquest canal ([email protected]).

[21:07] --> rafael_carreras ha entrat aquest canal ([email protected]).

[21:08] <slougi> I posted the kwin bug.

[21:08] --> adymo ha entrat aquest canal ([email protected]).

[21:08] <seele> agateau: colomar: rafael_carreras: welcome

[21:08] <agateau> seele: thanks!

[21:08] <colomar> thx

[21:08] <seele> ok. slougi, do you want to review the bug so everyone is aware of the problem?

[21:08] <seele> I think this is the bug link: http://bugs.kde.org/show_bug.cgi?id=15329

[21:09] <slougi> sure. i think kwin's defaults can be improved in a number of areas. it's the only part of kde that i configure any time i set up a new account or reset settings for some reason.

[21:09] <slougi> hmm no, that's a different one

[21:09] <slougi> one sec

[21:09] <slougi> https://bugs.kde.org/show_bug.cgi?id=187233

[21:09] <seele> oops, sorry about that

[21:09] <slougi> a number of kwin people replied to the bug

[21:09] <leinir> Is window folding still the default for double-click on titlebar?

[21:10] <sreich> I don't think so

[21:10] <slougi> nope, maximize

[21:10] <sreich> do you mean "Shade"

[21:10] <sreich> believe that's the proper term

[21:10] <blauzahl> i wouldn't mind talking about the konq bug, i didn't post it, though :)

[21:10] <slougi> my point is mainly with 1) the default buttons in the win decoration and 2) composite effect settings as out of the box

[21:10] <leinir> ok :)

[21:10] <leinir> sreich: Sorry, yeah i mean shade :)

[21:11] <sreich> slougi: what about 2.) ?

[21:11] <slougi> regarding the default buttons, I'm not happy with the current default of the sticky button being shown. I think a lot of users may have no idea what it does.

[21:11] <sreich> ah, nvm, i see

[21:11] <sreich> yeah, I never use it either

[21:12] <seele> ok, so maybe let's step through each of the defaults the bug recommends and decide if it makes sense or not

[21:12] <sreich> to be honest, I am curious to know how many people -actually- use that button/feature...

[21:12] <sreich> soudns good

[21:12] * pinotree , almost daily

[21:12] * agateau too

[21:13] <slougi> sreich: regarding 2) i think the default window switcher is a bit confusing. i get motion sickness any time i use it. also, i think adding transparency to moving windows by default is not good, as it draws attention away from the window itself. lastly, i think in the present window effect the default text and icon overlay make visual identification of the windows more difficult.

[21:13] <leinir> Hmm... Lucas Murray's comment about motion sickness quite valid - i know numerous people who have that problem (three to be exact), so it's not really uncommon

[21:13] <pinotree> but i don't mind, i added it myself in the configuration long ago

[21:13] <leinir> ok, three then ;)

[21:13] <slougi> in a nut shell, that's it :)

[21:13] <leinir> *four

[21:13] <seele> ok.. so point one in the bug:

[21:13] <seele> 1. I think the default button arrangement can be improved. The button order

[21:13] <seele> suggested by aseigo some time back really does work very well in practice, for

[21:13] <seele> me and anecdotally for several users.

[21:14] <pinotree> that is?

[21:14] <seele> are those the minimize/maximize/close buttons?

[21:14] <sreich> slougi: what is the default window switcher exactly? But usually I think, when people move windows, they want to know what is beneath them

[21:14] <sreich> case in point, transparency

[21:15] <agateau> i think the order was [close] [title] [minimize][maximize]

[21:15] <slougi> sreich: it makes the windows translucent, except for the one which would be selected. it's very confusing visually for me at least

[21:15] <slougi> agateau: no, it was minimize, maximize, spacer, spacer, [icon/window menu], title, close

[21:15] <agateau> oh

[21:15] <agateau> even worse :)

[21:16] <pinotree> icon in the middle? ugh

[21:16] <sreich> in the middle.... hm

[21:16] <leinir> Close specifically being far away from all other control points, because it's a descructive action :)

[21:16] <leinir> In the middle?!

[21:16] <slougi> leinir: exactly

[21:16] <sreich> well... a mockup would help...

[21:16] <leinir> The spacers don't put things in the middle ;)

[21:16] <leinir> Just a second, i'll grab a screenshot...

[21:16] <slougi> sreich: just configure kwin like that for a second? :)

[21:16] --> Chani ha entrat aquest canal ([email protected]).

[21:17] <sreich> slougi: yeah, but then my luck is system settings will suddenly drop it's kcm's and i'll be screwed with that there :)

[21:17] <slougi> http://bugi.oulu.fi/~slougi/files/dolphin.png <-- here is a screenshot i took while back

[21:18] <leinir> Damn, slougi was faster ;)

[21:18] <seele> this is the proposed layout?

[21:18] <leinir> That is the proposed layout, yes :)

[21:18] <leinir> It is, however, missing the quickhelp button

[21:18] <slougi> well, that's actually secondary :) mostly i wonder whether the sticky button should be on by default

[21:18] <adymo> what about center-aligning the icon and window title then? (will somehow resemble mac ui, they don't have window icon on mac)

[21:18] <sreich> that feels so foreign, it's weird after using the same way for years then changing...

[21:18] <slougi> but yes, that's the button layout i prefer

[21:18] <sreich> yeah, icon and title (at least the latter)

[21:18] <agateau> adymo: there is a window icon on mac

[21:19] <sreich> leinir: I think the help button should be near minimize... otherwise someone asking for help closes the window :P

[21:19] <adymo> agateau: ah, right, but not for all windows

[21:19] <leinir> sreich: That's where i've got mine :)

[21:19] <seele> where would the what's this button go?

[21:19] <agateau> adymo: yes i believe you are right

[21:19] <leinir> actually, i have it to the left of the icon/window menu

[21:20] <leinir> (as in, between the spacer and that)

[21:20] <sreich> seele: that's what we were saying

[21:20] <leinir> Works quite well :)

[21:20] <sreich> (to the right of the restore button)

[21:20] <leinir> Anecdotally, of course :)

[21:20] <agateau> I think the argument "close is a destructive action so it must stay apart" is not really valid, because applications were close is destructive will/should take care of protecting the user

[21:20] <leinir> sreich: minimize, restore, spacer, whatsthis, icon, title, close

[21:20] <agateau> changing the button order like this creates differences for little benefit imo

[21:21] <Chani> so what's the topic?

[21:21] <sreich> leinir: spacer b/w icon & whats this

[21:21] <seele> Chani: https://bugs.kde.org/show_bug.cgi?id=187233

[21:21] <agateau> Chani: button order in window title

[21:21] <leinir> sreich: Could work too :)

[21:21] <seele> Chani: new window bar layout was proposed

[21:21] <Chani> huh

[21:21] <leinir> It'd satisfy the requirement to leave the other hit targets in their original position, so it's better than my idea as well :)

[21:21] <sreich> agateau: yeah, I personally am not sure how this helps... but i guess the only benefit is that it separates close & minimize

[21:22] <sreich> well.. close & others

[21:22] <sreich> agateau: protecting the user? you mean prompt for closing in every single window?

[21:22] <agateau> iirc, default kde conf already separates close & others

[21:22] <sreich> yeah, but not by this much

[21:22] <seele> sreich: he means if the user is going to lose data from closing the application, it should prompt them

[21:22] <agateau> sreich: i mean prompt when closing a window means loosing data

[21:22] * Chani used to put the close button on the left so that there was less risk of hitting it by accident. back then my friends were really really lost when they tried to use my comp :)

[21:22] --> zanoi_ ha entrat aquest canal ([email protected]).

[21:22] <slougi> imho, the default currently is also visually cumbersome ;) moving to bike shed alert level 3

[21:22] <sreich> seele: oh okay, yeah, I see

[21:23] <Chani> it worked great for *me*, but not for others

[21:23] <sreich> Chani: yeah, I can imagine...

[21:23] <seele> so relearning button order is an issue

[21:23] <sreich> Chani: yeah, users bred in this environment stick with it, they see something new like this and become frightened

[21:23] <seele> and since this layout isn't being used by too many people, it's hard to tell if it is easily relearnable

[21:23] <Chani> right now it seems I have a spacer before the X. is that default or did I do it?

[21:23] <slougi> Chani: default

[21:23] <sreich> default

[21:24] <slougi> i think it's actually two spacers

[21:24] <NSaibot> we wouldn't have to bother about the buttons being dangerous if we could "undo" just about anything. however, dunno if that's possible :)

[21:24] <seele> i think minimizing and maximizing a window are conceptually different from closing an application, and so people may be able to learn it easily

[21:24] <seele> but that is just an assumption

[21:24] <sreich> NSaibot: maybe in kde 12 :)

[21:24] <NSaibot> hehe

[21:24] <notmart> and quite sensible default even if not too visually pretty

[21:25] <seele> how is the layout information stored? can a theme be packaged and easily distributed to get people to try out a new layout?

[21:25] <seele> i would also like to get the oxygen team's opinion on what to do with the title and how it should be aligned

[21:26] <seele> i assume in the center, since the min and max buttons create a pretty big offset

[21:26] <notmart> the layout is from kconfig, iirc the default one can be overridden also by a custom window decoration

[21:27] <notmart> seele: iirc nuno with center was ok

[21:27] <seele> notmart: ok

[21:27] <seele> ok, maybe i should rephrase the first question

[21:27] <seele> is there an easy way to get people to try out this layout and have them easily revert if they want?

[21:28] <seele> can it be configured in a theme and shipped via GHNS? or do they manually need to change it?

[21:28] <seele> and then manually need to change it back

[21:28] <slougi> it's quite easy to configure the layout in the kwin settings - afaik there is currently no GHNS support

[21:28] --> sebas ha entrat aquest canal ([email protected]).

[21:28] <notmart> no, don't think possible with ghns

[21:29] <seele> slougi: the problem is testing it. fewer people will go in and configure it manually. it would be easier for them to just install a new theme and then switch it back.

[21:29] <notmart> could be said "install this configuration file"

[21:29] <slougi> seele: right

[21:29] <seele> configuring it yourself means you have to remember what the default was

[21:29] <slougi> just hit the defaults button?

[21:29] <Peter133> The png is the current arrangement, or the desired one?

[21:29] <seele> Peter133: the proposed

[21:30] <seele> slougi: it needs to be easy to test if we want regular people to try out the new config. right now the effort and cost of trying it out is too high

[21:30] <Peter133> Looks okay, is what I have in reverse (right to left)

[21:30] <Peter133> I seldom use sticky, but I like where it is

[21:31] <seele> is the config stored simply in a text file? maybe a simple script that switched the current with the proposed would help

[21:31] <seele> windec -new, windec -restore.. seems simple enough for people to try

[21:31] <leinir> Peter133: Reason to have it this way around is that the single destructive item (close) is away from everything - i used to have it the other way around as well, but sometimes ended up clicking close when i actually wanted to click on the window menu :)

[21:31] <agateau> seele: i believe it is, but the script would have to force kwin to reread its conf

[21:32] <sebas> It should probably do "kquitapp kwin; <replace config>; kwin"

[21:32] <Peter133> leinir: All buttons reversed, not just close

[21:32] <leinir> Peter133: the icon as well?

[21:32] <leinir> and title?

[21:32] <Peter133> yea

[21:32] <sebas> Can I see the png, I joined late?

[21:33] <notmart> ~.kde4/share/config/kwinrc

[21:33] <Peter133> close on right all other buttons on left, title between

[21:33] <notmart> would just mean replacing that file

[21:33] <slougi> sebas: http://bugi.oulu.fi/~slougi/files/dolphin.png

[21:33] <Peter133> sorry, close on left

[21:33] <seele> ok, so it seems like making a simple script might be possible? since the windec stuff in system settings is only configurable and not themable

[21:33] <slougi> looking at the kwin dbus methods, it should be simple to have it reload the config

[21:33] <slougi> how about i write a script for the next meeting?

[21:34] <notmart> seele: yes, rewriting the config also means nuking the effects settings so users should be warned to not be pissed off

[21:34] <seele> slougi: yes, that would be good

[21:34] <slougi> notmart: you could just slurp them out of the config and restore them later

[21:35] <agateau> notmart: one can use kwriteconfig to avoid rewriting the whole config file

[21:35] <NSaibot> Peter133: close on the left sounds pretty good

[21:35] <notmart> agateau: yeah true

[21:36] <seele> ok. slougi will write a script which will allow users to switch between their current and the proposed windec layouts

[21:36] <sebas> Personally, I don't like the idea because it's totally different from what I've used to and doesn't provide real advantage (I'm using active corners already)

[21:36] <seele> then we'll try to get as many people to try it for a period of time and get feedback

[21:36] <sebas> Do we have something in the top-left by default?

[21:36] <seele> sebas: that's why we're trying to find an easy way for people to try it, so we can get their feedback

[21:37] <sebas> yup, I get that. I had run with it for a bit when we discussed it up to 4.0

[21:37] <notmart> sebas: top-left is expose by default iirc

[21:37] <sebas> Aight, I've got that too

[21:37] <sebas> yay for good defaults ;)

[21:37] <agateau> and it creates even more differences for people switching between kde and gnome

[21:38] <seele> ok. slougi, were there any other points in that bug you wanted to discuss

[21:38] <NSaibot> i thought it's about usability and not compatibility

[21:38] <slougi> yes, the default configuration for a few effects. i'd like to start with the present windows (exposé) effect, since that bugs me the most :)

[21:38] <leinir> NSaibot: Expected behaviour is part of usability as well, donchaknow ;)

[21:38] <agateau> NSaibot: usability is also about minimizing relearning

[21:38] <NSaibot> leinir: then it'd depend on where you come from

[21:39] <seele> if it is really that much better, then we shouldnt worry about cross desktop consistency, however, we can also provide themable window bar layouts so users can choose a more common one.. but that's a different issue

[21:39] <NSaibot> coming from mac you'd expect the button on the left

[21:39] <seele> slougi: what is the expose' effect?

[21:39] <seele> (i have all effects turned off, poor laptop)

[21:39] <NSaibot> seele: presenting all the applications

[21:39] <slougi> i think it's not a good idea to have the text and icon overlayed by default, since it detracts from the visual identification of windows, which is the whole point of the effect. the icon not so much, since it's in the corner, but my eyes at least always dart straight to the text.

[21:39] <agateau> NSaibot: mac layout is still very unlike the proposed layout

[21:39] <leinir> Yes, and from anywhere else you expect it on the right :)

[21:39] <slougi> seele: the one that shows all the windows and you can click to select one

[21:40] <NSaibot> leinir: point taken

[21:40] <agateau> slougi: the thing is: it helps with keyboard filtering i guess

[21:41] <seele> can the text go below the window or is there not enough space for that?

[21:41] <slougi> agateau: right, that's a point i hadn't considered.

[21:41] <seele> is this a big issue also? has anyone else felt like the label obstructs their view?

[21:41] <NSaibot> however, i think apple invested lots of time in usability and stats.

[21:41] <NSaibot> i'm silent now about that issue

[21:42] <seele> no one has an opinion about the expose' view?

[21:42] <leinir> i personally really like the labels

[21:42] * seele turns on internationalized keyboard

[21:42] <slougi> seele: the text could probably go below the window, or in a corner. currently the window icon is shown on the lower right and text in the middle.

[21:42] <sreich> yes, but quite honestly not everything should be based off of apple... we are targetting a different audience, by far.

[21:43] <leinir> Hmm... slougi that's a good point, it's possibly a bit too front-and-center :)

[21:43] <slougi> i agree with sreich, i think KDE should set its own direction. of course copying good ideas is not a bad thing ;)

[21:43] <leinir> icon on lower left, text right next to it, might make sense :)

[21:43] <agateau> seele: I like the label too, but I agree it could be shown at bottom

[21:43] <NSaibot> slougi: exactly :)

[21:43] <sreich> yes, but saying that "because apple does it, they do lots of studies"

[21:43] <seele> ok, so maybe create a screenshot (fake or real) of a new layout and we can comment on it

[21:43] <seele> i think it is too hard to imagine how much better it would be without seeing it

[21:44] <slougi> right. my compositing is broken for some reason currently :)

[21:44] <NSaibot> sreich: not because apple did it, because it separates "dangerous" from less "dangerous" behaviour

[21:44] <slougi> seele: i think a big part is also the animation...

[21:44] <leinir> my laptop can't pull it ;)

[21:44] <sreich> NSaibot: yeah

[21:44] <leinir> (right graphics chip, too high resolution)

[21:44] <sreich> i'm just saying, using apple as a comparison should be just that, it should not be a derivitive of it, or a justification

[21:45] <NSaibot> right

[21:45] <sreich> (there are exceptions, however, I imagine).

[21:45] <seele> sreich: NSaibot: please stay on topic

[21:45] <sreich> :)

[21:45] <seele> slougi: ok, i think going too much in to this issue will eat up more time. maybe there can be another meeting with the kwin folks about it since they will know what can and cant be done

[21:46] <slougi> seele: ok

[21:46] <seele> slougi: next issue from that bug? i would like to move on to another bug soon as well

[21:46] <slougi> seele: i understand. window transparency when moving. i think it draws attention too much to the underlying windows, away from the window being moved.

[21:47] <leinir> arguably, if you are moving a window, you are trying to move it out of the way to see something else...

[21:47] <seele> this sounds like another preference/performance issue. a lot of people like that effect

[21:47] <seele> leinir: good point

[21:47] <NSaibot> leinir: or to have more space to resize this window

[21:47] <slougi> right, many of these are bike shed issues. but a number of people (anecdotes again) have found it confusing apart from me.

[21:47] <leinir> NSaibot: always found that funny, all four corners are resize points :)

[21:48] <-- Peter133 has left this server (Read error: 104 (Connection reset by peer)).

[21:48] <NSaibot> i didn't say it's rational ;)

[21:48] <seele> slougi: it can also be configured to be turned off. maybe that option is too hard to find?

[21:48] <NSaibot> but that's the way it is

[21:48] <colomar> It definitely looks cool. And I don't the window's content is what users care about most when moving a window, either

[21:48] <slougi> seele: i think the kwin configuration in general is currently very much suboptimal, but i'd like to discuss that some other day :)

[21:48] <seele> ok

[21:48] <seele> is that all for that bug then?

[21:49] <leinir> Yeah, i've an idea or two for that too, but... later :)

[21:49] <agateau> I usually disable transparency when moving too, i find it annoying when I move the window only a few pixels to have it fade in and out

[21:49] <slougi> seele: pretty much. one point is shortcuts, i think this a bit of a bigger picture issue too.

[21:49] <seele> ok

[21:49] <seele> maybe you can try to get a meeting together with the kwin people and we can talk about those issues

[21:50] <seele> i would like to move on

[21:50] <slougi> a lot of the current shortcuts are US-keyboard centric, and i have to reconfigure them to be able to press them at all. this extends to some other apps too.

[21:50] <slougi> seele: sure

[21:50] <slougi> thanks for your time everyone

[21:50] <seele> does anyone else present have a usability bug they posted on the meeting page? there were a number of them added in the past few days

[21:50] <seele> slougi: thanks

[21:50] <NSaibot> i posted one

[21:51] <seele> NSaibot: ok, can you give us the link and describe the issue?

[21:51] <NSaibot> #8

[21:51] <NSaibot> oh, sorry no bug

[21:51] <NSaibot> just a suggestion

[21:51] <seele> ok

[21:51] <seele> # Make often used/primary actions (e. g. "empty trash") more prominent. NSaibot

[21:51] <NSaibot> yea

[21:51] <seele> can you explain what the usability issue is and what you mean by your recommendation?

[21:52] <NSaibot> i'll try

[21:52] <leinir> Also, what in particular do you mean by prominent? Colour, size, position...?

[21:52] <NSaibot> the example i made was with the trash bin

[21:52] --> Peter133 ha entrat aquest canal ([email protected]).

[21:53] <NSaibot> the empty trash is easy confused with delete pastbin

[21:53] <NSaibot> trash bin*

[21:53] <NSaibot> so making the often used or primary actions more prominent (colour or size) would be of help

[21:53] <NSaibot> to minimize such confusion

[21:53] <seele> NSaibot: what UI are you in? a context menu or Dolphin?

[21:53] <NSaibot> context menu

[21:54] <seele> the plasma widget context menu?

[21:54] <NSaibot> uhmm, i guess, yes

[21:54] <leinir> Is this not again a question of shipping plasma locked?

[21:54] <leinir> (the same reasoning as shipping toolbars locked we discussed last time)

[21:54] <NSaibot> but i guess it'd make sense anywhere in kde to make primary actions more prominent, not?

[21:55] <notmart> NSaibot: still didn't understand more prominent where, context menus?

[21:55] <seele> NSaibot: what do you mean by more prominent? the related actions are at the top of the context menu

[21:55] <NSaibot> notmart: yes, in the context menu

[21:55] <seele> Open, which is probably the most common option, is first

[21:55] <seele> followed by empty, which is probably the second most common action

[21:56] <-- Sho_ has left this server (Remote closed the connection).

[21:56] <slougi> i think this makes sense in general. it's also something that makes sense in toolbars imo. for example in kmail's mail compose window the send mail button could be larger than the rest. (another pet peave of mine ;) this could be done for example by having text only for often used actions. of course, this makes less often used actions more obscure, and then there is the issue of deciding what the often used actions are.

[21:56] <slougi> (this was also discussed on kde-core-devel a few months back)

[21:56] <NSaibot> slougi: thanks for getting my point

[21:56] <seele> slougi: regarding options in the context menu or in the general UI?

[21:57] <slougi> seele: i don't have a strong opinion regarding this particular context menu, but i think this is a general point worth pursuing.

[21:57] <colomar> NSaibot: Do you mean like Windows does with the left-click action on tray icons' context menus, for example?

[21:57] <seele> colomar: vista or xp?

[21:58] <NSaibot> colomar: i think it'd make sense just anywhere in the kde UI, be it main menu or context menu

[21:58] <NSaibot> plasma or just any kde application

[21:58] <notmart> NSaibot: would just be the single one more prominent or an arbitrary number?

[21:58] <leinir> So you can mark a single action in a menu as "this one's the important one", and it gets marked as such?

[21:59] <leinir> or... what notmart said ;)

[21:59] <notmart> on windows is bold the default action that would be executed on mouseclick over the icon for instance

[21:59] <colomar> seele: I'm not sure but I think XP already had that

[21:59] <seele> leinir: ive seen it as the most common items might be in a bigger font and are the only ones with icons, or they are simply bolded so they stand out

[21:59] <NSaibot> notmart: primary actions, as in the example with the trash bin

[21:59] <notmart> colomar: iirk from win98

[21:59] <seele> colomar: xp bolds important context items, i wasnt sure if vista did something different

[21:59] <leinir> seele: Yeah, bold seems like an idea to me :)

[22:00] <NSaibot> if there are 2 or 3 usually used actions, emphasize them

[22:00] <notmart> NSaibot: like windows does the trash bin would have open, not empty as bold

[22:00] <seele> so i think the trash widget is simply an example, but this could be applied to both context menus and the menubar

[22:00] <NSaibot> seele: yes

[22:00] <seele> ok

[22:00] <notmart> for more than few actions usually the menu icons are used

[22:00] <-- Peter133 has left this server (Read error: 104 (Connection reset by peer)).

[22:00] <notmart> but then thay got inflationed

[22:01] <seele> and this has been discussed on the kde-core-devel mailing list recently?

[22:01] <notmart> in theory only a coulple of menu items should have an icon at least that was back in the days

[22:01] <seele> anyone have a link to the thread?

[22:01] <slougi> notmart: i agree that there is too much visual clutter currently.

[22:03] <NSaibot> making the height of the action entry bigger + some color difference would help a lot.

[22:03] <seele> so one proposal would be to use an icon to show important actions, but then that would mean removing a lot of the existing icons from the menu

[22:03] <seele> another proposal would be to simply bold the text to show importance

[22:03] <seele> another could be making that item appear larger (with larger font or something)

[22:03] <leinir> Hmm... One item with bold and icon, a few other items with icons, and the rest without icons

[22:03] <notmart> i wonder if qaction has any support for that, i doubt

[22:03] --> Peter133 ha entrat aquest canal ([email protected]).

[22:04] <slougi> how would this apply to toolbars? bold text there as well?

[22:04] <seele> it seems like several of you are interested in this issue. do you want to work together and prepare some examples of how to do this?

[22:04] <NSaibot> slougi: good point

[22:04] <seele> slougi: it would need to be consistent with how it is done in the menus so there is a match between the two elements

[22:04] <seele> or no change

[22:04] <slougi> i'd definitely like to. i've been meaning to work on some other general toolbar issues anyway.

[22:04] <seele> toolbars should already include only the most common/important functions

[22:05] <seele> so it may be unnecessary to mark the super important ones

[22:05] <NSaibot> seele: right

[22:05] <seele> for now, let's just address menus in the menubar and context menu

[22:05] <slougi> right

[22:05] <seele> there are several ways that importance can be shown

[22:05] <seele> some of them may conflict with the current practice of showing icons for all the menu items

[22:06] <notmart> in the plasma contect menu we would even have some technical issue to remove some icons :/

[22:06] <seele> notmart: we can worry about that after we find the best design solution. if the payoff of removing icons isn't worth it, we may need to use a different design solution

[22:07] <seele> for now, i think mocking up or coding the different ways it could be done will be helpful

[22:07] <seele> then we can revisit the issue and see which is better

[22:07] <slougi> who was interested in this issue?

[22:07] <notmart> seele: agree

[22:07] <seele> NSaibot: this was your issue, do you want to take the lead and either come up with the different screenshots and maybe work with whoever else is interested?

[22:08] <NSaibot> seele: i'm a mere user, no idea. i think i could come up with a small mock up

[22:08] <seele> ok. notmart, leinir, both of you seem interested in this issue

[22:08] <seele> did either of you want to work with NSaibot on this?

[22:09] <leinir> i can't dedicate much time to it over the next couple of months, i'm afraid, uni is lethal at the moment :)

[22:09] <notmart> cough cough :9

[22:09] <leinir> it's all i can do to find the time for this meeting ;)

[22:09] <leinir> Otherwise i'd love to

[22:09] <seele> ok..

[22:09] <slougi> well, i suppose i could help

[22:09] <-- Peter133 has left this server (Connection reset by peer).

[22:10] <seele> NSaibot: if you can come up with some mockups, even if they aren't realistic, it could help with further discussion

[22:10] <leinir> i can find an hour here and there, but not really plan ahead

[22:10] <seele> slougi: that would be great

[22:10] <leinir> But yes - email collaboration for this could work :)

[22:10] <seele> i'll let whoever is interested coordinate with NSaibot

[22:10] <NSaibot> seele: alright, i'll do my best

[22:10] <slougi> NSaibot: you think you could send me an e-mail with more detailed thoughts?

[22:10] <leinir> NSaibot: Are you on kde-usability's mailing list? :)

[22:10] <NSaibot> leinir: nope

[22:10] <NSaibot> slougi: yea, why not. the preferred language?

[22:11] <seele> ok.. on to a new agenda item

[22:11] <slougi> NSaibot: english or finnish :)

[22:11] <notmart> i can think about techical issues on this, especially on the plasa side, because i'm a bit clueless about the rest...

[22:11] <seele> does anyone else have a bug to discuss? otherwise i will start picking them from the list

[22:11] <leinir> NSaibot: If you can get on there, let's use that for communication - that way we'd be a potentially larger team working on it :)

[22:11] <NSaibot> leinir: alright

[22:11] <slougi> i agree with discussing things on kde-usability

[22:12] <seele> ok.. no one else has a meeting agenda item?

[22:12] <seele> let's start picking from the list then

[22:13] <notmart> seele: i hink no, i did a quick search on bugzilla on plasma usability issues and i just found one really interesting, but it's in the rocess of being addressed so i think it will be easier

[22:13] <notmart> since is on the systray notification stuff

[22:13] <seele> notmart: ok

[22:13] <adymo> may i propose a short break from usability bugs to make a announcement?

[22:14] <seele> adymo: sure go for it

[22:14] <adymo> does anyone who is interested in usability wants to come to the next kdevelop team meeting an work on usability with us (couple of days or the whole week)

[22:14] <colomar> When is it?

[22:15] --> PeterMG ha entrat aquest canal ([email protected]).

[22:15] <adymo> we historically paid too little attention to usability and it would be great to change that

[22:15] <adymo> it's 19th-25 April, Mykolayiv, Ukraine

[22:15] <adymo> more is here: http://lists.kde.org/?l=kdevelop-devel&m=122739410808024&w=2

[22:15] <leinir> adymo: i'd absolutely love to go, but unfortunately can't :/

[22:16] <leinir> (hence my lack of reply on the mail what got sent around)

[22:16] <agateau> adymo: can't come, sorry

[22:17] <seele> ok, anyone interested, please contact adymo

[22:17] <seele> adymo: thanks

[22:17] <seele> let's see here.. next bug

[22:17] <seele> https://bugs.kde.org/show_bug.cgi?id=168060

[22:17] <seele> Konqueror's "save password" dialog is unintuitive

[22:17] <seele> oh, i think someone is already working on this. i've seen screenshots recently

[22:18] <-- zanoi_ has left this server (Remote closed the connection).

[22:18] <leinir> Yes, it definitely doesn't have yes/no/cancel for me any longer

[22:18] <leinir> (just switched distributions, though, so wether it's a 4.2 thing or an opensuse thing, i don't know)

[22:18] <-- dotancohen has left this server (Remote closed the connection).

[22:19] <seele> oh missed one

[22:19] <seele> http://bugs.kde.org/show_bug.cgi?id=154564

[22:19] <seele> Keyboard's "Super" key doesn't launch Kmenu

[22:19] <NSaibot> furthermore, you have to decide if you want to save the password, even before you realise that you have a typo in your password

[22:19] <seele> i think there was an issue that there can't be single key shortcuts?

[22:19] <notmart> this one is really tricky to do

[22:19] <seele> notmart: do you know if anyone is working on this?

[22:20] <leinir> seele: Yes - thing is it /used/ to be possible, way, way back in the day (think early 3 series or somesuch, 3.2 or so)

[22:20] <notmart> problem is also that supoer is a modifier, so juat an half scancode

[22:20] --> zanoi_ ha entrat aquest canal ([email protected]).

[22:20] <notmart> seele: i remember we talked about it at tokamak but i think it's dead there

[22:20] <slougi> leinir: reading the bug report, i think that was a kicker specific hack

[22:20] <leinir> slougi: Right :)

[22:21] <leinir> So... if nothing else, at least it's possible :)

[22:21] <leinir> Hack or not ;)

[22:21] <pinotree> Super can be either a normal key, or a modifier

[22:21] <notmart> leinir: iirc was remapping the key as f13 so the modifier ability was lost?

[22:21] <leinir> pinotree: Right... Xorg thing?

[22:21] <notmart> or was a more functional thing?

[22:21] <pinotree> yes

[22:22] <pinotree> you can chane its behaviour by tweaking the keyboard layout (don't ask me how, though)

[22:22] <slougi> you can remap it with xmodmap

[22:22] <slougi> anyway, that's beside the point

[22:22] <notmart> on windows iirc is the keyboard driver itself that inject the second half of the scancode if no other key is pressed together in x milliseconds

[22:22] <notmart> quite an hack

[22:22] <notmart> but dunno the details

[22:23] <seele> what dev group would be responsible for fixing something like this? anyone? kwin? plasma?

[22:23] <slougi> iirc there is a module option on linux for the hid module to do something similar.... but i think we should discuss design, not implementation

[22:23] <seele> distros?

[22:23] <slougi> it depends on what part of the stack you want it fixed

[22:23] <seele> mmm. too technical for me. what is the happy solution and what is the hack?

[22:24] <slougi> i'm not sure, if you're asking me :)

[22:24] <seele> plasma would do the hack like they did in 3? who would fix the root of the problem? is that an x11 issue?

[22:24] <notmart> me neither

[22:24] <seele> ok.. how about this

[22:24] <seele> it is a good idea

[22:24] <seele> what if we find a hack solution

[22:25] <seele> that way, when someone says "hey this is a hack, you should fix it this way"

[22:25] <seele> then they can fix it

[22:25] <seele> but between the time of the hack and the real solution

[22:25] <notmart> plasma is a bit high in the stack to do such a thing i think

[22:25] <seele> we still get the happy menu shortcut key working

[22:25] <notmart> wonder if someone still mantains kxkb stuff

[22:25] <seele> notmart: what would be lower and a better place to fix it at?

[22:25] <slougi> right. i think it can be fixed in kde shortcuts code. you do get the modifier straight away, as it is shown in the dialog.

[22:26] <slougi> for example, go to any reconfigure shortcuts dialog, and start reconfiguring any shortcut. press a modifier key -> it is shown, but unless you press another key the config is aborted.

[22:26] <leinir> A very good point

[22:27] <notmart> ok, so where is in kdelibs the shortcut handling code?

[22:28] <slougi> i'm not sure, it's not something i have ever played with. i presume somewhere in kdeui, since it does tie in with [K/Q]Action

[22:28] <tsdgeos> notmart: adryij (spelling) does, see he's latest post to k-c-d

[22:28] <agateau> notmart: in kdeui you have KGlobalAccel and co

[22:29] <tsdgeos> notmart: kshortcutsdialog.cpp in kdeui/dialogs

[22:30] <leinir> This is also something a friend mentioned the other day - because of how this works, you cannot do a simple key-press to pull up your prefferred krunner ui

[22:31] <slougi> except for special buttons like XF86Tool etc. i wonder if those are special cased somehow.

[22:32] <seele> is there a particular maintainer for kshortcutdialog.cpp or any core dev?

[22:32] <seele> who can we contact to learn more if this is the right place to fix it?

[22:34] <tsdgeos> mjansen i'd say

[22:34] <seele> is that his irc nick?

[22:34] <tsdgeos> yeah

[22:34] <seele> ok

[22:35] <seele> alright, so we've gone for an hour and a half

[22:35] <seele> do you want to try and discuss one more bug or do you want to call it a day?

[22:35] <PeterMG> one more

[22:35] <leinir> How about number 2? ;)

[22:36] <leinir> Quick discussion on that one: 1+ ;)

[22:36] <seele> #2 # Dolphin/Konqueror: Select/enter newly created folder/file (Bug 155706)

[22:36] <seele> http://bugs.kde.org/show_bug.cgi?id=155706

[22:36] <seele> leinir: that one?

[22:36] <slougi> i might have some input on that in a month or so :)

[22:36] <leinir> seele: Yes :)

[22:36] <seele> leinir: are you also volunteering to describe the issue? :)

[22:36] <leinir> Sure :)

[22:37] <seele> ok go for it

[22:38] <leinir> It's fairly straight forward: Presumably, once you have created a new directory, you wish to continue working on that directory in one way or another. So you have two options: Either you enter the directory immediately, or you select the directory inside the current directory (that is, highlight but don't navigate)

[22:38] <leinir> The reasoning behind the first would be to minimize the amount of actions required to continue the work on that directory

[22:39] <leinir> The reasoning behind the second would be to minimize the amount of work required to continue work in the current directory (if, for example, you wish to create another directory in the same directory as the previous)

[22:39] <seele> leinir: so this would be in both the file dialog and dolphin, or just one of them?

[22:39] <leinir> Both

[22:39] <seele> in the file dialog i think this makes sense, i havent thought about it in dolphin though

[22:39] <seele> everyone: thoughts? any cons to automatically entering a new directory in dolphin?

[22:39] <agateau> I believe 2nd is better: because of this usecase: I am in a folder with a.txt and b.txt, I create a folder and want to move a.txt in it

[22:40] <leinir> agateau: Yes, i believe that is the better as well :)

[22:40] <agateau> with 1st solution I would need to go up

[22:40] <adymo> agree with agateau

[22:40] <slougi> i don't see any drawback. one area where i see a big improvement is in large folders with lots of entries.

[22:40] <leinir> There's more use cases, and to achieve the 1st one you only have to press enter (or click) :)

[22:40] <agateau> that's

[22:40] <agateau> it

[22:40] <seele> yes, i think the file management behavior in dolphin would be different than in the file menu

[22:40] <seele> usually in dolphin you will be organizing

[22:41] <seele> but in the file dialog, you are probably creating a directory as part of your task, and so entering it automatically makes sense in that case

[22:41] <agateau> I agree

[22:41] <PeterMG> Well entering an empty folder doesn't really makes sense, does it?

[22:42] <leinir> seele: A good point... But it would suddenly render the file dialogue empty, where it was previously (most likely) full of, well, stuff :)

[22:42] <seele> so maybe the option makes sense in the file dialog? but in dolphin i think it will create unnecessary steps and hinder dnd

[22:42] <slougi> PeterMG: why not? for the save dialog?

[22:42] <seele> PeterMG: if you create a new folder while you are in a file save dialog, you most likely want to navigate to that folder afterwards

[22:42] <leinir> Wether or not this confusion is real or just an idea on my end i don't know, but... i think it might actually be a problem :)

[22:42] <PeterMG> slougi: true

[22:42] <seele> PeterMG: unless you can think of other usecases

[22:42] <colomar> leinir: I don't think that would be too much of a problem since the breadcrumb shows that you are in the new dircetory

[22:43] <leinir> colomar: True, but the two areas aren't entirely connected... though that in itself could be considered a problem, not one on the topic for tonight, really :)

[22:43] <slougi> i have some empirical evidence which suggests that at least new users have no idea what the breadcrumbs do

[22:43] <-- PeterMG has left this server (Read error: 104 (Connection reset by peer)).

[22:45] <leinir> slougi: i think it might be interesting to find out how quickly they pick it up, though...

[22:45] <agateau> I rely on the fact that the file dialog automatically enters a folder I created (and curse against windows for not doing the same) :)

[22:45] <agateau> slougi: I guess they may not look clickable enough

[22:45] <slougi> leinir: definitely. i'm currently doing a usability study for dolphin with new users for university course work - but that's out of the scope...

[22:45] <seele> ok.. so to separate the issues a little so we dont go in circles

[22:45] <slougi> yeah sorry for that

[22:46] <seele> in dolphin, you should no automatically go in to a new directory you create. there are many reasons why that would not be good

[22:46] <seele> so, what we are currently discussing is the creation of a new folder in the file dialog

[22:46] <leinir> Hmm... in file dialogues, i'm a bit ambivalent about it really :)

[22:46] --> PeterMG ha entrat aquest canal ([email protected]).

[22:46] <slougi> seele: specifically the save file dialog i think

[22:46] <seele> the primary use case would be saving a file, creating a new directory to put your file in

[22:46] <seele> slougi: yes

[22:46] <leinir> There's arguments for both sides, but yeah, arguably the enter-dir-on-create option is the more productive :)

[22:47] <seele> i think it makes a lot of sense that for that use case to enter the new directory. the majority of the time youre going to enter it

[22:47] <seele> also, if you are in a large folder, you will waste time trying to find your new folder in the mess of folders and files (depending on how your sort your lists)

[22:47] <leinir> Yeah

[22:47] <seele> there is the possibility that users may be confused by automatically entering the folder

[22:47] <sreich> well, it could focus to that folder

[22:47] <seele> but i think that the behavior can be learned

[22:47] <sreich> so I think that is a different case

[22:47] <sreich> <back>

[22:48] <seele> because the name of the new folder will be in the dialog

[22:48] <leinir> Well, select or enter is the options, really, so the question is wether or not entering the new (empty) directory is confusing :)

[22:48] <seele> and most of the time it will be where they wanted to be

[22:48] <sreich> yes it is

[22:48] <colomar> Just to be sure: Did the bug really mean "enter" by "select"? Or would it mabye make sense to select the folder in dolphin without actually entering it?

[22:48] <leinir> But yeah, it would make fair sense to suspect that anybody who actually knows how to create a new directory also knows that the breadcrumbs is showing the directory structure :)

[22:48] <sreich> I think I would be confused as to what it did

[22:48] <seele> leinir: select as in give it keyboard focus?

[22:48] <PeterMG> There is the other situation, you may want to create a dir structure and then populate it later, but I think Leinir's <enter> <shift>-<enter> works

[22:48] <leinir> colomar: No, select means select :)

[22:49] <agateau> I haven't heard about much people complaining about the enter-on-create feature of the file dialog

[22:49] <slougi> colomar: i think the current idea is that in dolphin it should be selected only. the current discussion is about the file save dialog.

[22:49] <seele> agateau: i think firefox does it in it's dialog as well

[22:49] <leinir> seele: In this case, i believe so - select, as in highlight for input :)

[22:49] <sreich> You should select the folder, and scroll down to where it is

[22:49] <sreich> slougi: hm

[22:49] <sreich> i see

[22:49] <agateau> seele: and kde has been doing it since kde3 maybe even kde2

[22:50] <sreich> what uses enter-on-create?

[22:50] <agateau> sreich: kde file dialog

[22:50] <slougi> really?

[22:50] <agateau> yes

[22:50] <leinir> Right - if that is the case, we should definitely still be doing that

[22:50] <sreich> ah, yeah

[22:50] <sreich> but that makes sense there

[22:50] <sreich> you -have- to create a file

[22:50] <seele> leinir: and you want to change it to just selecting, not entering?

[22:51] <sreich> whereas dolphin, you could be iterating, creating folders in a root dir

[22:51] <leinir> both make sense, but if we've got a history that that's what happens, then... :)

[22:51] <seele> somehow i feel like we're discussing a problem that is already fixed

[22:51] <leinir> seele: Not in the file dialogue, no - not after this discussion :)

[22:51] <sreich> I mean in a file save dialog, it isn't like you can do much else other than saving

[22:51] <agateau> sreich: exactly, that's why selecting only in dolphin is a better solution than automatically entering

[22:51] <agateau> imo

[22:51] <sreich> it's not like you should suddenly decide to rearrange your entire home folder via just the file dialog

[22:51] <sreich> agateau: yes

[22:51] <sreich> but what about the open dialog?

[22:52] <leinir> open dialogue is read-only, isn't it?

[22:52] <sreich> you are opening files... thusly when you create a directory, it is empty

[22:52] <sreich> leinir: what do you mean?

[22:52] <agateau> i personally believe there should not be a create folder button in the open dialog

[22:52] <slougi> the open dialog does enter automatically as well...

[22:52] <sreich> I disagree, you may want to move a file into another

[22:52] <sreich> *another directory

[22:53] <seele> sreich: but we shouldnt be designing to support an activity that doesnt make sense

[22:53] <agateau> mmm, that's not the intent of the open dialog, is it?

[22:53] <sreich> seele: why is it that it does not make sense

[22:53] <slougi> agateau: i agree

[22:53] <seele> just because you *can* manage files in the file dialog doesnt mean we should optimize the file dialog to do so

[22:53] <sreich> agateau: yes, but it is some problem, I think, that you could run into

[22:53] <sreich> oh wait...

[22:53] <sreich> lemme think this over more thoroughly :)

[22:54] <agateau> be careful, I may take my file dialog mockups from outside there dusty folder :)

[22:54] <sreich> well the only usage scenario would be if you had an already existing file which was ill-placed, and the dir structure ill-thought-out

[22:54] <agateau> we aren't going to bed soon if we go this way

[22:55] <sreich> which I think that is a rare situation, so in conclusion, I think that this should be removed from open file dialog only

[22:55] <sreich> the new folder, that is

[22:55] <sreich> in the rare event that you have to do this, you can open up dolphin easily

[22:55] <agateau> that's it

[22:55] <colomar> +1

[22:55] <seele> yes

[22:56] <sreich> ok, so back to the enter vs. selection problem?

[22:56] <seele> dolphin: select

[22:56] <seele> file save: open

[22:56] <seele> file open: ... ?

[22:56] <leinir> 1+

[22:57] <seele> currently it opens, correct?

[22:57] <agateau> seele: yes

[22:57] <sreich> yes, which wouldn't make sense altogether

[22:57] <seele> and i think we just discussed that it should select?

[22:57] <sreich> but the whole idea makes no sense to me...

[22:57] <agateau> it's the same code as in save

[22:57] <seele> so the only one that opens is file save?

[22:57] <seele> ah

[22:57] <sreich> yeah, it makes sense in file save only i think

[22:57] <slougi> file open dialog currently also enters any created directory, which doesn't make sense imo

[22:57] <seele> will it be a pain to extend it to have different functionality or is it easy?

[22:58] <sreich> slougi: no, I think that does actually

[22:58] <sreich> seele: what functionality is that?

[22:58] <agateau> it should be rather easy, but i believe it would be even easier to hide the create folder action in open mode :->

[22:58] <sreich> slougi: you are saving a PNG file... you want to create a folder named "My random pics", which is where this file would lie

[22:58] <sreich> You create it, it enters folder, you click save

[22:58] <slougi> sreich: it doesn't make sense for the _open_ file dialog

[22:58] <sreich> it's a fluid motion I think

[22:59] <sreich> slougi: yes, not at all

[22:59] <slougi> which is what i said ;)

[22:59] <leinir> agateau: i'm liking that idea :)

[22:59] <sreich> well... since we decided(?) to remove the new folder altogether from open dialog... this sectino of the topic is nil

[22:59] <seele> sreich: we are talking about the file open dialog

[22:59] <sreich> in that aspect

[22:59] <slougi> +1 on removing create folder from the open file dialog

[22:59] <sreich> +1

[22:59] <colomar> +1

[22:59] <leinir> +1

[22:59] <seele> who maintains the file dialog?

[23:00] <sreich> i dunno, i was doing some work on it lately

[23:00] <sreich> on all of them actually

[23:00] <sreich> iirc

[23:00] <agateau> i believe erselibre worked a lot on it

[23:00] <seele> ok, so the resolution is to remove the new folder functionality from file open?

[23:00] <agateau> *ereslibre

[23:01] <sreich> thought it was dfaure....

[23:01] * sreich looks

[23:01] <agateau> seele: fine with me

[23:01] <sreich> seele: yes

[23:01] <sreich> then we do not have to worry about enter vs select problems in here ;)

[23:01] <agateau> dfaure is the meta-maintainer, he maintains the whole kdelibs :)

[23:01] <seele> ok.. sreichsince you've worked with this dialog before do you want to take this?

[23:01] <sreich> agateau: :)

[23:02] <seele> i would also contact dfaure first and discuss it with him. changing a default is much different from removing functionality

[23:02] <sreich> seele: sure, gladly

[23:02] <seele> sreich: awesome

[23:02] <seele> ok everyone, that was the last one

[23:02] <seele> and it was a very productive meeting

[23:03] <seele> the meeting notes are here: http://techbase.kde.org/Projects/Usability/Meetings/2009March18

[23:03] <sreich> too bad I missed most of it :(

[23:03] <slougi> thanks all =)

[23:03] * sreich scrolls up to see what he missed

[23:03] <seele> tsdgeos: if you could add the logs at the bottom of that page, that would be helpful

[23:03] <seele> sreich: hopefully there will be a log soon

[23:03] <tsdgeos> seele: i'm on it

[23:03] <sreich> seele: wait...

[23:03] <tsdgeos> are we done totally?

[23:03] <seele> the next meeting will probably be on a weekend day in august

[23:03] <sreich> the save file dialog , upon folder creation...

[23:03] <seele> tsdgeos: i think so, we've gone for two hours :)