1 **** BEGIN LOGGING AT Fri Feb 17 17:20:12 2006
   2 
   3 Feb 17 17:20:45 *	calum does his usual quick keynav and theming check...
   4 Feb 17 17:22:04 <calum>	keynav mostly good, except focus gets stuck in the ">>>" field in the python console, and I can't even get out with Ctrl-Tab... (sorry, I know that's not in the screenshot though :)
   5 Feb 17 17:22:04 <pbor>	(this time around emacs keybinds should actually work for the three people that care)
   6 Feb 17 17:22:08 <calum>	cool
   7 Feb 17 17:22:28 <pbor>	yeah, the python console is not great
   8 Feb 17 17:22:39 <pbor>	it's just the epiphany one ported
   9 Feb 17 17:22:57 <pbor>	we were thinking of maybe disabling it
  10 Feb 17 17:23:02 <calum>	heh, ok...
  11 Feb 17 17:23:19 <calum>	everything looks great in high contrast themes though, good...
  12 Feb 17 17:23:42 <calum>	any other comments on main window before we move onto more specific stuff?
  13 Feb 17 17:24:17 <pbor>	the only other change is that tabs are now reorderable by DnD, should be ok since epi does the same
  14 Feb 17 17:24:52 <calum>	cool... is there any way to do that from the keyboard?
  15 Feb 17 17:25:14 <pbor>	mmm... good point
  16 Feb 17 17:25:19 <pbor>	I fear no
  17 Feb 17 17:25:44 <calum>	well, wouldn't worry about it too much... probably something the HIG/a11y folk need to think about and make a recommendation anyway...
  18 Feb 17 17:26:15 <pbor>	yes, also because it's one of the things that will be soon moved in GtkNotebook itself
  19 Feb 17 17:26:24 <calum>	right
  20 Feb 17 17:26:42 *	calum thinks we could probably just adapt the keynav spec for re-ordering table column headers
  21 Feb 17 17:27:04 <calum>	think we suggested Ctrl+arrow keys for that or something, when the header itself had focus
  22 Feb 17 17:27:06 <pbor>	sounds good
  23 Feb 17 17:27:28 <calum>	or we could just add "move left/right" menu items to the Documents menu or something too...
  24 Feb 17 17:28:00 <calum>	(especially as I see there's already a Move to New Window item there...)
  25 Feb 17 17:28:28 <pbor>	yep, though it would make that menu grow a bit
  26 Feb 17 17:28:45 <pbor>	(it can be quite long when there are a few docs open)
  27 Feb 17 17:29:08 <calum>	true... do you have a limit on how many docs can be shown on the menu?
  28 Feb 17 17:29:25 <pbor>	I guess that if we add them there we should also add them to the right-click menu on the tab
  29 Feb 17 17:29:38 <calum>	yes, that would be good too
  30 Feb 17 17:29:43 <pbor>	no, no limit... should we put one?
  31 Feb 17 17:31:30 <calum>	not necessarily, just wondered...  I've seen some apps start to use submenus when the list gets very long, so you get the first ten docs, then a submenu containing the next 10 etc... but the HIG doesn't really say anything specific about that...
  32 Feb 17 17:31:53 <calum>	not sure the submenu thing really solves the problem anyway
  33 Feb 17 17:32:02 <calum>	just makes the top level a bit tidier
  34 Feb 17 17:32:12 <pbor>	yeah... sounds like a bit of a corner case
  35 Feb 17 17:33:24 <pbor>	also because you could end up with the current doc not visible in the menu
  36 Feb 17 17:33:34 <calum>	yes. true...
  37 Feb 17 17:34:08 <calum>	I suppose you could make sure the current doc was always top of the list or something, but that would probably start causing other problems :)
  38 Feb 17 17:34:25 <pbor>	yes, it would break keyboard
  39 Feb 17 17:34:46 <pbor>	the first ten docs are reachable with alt+1,2,3...
  40 Feb 17 17:35:11 <calum>	right
  41 Feb 17 17:35:32 <calum>	ok, so let's not mess about with that :)
  42 Feb 17 17:35:38 <pbor>	:)
  43 Feb 17 17:35:43 <calum>	while we're talking about menus, we might as well have a look at http://gnome.org/~pborelli/ui-review/view-menu.png
  44 Feb 17 17:36:19 <pbor>	ok
  45 Feb 17 17:36:41 <pbor>	with respect to previous gedit we ditched the toolbar style submenu
  46 Feb 17 17:36:43 *	joachim (~joachim@ACD61A30.ipt.aol.com) has joined #ui-review
  47 Feb 17 17:36:51 <pbor>	I guess no one will cry for that ;)
  48 Feb 17 17:36:59 <calum>	hi joachim ... just having a look at ok, so while we're talking about menus, we might as well have a look at http://gnome.org/~pborelli/ui-review/view-menu.png
  49 Feb 17 17:37:03 <calum>	oops :)
  50 Feb 17 17:37:13 <calum>	too much clipboard there :)
  51 Feb 17 17:37:18 <calum>	we're just having a look at http://gnome.org/~pborelli/ui-review/view-menu.png
  52 Feb 17 17:37:25 <calum>	pbor: heh
  53 Feb 17 17:37:39 <joachim>	is gedit 2.13.90 ok?
  54 Feb 17 17:37:44 <pbor>	the main issue is the pane vs panel terminology
  55 Feb 17 17:37:47 <pbor>	joachim: sure
  56 Feb 17 17:38:22 *	joachim checks the style guide...
  57 Feb 17 17:38:32 <pbor>	nautilus uses side pane
  58 Feb 17 17:38:50 <joachim>	style guide says "pane"
  59 Feb 17 17:38:58 <pbor>	though bottom pane sounded weird to our non-english ears
  60 Feb 17 17:39:01 <joachim>	we should perhaps save 'panel' for the panels
  61 Feb 17 17:39:07 <calum>	right... well, to be honest, I don't think there's anything wrong with "bottom pane" (which I think is what the styleguide would recommend)... I guess the only question is whether we could have a more functional term than "bottom"...
  62 Feb 17 17:39:27 <joachim>	bottom pane is greyed out on mine... what is it?
  63 Feb 17 17:39:33 <calum>	or can the bottom pane be used so generically that "bottom" is the best we can do...
  64 Feb 17 17:39:39 <calum>	joachim: enable all your plugins
  65 Feb 17 17:39:57 <pbor>	well, the fact is that a plugin can pretty much put what he wants there
  66 Feb 17 17:40:06 <calum>	ok
  67 Feb 17 17:40:16 <joachim>	"plugin pane"?
  68 Feb 17 17:40:34 <calum>	I thought that too, but plugins can use the side pane too, right?
  69 Feb 17 17:40:34 <pbor>	plugin can also put stuff in the side pane
  70 Feb 17 17:40:39 <joachim>	ah
  71 Feb 17 17:40:44 <joachim>	rats
  72 Feb 17 17:41:00 <pbor>	beside I don't see a reson to expose the plugin implementation detail
  73 Feb 17 17:41:06 <calum>	right
  74 Feb 17 17:41:51 <joachim>	'bottom pane' sounds ok to me, & I'm a native english speaker
  75 Feb 17 17:42:12 *	calum agrees
  76 Feb 17 17:42:13 <pbor>	ok, so unless someone comes up with something better we should go with "bottom panel" -> "bottom pane"
  77 Feb 17 17:42:20 <calum>	yep
  78 Feb 17 17:42:24 <pbor>	okay
  79 Feb 17 17:43:05 <joachim>	(aside) Replace should be CTRL-H, not R
  80 Feb 17 17:43:27 <pbor>	why, it has been ctrl+R for ages
  81 Feb 17 17:43:29 <pbor>	?
  82 Feb 17 17:43:36 <joachim>	HIG
  83 Feb 17 17:43:50 <pbor>	mmm
  84 Feb 17 17:44:00 <joachim>	I mean, you don't have to get rid of R
  85 Feb 17 17:44:04 *	pbor wonders why this didn't come up before
  86 Feb 17 17:44:14 *	joachim thought he'd filed a bug
  87 Feb 17 17:44:15 <calum>	maybe nobody uses Replace :)
  88 Feb 17 17:44:19 <joachim>	but it could have been another app
  89 Feb 17 17:44:42 <pbor>	calum: I mean in previous ui review... ctrl+R has been there from the 2.0 days and before
  90 Feb 17 17:45:24 <calum>	pbor: yeah, I've a feeling we've discussed it before, but I don't recall if there was a reason we didn't suggest changing it...
  91 Feb 17 17:45:32 <calum>	(maybe something else used to use Ctrl+H?)
  92 Feb 17 17:45:41 *	calum checks old ui-review notes
  93 Feb 17 17:46:07 *	joachim checks for the \n selection bug
  94 Feb 17 17:46:30 <pbor>	joachim: what is that?
  95 Feb 17 17:46:35 <joachim>	it's not gedit, it's GTK
  96 Feb 17 17:46:42 <pbor>	ah, right
  97 Feb 17 17:46:53 <joachim>	but it makes working with source a PITA
  98 Feb 17 17:47:05 <joachim>	I end up chasing stray newlines
  99 Feb 17 17:47:36 <pbor>	joachim: can you cc me if you find the bug?
 100 Feb 17 17:47:41 <joachim>	yup
 101 Feb 17 17:47:45 <pbor>	great
 102 Feb 17 17:47:50 <joachim>	http://bugzilla.gnome.org/show_bug.cgi?id=323886
 103 Feb 17 17:48:17 <joachim>	what's your email?
 104 Feb 17 17:48:52 <pbor>	I am already on CC apparently
 105 Feb 17 17:48:56 <joachim>	cool
 106 Feb 17 17:49:40 <calum>	hmm, weird, can't find any mention of Ctrl-R/H thing at all :)
 107 Feb 17 17:49:59 <calum>	maybe we've all been blind all these years...
 108 Feb 17 17:50:25 <pbor>	who uses ctrl+H for replace out of curiosity?
 109 Feb 17 17:50:50 *	pbor woders if it would be less painful chaninging the HIG :P
 110 Feb 17 17:50:51 *	jessevd|food always uses Ctrl+R
 111 Feb 17 17:51:01 *	calum tries to think of another GNOME app that allows Replace...
 112 Feb 17 17:51:18 <joachim>	bluefish
 113 Feb 17 17:51:32 <calum>	HIG has Ctrl+R for Reload/Refresh IIRC, so we'd need to change all the apps that used that...
 114 Feb 17 17:52:18 <joachim>	SciTE
 115 Feb 17 17:52:18 <calum>	or the other option, as mpt and others often point out, is just to offer Replace automatically in every Find dialog...
 116 Feb 17 17:52:31 <calum>	then you don't need a separate shortcut :)
 117 Feb 17 17:52:59 <pbor>	that would actually be ok with me
 118 Feb 17 17:53:01 <joachim>	yeah. I think a common find dialog might be a good thing to think about one day
 119 Feb 17 17:53:34 <pbor>	speaking of find
 120 Feb 17 17:53:54 <pbor>	what you guys think of the match highlighting?
 121 Feb 17 17:54:17 <pbor>	unfortunately it's not easily themable
 122 Feb 17 17:54:19 <joachim>	all terms in yellow? nice!
 123 Feb 17 17:54:34 <pbor>	until gtk gets support for symbolic colors
 124 Feb 17 17:54:35 <joachim>	but how do I clear it?
 125 Feb 17 17:54:47 <calum>	heh, I was just wondering that :)
 126 Feb 17 17:54:48 <pbor>	joachim: ctrl+shift+K
 127 Feb 17 17:55:00 <calum>	is that option on the menus anywhere?
 128 Feb 17 17:55:01 <pbor>	yeah, that's what I wanted to ask :)
 129 Feb 17 17:55:03 <joachim>	no menu item?
 130 Feb 17 17:55:09 <kikidonk>	i don't know if it's a gedit or gtk problem, but <tab> in the save dialog filename entry doesn't focus the folderchooser button
 131 Feb 17 17:55:23 <joachim>	Could you add Search -> Clear highlight ?
 132 Feb 17 17:55:32 <calum>	sounds good to me...
 133 Feb 17 17:55:42 <pbor>	yes, that's a possibility
 134 Feb 17 17:56:09 <calum>	kikidonk: hmm, you're right... you can use Ctrl-Tab though, at least...
 135 Feb 17 17:56:14 <pbor>	the other possibility would be to clear the hl when closing the dialog
 136 Feb 17 17:56:44 <pbor>	but it would make the hl less useful if one wants to keep stuff highlighted
 137 Feb 17 17:56:48 <calum>	yeah... I wonder if there's much point in having the highlight at all if you're going to do that...
 138 Feb 17 17:56:56 <pbor>	indee
 139 Feb 17 17:56:57 <pbor>	+d
 140 Feb 17 17:57:09 <zwnj>	prob: OT, but would you test the print preview in an RTL locale?
 141 Feb 17 17:57:30 <pbor>	zwnj: yeah... we'll get to the print preview in a bit :)
 142 Feb 17 17:57:37 *	pbor wants to finish up search
 143 Feb 17 17:57:51 <pbor>	so, this brings me to the new incremental searching
 144 Feb 17 17:57:52 <joachim>	there's no news on a stock Open Recent menu item is there?
 145 Feb 17 17:57:54 <zwnj>	pbor: so the search panel for now :D
 146 Feb 17 17:58:31 <pbor>	joachim: recent stuff will be reworked as part of project ridley
 147 Feb 17 17:58:37 <joachim>	right
 148 Feb 17 17:58:49 <pbor>	the new incremental searching is triggered with ctrl+K
 149 Feb 17 17:58:53 *	hav0x (~hav0x@bl5-215-157.dsl.telepac.pt) has joined #ui-review
 150 Feb 17 17:59:09 *	calum suspects that should be on the Search menu too
 151 Feb 17 17:59:15 <pbor>	http://gnome.org/~pborelli/screenshot
 152 Feb 17 17:59:30 <pbor>	the reasoning is that it's an advanced feature
 153 Feb 17 17:59:45 <joachim>	404
 154 Feb 17 18:00:00 <pbor>	and we don't want people to thing upfront "Should I search this way or that other way?"
 155 Feb 17 18:00:00 <calum>	true, but advanced stuff shouldn't be completely invisible, just harder to find :)
 156 Feb 17 18:00:25 *	calum tries to think of a better idea
 157 Feb 17 18:00:26 <pbor>	what would be a good menu item?
 158 Feb 17 18:00:48 <pbor>	also, for casual users the find dialog suffices
 159 Feb 17 18:01:04 <calum>	oh yes, wouldn't argue with that
 160 Feb 17 18:01:28 <pbor>	the incremental one is useful only with "hands on the keyboard"
 161 Feb 17 18:02:20 <calum>	I dunno what you'd call it, really... "Typeahead Search", "Incremental Search"... *shrug*
 162 Feb 17 18:02:28 <calum>	or you could just put the search box on the toolbar and not call it anything :)
 163 Feb 17 18:02:44 <joachim>	how do you start that?
 164 Feb 17 18:02:51 <pbor>	ctrl+K
 165 Feb 17 18:03:13 <calum>	is there any way to cycle through matches, or are you stuck with the first  one?
 166 Feb 17 18:03:21 <joachim>	ah. the popup pops up in a funny place
 167 Feb 17 18:03:28 <pbor>	calum: up/down arrows
 168 Feb 17 18:03:41 <pbor>	calum: and the mouse scroll wheel
 169 Feb 17 18:03:44 <calum>	pbor: that drops down the history list for me...
 170 Feb 17 18:03:58 <joachim>	it half covers the tab
 171 Feb 17 18:04:23 <pbor>	calum: yes... that's unfortunate: actually I think we should kill the history
 172 Feb 17 18:05:06 <pbor>	joachim: is that a problem?
 173 Feb 17 18:05:12 <pbor>	it was done on purpose
 174 Feb 17 18:05:23 <joachim>	it's not a prob, but it looks a little odd
 175 Feb 17 18:06:31 <joachim>	I see you've done it so it's flush with the bottom of the document title
 176 Feb 17 18:06:49 <calum>	yeah... more likely to obscure a match there than if it was at the bottom-right of the document, I suspect (or bottom-left for RTL text)
 177 Feb 17 18:07:05 <joachim>	but it obscures the corner of the tab's icon
 178 Feb 17 18:07:51 <pbor>	calum: it would obscure a match only if the match was in the first line of the doc and in that case you usually do not need to search :)
 179 Feb 17 18:07:54 <joachim>	I'd nudge it to the right a bit. But it's not a major concern. You'll just get bug reports ;)
 180 Feb 17 18:08:02 <pbor>	calum: in the others cases text gets scrolled
 181 Feb 17 18:08:14 *	charles (~charles@nat.nssl.noaa.gov) has joined #ui-review
 182 Feb 17 18:08:15 <calum>	pbor: probably true, I guess...
 183 Feb 17 18:08:31 <pbor>	basically I don't want it at the bottom
 184 Feb 17 18:08:45 <pbor>	find bars at the bottom get on my nerves
 185 Feb 17 18:08:47 <pbor>	:)
 186 Feb 17 18:08:57 <pbor>	it's the last place where I look
 187 Feb 17 18:09:47 <nud>	calum: you can also use ctrl+g/ctrl+maj+g to cycle matches
 188 Feb 17 18:10:00 <calum>	ah ok, should have thought of that :)
 189 Feb 17 18:10:07 <nud>	as for the regular find, or ephy, or ...
 190 Feb 17 18:10:57 <pbor>	if you type a not-found string the entries turns red
 191 Feb 17 18:11:05 <nud>	(sorry not being very present, but I unfortunately have other things to do besides...)
 192 Feb 17 18:11:28 <pbor>	nud: no prob, I'll ping you when we get to the tools dialog
 193 Feb 17 18:11:55 <nud>	and then I'll answer as soon as I can. Try not to talk about it before 19.45 ;-)
 194 Feb 17 18:12:06 <pbor>	:)
 195 Feb 17 18:12:08 <nud>	(CET)
 196 Feb 17 18:12:22 <nud>	bbl
 197 Feb 17 18:12:35 <pbor>	okay, so I think the bottom line for search is:
 198 Feb 17 18:12:43 <pbor>	- the replace accel thingie
 199 Feb 17 18:12:52 <pbor>	- menu entry for clearing hl
 200 Feb 17 18:13:13 <pbor>	- find a way to make incremental search more discoverable
 201 Feb 17 18:13:49 <calum>	sounds about right... would certainly be nice to do the first two for 2.14, if possible...
 202 Feb 17 18:13:53 <joachim>	find a way to make incremental search more discoverable < IMO mentioning it in the docs is enough
 203 Feb 17 18:14:05 <pbor>	okay
 204 Feb 17 18:15:05 <joachim>	when's a good time to talk about indent/unindent?
 205 Feb 17 18:15:15 <pbor>	joachim: what about it?
 206 Feb 17 18:15:34 <joachim>	it seems every gnome text editor has different shortcuts for this
 207 Feb 17 18:16:18 *	jessevd|food is now known as jessevdk
 208 Feb 17 18:16:21 <pbor>	well, we get *tons* of bugreports about asking to use tab  for "mass indent" many lines
 209 Feb 17 18:16:37 <pbor>	would be nice to get a word from calum about this
 210 Feb 17 18:16:56 <pbor>	we currently use ctrl+t and ctrl+shift+t
 211 Feb 17 18:16:56 <joachim>	bluefish uses CTRL < > (without shift, but that;s the mental association)
 212 Feb 17 18:17:08 <joachim>	SubEthaEdit on OS X uses CTRL [ ] which is nice too
 213 Feb 17 18:17:16 <joachim>	both of thoe have a visual association that's nice
 214 Feb 17 18:17:21 *	mknepher (~michael@adsl-63-194-2-38.dsl.lsan03.pacbell.net) has joined #ui-review
 215 Feb 17 18:17:28 <calum>	have to say that selecting a bunch of lines and hitting Tab is usually the first thing I try, I don't know why though :)
 216 Feb 17 18:17:57 <calum>	(because my head tells me that should replace the selection with a tab...)
 217 Feb 17 18:18:00 <pbor>	calum: yup, the problem is that we need something similar for unindent
 218 Feb 17 18:18:06 <calum>	Shift-Tab?
 219 Feb 17 18:18:14 <joachim>	yup, that works on SciTE
 220 Feb 17 18:18:18 <pbor>	yes, that would be the first guess
 221 Feb 17 18:18:35 <pbor>	calum: but we were always afraid to break keynav
 222 Feb 17 18:18:44 <pbor>	focus handling I mean
 223 Feb 17 18:18:48 <joachim>	what do you think about <> or [] ?
 224 Feb 17 18:19:07 <kikidonk>	eclipse uses tab
 225 Feb 17 18:19:14 <kikidonk>	and ctrl-tab
 226 Feb 17 18:19:58 <pbor>	joachim: they are very uncomfortable on my keyboard
 227 Feb 17 18:20:05 <calum>	pbor: well, in a text editing app, I don't think anyone would really expect Tab/Shift-tab to move focus out of the editing window... we use Ctrl-Tab and Shift-Ctrl-Tab instead for those situations...
 228 Feb 17 18:20:32 <calum>	s/use/tell people to use :)
 229 Feb 17 18:20:43 <mknepher>	bluefish uses < and >, but I prefer the tab button
 230 Feb 17 18:21:11 <pbor>	joachim: on a .it keyboard <> [] require shift or alt gr to be typed
 231 Feb 17 18:21:15 <pbor>	calum: rock on
 232 Feb 17 18:21:19 <joachim>	yuck!
 233 Feb 17 18:21:56 <pbor>	calum: I just need to convince paolo then and we then get it in sourceview so that all app using it benefit
 234 Feb 17 18:22:08 <calum>	fine by me :)
 235 Feb 17 18:22:27 <pbor>	okay
 236 Feb 17 18:22:44 <pbor>	next on the list are either the print-preview or the message areas
 237 Feb 17 18:22:54 <pbor>	what you guys prefer?
 238 Feb 17 18:23:42 <calum>	actually, one last thing on  the View menu: "Highlight Mode->Normal"... what does "Normal" actually mean?  It just doesn't seem very descriptive...
 239 Feb 17 18:24:12 <pbor>	calum: right... it just turns of hl
 240 Feb 17 18:24:24 <calum>	ok, so "None" would be accurate too?\
 241 Feb 17 18:24:28 <joachim>	"plain"?
 242 Feb 17 18:24:40 <pbor>	None sounds good to me
 243 Feb 17 18:24:43 <joachim>	yeah or None
 244 Feb 17 18:24:49 <calum>	cool
 245 Feb 17 18:25:20 <calum>	ok... message areas then?
 246 Feb 17 18:25:25 <pbor>	cool
 247 Feb 17 18:25:37 <pbor>	http://gnome.org/~pborelli/ui-review/open-error.png
 248 Feb 17 18:26:03 <pbor>	we substituted some of the message dialogs with per tab errors
 249 Feb 17 18:26:19 <pbor>	a bit like firefox
 250 Feb 17 18:27:11 <pbor>	since errors may be async they should not interrupt workflow if they happen in a separate tab
 251 Feb 17 18:27:36 <pbor>	(e.g. saving a remote file which takes a while change tab and work on something else)
 252 Feb 17 18:27:43 *	joachim tries to remember if there's a UG section on file permissions
 253 Feb 17 18:27:50 <joachim>	if so, a help button could go there
 254 Feb 17 18:28:25 <calum>	so, I guess one question is why make them look so different to regular alerts... couldn't they just look like ordinary alerts, but "stuck" to the tab?
 255 Feb 17 18:28:31 <pbor>	they may also have  a progress bar http://gnome.org/~pborelli/ui-review/remote-open-progress.png
 256 Feb 17 18:28:44 <pbor>	calum: well, they look very similar
 257 Feb 17 18:28:48 <pbor>	same icon
 258 Feb 17 18:28:52 <calum>	except they're yellow and wide :)
 259 Feb 17 18:29:17 <pbor>	primary message is bold, secondary message in normal text
 260 Feb 17 18:29:40 <pbor>	well, the wideness is just as large as the tab is
 261 Feb 17 18:29:58 <calum>	right, but alerts are the width they are because it makes the message text easier to read...
 262 Feb 17 18:30:00 <pbor>	wrt the color... it's the tooltips background color
 263 Feb 17 18:30:15 <calum>	(~10 words or so usually, in English)
 264 Feb 17 18:30:23 <pbor>	which looked a bit less"gray" :)
 265 Feb 17 18:30:37 <calum>	well, it's good that it's themable at least....
 266 Feb 17 18:30:56 <pbor>	yup
 267 Feb 17 18:31:15 <pbor>	so we should contrain the text so that the message itself is less wide?
 268 Feb 17 18:31:26 <pbor>	for easier reading
 269 Feb 17 18:31:33 <calum>	well, it's something to think about...
 270 Feb 17 18:31:46 <joachim>	could you put a help button for some cases?
 271 Feb 17 18:31:50 *	pbor wonders how painful would that be in code...
 272 Feb 17 18:32:00 <pbor>	joachim: we can put any button
 273 Feb 17 18:32:01 <calum>	if your messages aren't very verbose anyway, it probably doesn't matter...
 274 Feb 17 18:32:27 <pbor>	joachim: but we use it just for messages that didn't use to require help
 275 Feb 17 18:33:20 <joachim>	there's # 6.10.13. To Change Permissions in the User Guide
 276 Feb 17 18:33:43 <pbor>	maybe an hyper link in the text would be better?
 277 Feb 17 18:34:06 <joachim>	sure
 278 Feb 17 18:34:11 <pbor>	(not sure how HIGgy that would be)
 279 Feb 17 18:34:48 <calum>	don't think it's either pro- or anti-HIG at the moment :)
 280 Feb 17 18:34:58 <pbor>	okay
 281 Feb 17 18:35:08 <pbor>	we'll take that into consideration
 282 Feb 17 18:35:18 <pbor>	okay... now that I introduced you to message areas, I'll show you the one that pains me the most
 283 Feb 17 18:35:25 <pbor>	http://gnome.org/~pborelli/ui-review/already-open.png
 284 Feb 17 18:35:29 <joachim>	there's a yucky numerical DocBook ID for that section, but I've just changed it to "nautilus-permissions"
 285 Feb 17 18:35:37 <joachim>	can you link to that?
 286 Feb 17 18:36:16 <pbor>	joachim: well, at the moment symlinks are not yet implemented, but we will try
 287 Feb 17 18:36:54 <pbor>	joachim: we are very near to 2.14 and the old dialogs didn't link to the help either, so at least we are not regressing
 288 Feb 17 18:37:02 <joachim>	the gedit prefs links to help
 289 Feb 17 18:37:17 <pbor>	sure
 290 Feb 17 18:37:29 <joachim>	that's "nautilus-permissions" in the Desktop User GUide, just to be clear
 291 Feb 17 18:37:29 <pbor>	joachim: I am talking about error messages
 292 Feb 17 18:37:39 *	mknepher has quit (Ex-Chat)
 293 Feb 17 18:37:42 <charles>	pbor: could the `edit' and `don't' buttons go underneath the alert text?
 294 Feb 17 18:37:47 <calum>	hmm... do you really need to use a message area for immediately-after-loading alerts anyway?  wouldn't you normally want to act on them right away?
 295 Feb 17 18:37:59 <calum>	(in which case a regular alert would be just fine?)
 296 Feb 17 18:38:22 <pbor>	calum: loading from remote may take a while
 297 Feb 17 18:38:37 <calum>	I suppose...
 298 Feb 17 18:38:47 <pbor>	calum: alerts block the whole window
 299 Feb 17 18:38:51 <calum>	oh, btw, does anything happen to show you have an alert in another tab?  does the tab icon change or flash or something?
 300 Feb 17 18:39:13 <charles>	calum: the tab icon is an error in open-error.png
 301 Feb 17 18:39:16 <pbor>	the icon changes
 302 Feb 17 18:39:59 <pbor>	we experimented with a bubble-from-the-statusbar, but for now that is the "crack" drawer :P
 303 Feb 17 18:40:13 <calum>	heh
 304 Feb 17 18:40:25 <calum>	charles: so it is... some inconsistency there then :)
 305 Feb 17 18:41:03 <charles>	I like the per-tab alerts, but those buttons are a long way away from the rest of the action
 306 Feb 17 18:41:36 <pbor>	charles: noted
 307 Feb 17 18:41:45 <charles>	heh, yep already-open.png should have a warning icon in the tab...
 308 Feb 17 18:41:56 <pbor>	good point
 309 Feb 17 18:42:24 *	pbor didn't understand calum's consistency observation
 310 Feb 17 18:42:51 <charles>	what happens when you click the `don't edit' button?
 311 Feb 17 18:43:07 *	hav0x has quit (Ping timeout: 600 seconds)
 312 Feb 17 18:43:19 <pbor>	charles: about the buttons position... we followed firefox... I guess we could put them below, I'll ask paolo what he thinks
 313 Feb 17 18:43:39 *	jessevdk is now known as jessevdk|gym
 314 Feb 17 18:44:02 <pbor>	"don't edit" causes the doc to stay open in read only mode
 315 Feb 17 18:44:11 <pbor>	which I agree it's confusing
 316 Feb 17 18:44:23 <pbor>	this is one of the main issues I wanted to discuss
 317 Feb 17 18:44:24 <calum>	"Open Read-Only"?
 318 Feb 17 18:44:35 <pbor>	http://bugzilla.gnome.org/show_bug.cgi?id=324491 is the bug about it
 319 Feb 17 18:45:06 <pbor>	calum: yes, that's an improvement... though I was thinking of getting rid of that button
 320 Feb 17 18:45:37 <pbor>	switching to the alreday open tab seems the most requested action
 321 Feb 17 18:47:17 <calum>	does seem more reasonable, I assumed you must have some sort of use case for having it open in multiple tabs :)
 322 Feb 17 18:48:02 <pbor>	well, I often want to compare the current version to the original
 323 Feb 17 18:48:23 <calum>	hmm, ok... sounds more like you want a diff plugin for that sort of thing :)
 324 Feb 17 18:48:41 <pbor>	or I happen to have the file already open in another window/workspace and open it in the current window for quick consultation and then close it
 325 Feb 17 18:49:15 <calum>	yes, that sounds a bit more likely...
 326 Feb 17 18:50:28 <charles>	"gedit opened this instance of the file" is either too wordy, or has a non-obvious semantic meaning.  Would "gedit opened the file" have the same meaning?
 327 Feb 17 18:50:43 <calum>	perhaps it could only show the message if the document was already open in the same gedit window?
 328 Feb 17 18:50:57 <calum>	er, not open, I mean
 329 Feb 17 18:51:03 <calum>	otherwise, just switch to that tab
 330 Feb 17 18:51:48 <pbor>	wouldn't changing the result depending on the context be a bit surprising?
 331 Feb 17 18:52:11 <pbor>	there are also other use cases to open the same file more than once in the same window
 332 Feb 17 18:52:24 <pbor>	for instance opening a "template" file
 333 Feb 17 18:52:42 <pbor>	which then you change in each tab and save as
 334 Feb 17 18:53:50 <calum>	pbor: maybe, there's a fine line between "surprising" and "doing the right thing " :)
 335 Feb 17 18:54:15 <pbor>	heh
 336 Feb 17 18:54:30 <calum>	sorry guys, I really have to go :(  Please keep the discussion going if you like, and I'll keep logging the chat session...
 337 Feb 17 18:54:43 <pbor>	ok
 338 Feb 17 18:54:52 <pbor>	thanks for your insight calum
 339 Feb 17 18:55:15 <calum>	no problem, thanks for coming :)
 340 Feb 17 18:55:25 *	calAWAY (~cb114949@amfea-proxy-2.sun.com) has joined #ui-review
 341 Feb 17 18:56:49 <pbor>	so, for this already-open thingie for now I'd prefer someone to suggest:
 342 Feb 17 18:56:57 <pbor>	- a better wording of the message
 343 Feb 17 18:57:22 <pbor>	- a label short enough for the "Switch to alreday open doc" button
 344 Feb 17 18:57:43 <pbor>	does someone have good ideas?
 345 Feb 17 18:57:46 <joachim>	sorry I've been semi-away - do you have a shot of this one?
 346 Feb 17 18:57:57 <charles>	http://gnome.org/~pborelli/ui-review/already-open.png
 347 Feb 17 18:59:04 <pbor>	since I have to run in a bit too consider that request open and add any suggestion to the bug in bugzilla :)
 348 Feb 17 18:59:10 <pbor>	http://bugzilla.gnome.org/show_bug.cgi?id=324491
 349 Feb 17 18:59:12 <joachim>	"gedit opened this instance of the file" -- why not "opened this tab"?
 350 Feb 17 18:59:17 <joachim>	since that's what the user sees
 351 Feb 17 18:59:34 <pbor>	joachim: yeah... though we try to avoid "tab"
 352 Feb 17 18:59:40 <joachim>	"gedit has opened this tab read-only"
 353 Feb 17 18:59:51 <joachim>	ok...
 354 Feb 17 19:00:03 <joachim>	"This is a second, read-only view of the document.
 355 Feb 17 19:00:10 <pbor>	sounds better
 356 Feb 17 19:00:24 <charles>	joachim: that's pretty good
 357 Feb 17 19:00:56 <pbor>	since I have to run too, maybe we can give a quick look at two new dialogs and look for any obvious HIG violations
 358 Feb 17 19:01:14 <pbor>	the dialogs are the ones from the two new plugins
 359 Feb 17 19:01:33 <pbor>	http://gnome.org/~pborelli/ui-review/external-tools-manager.png
 360 Feb 17 19:01:42 <pbor>	http://gnome.org/~pborelli/ui-review/snippets-manager.png
 361 Feb 17 19:02:00 <joachim>	they look ok
 362 Feb 17 19:02:18 <joachim>	the list / edit item combination is something I've been meaning to raise on the list for ages....
 363 Feb 17 19:02:25 <joachim>	there are so many implementations of it
 364 Feb 17 19:02:45 <pbor>	yup
 365 Feb 17 19:03:06 <pbor>	okay
 366 Feb 17 19:03:20 <pbor>	the other big item on my list is the new print preview
 367 Feb 17 19:03:41 <pbor>	http://gnome.org/~pborelli/ui-review/print-preview.png
 368 Feb 17 19:03:54 <pbor>	the controls are streamlined
 369 Feb 17 19:04:12 <pbor>	(inspired by evince)
 370 Feb 17 19:04:22 <--	xkahn has quit (Leaving)
 371 Feb 17 19:04:29 <pbor>	and it's directly in the tab instead of a separate window
 372 Feb 17 19:04:41 <joachim>	looks fine to me
 373 Feb 17 19:04:58 <charles>	very nice
 374 Feb 17 19:05:05 -->	xkahn (~xkahn@wlanconf-nat-pool-bos.redhat.com) has joined #ui-review
 375 Feb 17 19:05:26 <pbor>	thanks a lot to all of you guys
 376 Feb 17 19:05:31 <pbor>	I need to run too
 377 Feb 17 19:05:42 <joachim>	bye
 378 Feb 17 19:05:56 <pbor>	if you have any other comment or suggestion feel free to file bugs or grab me on irc
 379 Feb 17 19:06:06 <pbor>	bye
 380 Feb 17 19:06:12 ---	pbor is now known as pbor|afk
 381 Feb 17 19:06:40 <--	joachim has quit (Leaving)