(17:59:56) hi calum (18:00:03) hi pbor (18:02:40) it usually takes a while for people to show up, so we'll wait a few minutes yet before we start :) (18:02:51) sure, no prob (18:05:07) pbor: is there anything specifically you want to look at apart from error messages? (18:05:34) calum: there is a review of the new features and plugins (18:05:57) I put a selection of screenies here http://gnome.org/~pborelli/ui-review/ (18:06:25) at a first look the main gedit window ( http://gnome.org/~pborelli/ui-review/main.png )has not changed much (18:06:25) pbor: excellent (18:06:49) the only change in the menus is the view submenu http://gnome.org/~pborelli/ui-review/view-menu.png where we removed the option to set the toolbar style (the control center capplet suffice) (18:06:52) zwnj: could you op me, please? (18:07:07) calum: hi (18:07:15) i didn't know i'm an op :D (18:07:19) zwnj: or just set the topic to http://gnome.org/~pborelli/ui-review/ (18:07:22) zwnj sets mode: +o calum (18:07:24) zwnj: oh... well, xchat thinks you are :) (18:07:27) thanks :) (18:07:38) calum set topic on #ui-review: Now reviewing : http://gnome.org/~pborelli/ui-review/ (18:07:39) hi pbor (18:07:43) we introduced the side and bottom panels. As you can see there is the first terminolgy issue here: pane vs panel. We started with panel but then we saw that nautilus uses side pane, so we changed that, but decided to leave the bottom one alone waiting for better suggestions (18:07:48) hey zwnj (18:08:38) pbor: ok, we can talk about that then... (18:08:51) http://gnome.org/~pborelli/ui-review/panes.png shows the panes btw (18:09:39) the bottom one is only sensitive if a plugin makes use of the bottom pane, the side one always contains at least the docs list (18:10:06) pbor: what's that [+] ? (18:10:17) zwnj: the tags plugin (18:10:38) oh, seems interesting (18:10:42) what's it? (18:10:49) ^that ? (18:10:52) (which is not enabled by default) (18:11:16) *calum enables all plugins for the sake of the ui review :) (18:11:34) zwnj: it just offers a list of a collection of tags to insert, e.g. html tags (18:11:48) uh, got it (18:11:55) I advise against using the tags plugin in general (18:12:05) it performs badly unfortunately (18:12:23) we need to rework it, but didn't have time in this cycle (18:12:58) ok, I guess we'll wait until quarter past and then start properly... (18:13:07) *calum takes the opportunity to make some coffee :) (18:13:10) okay (18:16:23) ok, let's go then :) (18:16:47) I guess we should start with a quick look at the main window... http://gnome.org/~pborelli/ui-review/main.png (18:17:26) only slightly unusual thing I see there is that Open and Save have text on their toolbar buttons, but New doesn't... any particular reason for that? (18:18:23) well, that's me who uses the text beside icon option (18:18:51) right... me too, but if Open and Save have text beside their icons, I'd just usually expect New to have it too :) (18:19:07) I'm not sure it's breaking any specific HIG guidelines though, just curious... (18:19:23) I think the reasoning was that new is not used that often (18:19:48) (we just forward ported what was already there in previous versions) (18:19:56) that's a perfectly good reason... (18:20:44) *calum does his usual quick keynav and theming check... (18:22:03) (this time around emacs keybinds should actually work for the three people that care) (18:22:04) 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 :) (18:22:07) cool (18:22:26) yeah, the python console is not great (18:22:38) it's just the epiphany one ported (18:22:56) we were thinking of maybe disabling it (18:23:02) heh, ok... (18:23:19) everything looks great in high contrast themes though, good... (18:23:41) any other comments on main window before we move onto more specific stuff? (18:24:16) the only other change is that tabs are now reorderable by DnD, should be ok since epi does the same (18:24:52) cool... is there any way to do that from the keyboard? (18:25:12) mmm... good point (18:25:18) I fear no (18:25:43) well, wouldn't worry about it too much... probably something the HIG/a11y folk need to think about and make a recommendation anyway... (18:26:13) yes, also because it's one of the things that will be soon moved in GtkNotebook itself (18:26:24) right (18:26:41) *calum thinks we could probably just adapt the keynav spec for re-ordering table column headers (18:27:04) think we suggested Ctrl+arrow keys for that or something, when the header itself had focus (18:27:05) sounds good (18:27:28) or we could just add "move left/right" menu items to the Documents menu or something too... (18:28:00) (especially as I see there's already a Move to New Window item there...) (18:28:27) yep, though it would make that menu grow a bit (18:28:44) (it can be quite long when there are a few docs open) (18:29:07) true... do you have a limit on how many docs can be shown on the menu? (18:29:24) I guess that if we add them there we should also add them to the right-click menu on the tab (18:29:38) yes, that would be good too (18:29:42) no, no limit... should we put one? (18:31:29) 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... (18:31:53) not sure the submenu thing really solves the problem anyway (18:32:02) just makes the top level a bit tidier (18:32:11) yeah... sounds like a bit of a corner case (18:33:22) also because you could end up with the current doc not visible in the menu (18:33:34) yes. true... (18:34:08) 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 :) (18:34:24) yes, it would break keyboard (18:34:45) the first ten docs are reachable with alt+1,2,3... (18:35:11) right (18:35:32) ok, so let's not mess about with that :) (18:35:36) :) (18:35:42) while we're talking about menus, we might as well have a look at http://gnome.org/~pborelli/ui-review/view-menu.png (18:36:18) ok (18:36:39) with respect to previous gedit we ditched the toolbar style submenu (18:36:42) joachim (~joachim@ACD61A30.ipt.aol.com) joined #ui-review (18:36:50) I guess no one will cry for that ;) (18:36:58) 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 (18:37:03) oops :) (18:37:13) too much clipboard there :) (18:37:17) we're just having a look at http://gnome.org/~pborelli/ui-review/view-menu.png (18:37:24) pbor: heh (18:37:38) is gedit 2.13.90 ok? (18:37:43) the main issue is the pane vs panel terminology (18:37:45) joachim: sure (18:38:21) *joachim checks the style guide... (18:38:31) nautilus uses side pane (18:38:49) style guide says "pane" (18:38:57) though bottom pane sounded weird to our non-english ears (18:39:00) we should perhaps save 'panel' for the panels (18:39:06) 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"... (18:39:26) bottom pane is greyed out on mine... what is it? (18:39:33) or can the bottom pane be used so generically that "bottom" is the best we can do... (18:39:39) joachim: enable all your plugins (18:39:55) well, the fact is that a plugin can pretty much put what he wants there (18:40:06) ok (18:40:15) "plugin pane"? (18:40:33) plugin can also put stuff in the side pane (18:40:34) I thought that too, but plugins can use the side pane too, right? (18:40:38) ah (18:40:43) rats (18:40:58) beside I don't see a reson to expose the plugin implementation detail (18:41:06) right (18:41:50) 'bottom pane' sounds ok to me, & I'm a native english speaker (18:42:12) *calum agrees (18:42:12) ok, so unless someone comes up with something better we should go with "bottom panel" -> "bottom pane" (18:42:20) yep (18:42:23) okay (18:43:04) (aside) Replace should be CTRL-H, not R (18:43:25) why, it has been ctrl+R for ages (18:43:27) ? (18:43:35) HIG (18:43:49) mmm (18:43:59) I mean, you don't have to get rid of R (18:44:03) *pbor wonders why this didn't come up before (18:44:13) *joachim thought he'd filed a bug (18:44:15) maybe nobody uses Replace :) (18:44:18) but it could have been another app (18:44:40) calum: I mean in previous ui review... ctrl+R has been there from the 2.0 days and before (18:45:23) 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... (18:45:32) (maybe something else used to use Ctrl+H?) (18:45:41) *calum checks old ui-review notes (18:46:06) *joachim checks for the \n selection bug (18:46:28) joachim: what is that? (18:46:34) it's not gedit, it's GTK (18:46:41) ah, right (18:46:52) but it makes working with source a PITA (18:47:04) I end up chasing stray newlines (18:47:35) joachim: can you cc me if you find the bug? (18:47:40) yup (18:47:44) great (18:47:50) http://bugzilla.gnome.org/show_bug.cgi?id=323886 (18:48:16) what's your email? (18:48:51) I am already on CC apparently (18:48:55) cool (18:49:39) hmm, weird, can't find any mention of Ctrl-R/H thing at all :) (18:49:59) maybe we've all been blind all these years... (18:50:24) who uses ctrl+H for replace out of curiosity? (18:50:48) *pbor woders if it would be less painful chaninging the HIG :P (18:50:50) *jessevd|food always uses Ctrl+R (18:51:00) *calum tries to think of another GNOME app that allows Replace... (18:51:17) bluefish (18:51:31) HIG has Ctrl+R for Reload/Refresh IIRC, so we'd need to change all the apps that used that... (18:52:17) SciTE (18:52:18) or the other option, as mpt and others often point out, is just to offer Replace automatically in every Find dialog... (18:52:31) then you don't need a separate shortcut :) (18:52:57) that would actually be ok with me (18:53:00) yeah. I think a common find dialog might be a good thing to think about one day (18:53:33) speaking of find (18:53:53) what you guys think of the match highlighting? (18:54:15) unfortunately it's not easily themable (18:54:18) all terms in yellow? nice! (18:54:32) until gtk gets support for symbolic colors (18:54:34) but how do I clear it? (18:54:46) joachim: ctrl+shift+K (18:54:46) heh, I was just wondering that :) (18:54:59) yeah, that's what I wanted to ask :) (18:55:00) is that option on the menus anywhere? (18:55:02) no menu item? (18:55:08) i don't know if it's a gedit or gtk problem, but in the save dialog filename entry doesn't focus the folderchooser button (18:55:23) Could you add Search -> Clear highlight ? (18:55:32) sounds good to me... (18:55:40) yes, that's a possibility (18:56:08) kikidonk: hmm, you're right... you can use Ctrl-Tab though, at least... (18:56:12) the other possibility would be to clear the hl when closing the dialog (18:56:42) but it would make the hl less useful if one wants to keep stuff highlighted (18:56:48) yeah... I wonder if there's much point in having the highlight at all if you're going to do that... (18:56:54) indee (18:56:56) +d (18:57:08) prob: OT, but would you test the print preview in an RTL locale? (18:57:28) zwnj: yeah... we'll get to the print preview in a bit :) (18:57:36) *pbor wants to finish up search (18:57:50) so, this brings me to the new incremental searching (18:57:51) there's no news on a stock Open Recent menu item is there? (18:57:53) pbor: so the search panel for now :D (18:58:29) joachim: recent stuff will be reworked as part of project ridley (18:58:36) right (18:58:48) the new incremental searching is triggered with ctrl+K (18:59:08) *calum suspects that should be on the Search menu too (18:59:13) http://gnome.org/~pborelli/screenshot (18:59:28) the reasoning is that it's an advanced feature (18:59:44) 404 (18:59:59) and we don't want people to thing upfront "Should I search this way or that other way?" (19:00:00) true, but advanced stuff shouldn't be completely invisible, just harder to find :) (19:00:25) *calum tries to think of a better idea (19:00:25) what would be a good menu item? (19:00:46) also, for casual users the find dialog suffices (19:01:04) oh yes, wouldn't argue with that (19:01:26) the incremental one is useful only with "hands on the keyboard" (19:02:20) I dunno what you'd call it, really... "Typeahead Search", "Incremental Search"... *shrug* (19:02:27) or you could just put the search box on the toolbar and not call it anything :) (19:02:43) how do you start that? (19:02:49) ctrl+K (19:03:12) is there any way to cycle through matches, or are you stuck with the first one? (19:03:20) ah. the popup pops up in a funny place (19:03:26) calum: up/down arrows (19:03:39) calum: and the mouse scroll wheel (19:03:43) pbor: that drops down the history list for me... (19:03:57) it half covers the tab (19:04:22) calum: yes... that's unfortunate: actually I think we should kill the history (19:05:04) joachim: is that a problem? (19:05:11) it was done on purpose (19:05:22) it's not a prob, but it looks a little odd (19:06:30) I see you've done it so it's flush with the bottom of the document title (19:06:48) 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) (19:07:04) but it obscures the corner of the tab's icon (19:07:50) 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 :) (19:07:53) I'd nudge it to the right a bit. But it's not a major concern. You'll just get bug reports ;) (19:08:00) calum: in the others cases text gets scrolled (19:08:13) charles (~charles@nat.nssl.noaa.gov) joined #ui-review (19:08:15) pbor: probably true, I guess... (19:08:29) basically I don't want it at the bottom (19:08:43) find bars at the bottom get on my nerves (19:08:46) :) (19:08:56) it's the last place where I look (19:09:47) calum: you can also use ctrl+g/ctrl+maj+g to cycle matches (19:10:00) ah ok, should have thought of that :) (19:10:07) as for the regular find, or ephy, or ... (19:10:56) if you type a not-found string the entries turns red (19:11:04) (sorry not being very present, but I unfortunately have other things to do besides...) (19:11:26) nud: no prob, I'll ping you when we get to the tools dialog (19:11:54) and then I'll answer as soon as I can. Try not to talk about it before 19.45 ;-) (19:12:04) :) (19:12:07) (CET) (19:12:21) bbl (19:12:34) okay, so I think the bottom line for search is: (19:12:41) - the replace accel thingie (19:12:51) - menu entry for clearing hl (19:13:12) - find a way to make incremental search more discoverable (19:13:49) sounds about right... would certainly be nice to do the first two for 2.14, if possible... (19:13:52) find a way to make incremental search more discoverable < IMO mentioning it in the docs is enough (19:14:04) okay (19:15:04) when's a good time to talk about indent/unindent? (19:15:14) joachim: what about it? (19:15:33) it seems every gnome text editor has different shortcuts for this (19:16:20) well, we get *tons* of bugreports about asking to use tab for "mass indent" many lines (19:16:35) would be nice to get a word from calum about this (19:16:55) we currently use ctrl+t and ctrl+shift+t (19:16:55) bluefish uses CTRL < > (without shift, but that;s the mental association) (19:17:07) SubEthaEdit on OS X uses CTRL [ ] which is nice too (19:17:15) both of thoe have a visual association that's nice (19:17:28) 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 :) (19:17:56) (because my head tells me that should replace the selection with a tab...) (19:17:59) calum: yup, the problem is that we need something similar for unindent (19:18:06) Shift-Tab? (19:18:13) yup, that works on SciTE (19:18:16) yes, that would be the first guess (19:18:34) calum: but we were always afraid to break keynav (19:18:43) focus handling I mean (19:18:47) what do you think about <> or [] ? (19:19:06) eclipse uses tab (19:19:13) and ctrl-tab (19:19:57) joachim: they are very uncomfortable on my keyboard (19:20:05) 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... (19:20:32) s/use/tell people to use :) (19:20:42) bluefish uses < and >, but I prefer the tab button (19:21:09) joachim: on a .it keyboard <> [] require shift or alt gr to be typed (19:21:14) calum: rock on (19:21:18) yuck! (19:21:54) calum: I just need to convince paolo then and we then get it in sourceview so that all app using it benefit (19:22:07) fine by me :) (19:22:25) okay (19:22:43) next on the list are either the print-preview or the message areas (19:22:52) what you guys prefer? (19:23:42) actually, one last thing on the View menu: "Highlight Mode->Normal"... what does "Normal" actually mean? It just doesn't seem very descriptive... (19:24:11) calum: right... it just turns of hl (19:24:24) ok, so "None" would be accurate too?\ (19:24:27) "plain"? (19:24:38) None sounds good to me (19:24:42) yeah or None (19:24:49) cool (19:25:20) ok... message areas then? (19:25:23) cool (19:25:36) http://gnome.org/~pborelli/ui-review/open-error.png (19:26:01) we substituted some of the message dialogs with per tab errors (19:26:18) a bit like firefox (19:27:10) since errors may be async they should not interrupt workflow if they happen in a separate tab (19:27:35) (e.g. saving a remote file which takes a while change tab and work on something else) (19:27:42) *joachim tries to remember if there's a UG section on file permissions (19:27:49) if so, a help button could go there (19:28:24) 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? (19:28:29) they may also have a progress bar http://gnome.org/~pborelli/ui-review/remote-open-progress.png (19:28:43) calum: well, they look very similar (19:28:46) same icon (19:28:52) except they're yellow and wide :) (19:29:16) primary message is bold, secondary message in normal text (19:29:38) well, the wideness is just as large as the tab is (19:29:58) right, but alerts are the width they are because it makes the message text easier to read... (19:29:58) wrt the color... it's the tooltips background color (19:30:15) (~10 words or so usually, in English) (19:30:22) which looked a bit less"gray" :) (19:30:36) well, it's good that it's themable at least.... (19:30:55) yup (19:31:13) so we should contrain the text so that the message itself is less wide? (19:31:25) for easier reading (19:31:32) well, it's something to think about... (19:31:45) could you put a help button for some cases? (19:31:49) *pbor wonders how painful would that be in code... (19:31:59) joachim: we can put any button (19:32:01) if your messages aren't very verbose anyway, it probably doesn't matter... (19:32:26) joachim: but we use it just for messages that didn't use to require help (19:33:19) there's # 6.10.13. To Change Permissions in the User Guide (19:33:42) maybe an hyper link in the text would be better? (19:34:06) sure (19:34:10) (not sure how HIGgy that would be) (19:34:48) don't think it's either pro- or anti-HIG at the moment :) (19:34:57) okay (19:35:06) we'll take that into consideration (19:35:16) okay... now that I introduced you to message areas, I'll show you the one that pains me the most (19:35:24) http://gnome.org/~pborelli/ui-review/already-open.png (19:35:29) there's a yucky numerical DocBook ID for that section, but I've just changed it to "nautilus-permissions" (19:35:36) can you link to that? (19:36:15) joachim: well, at the moment symlinks are not yet implemented, but we will try (19:36:52) 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 (19:37:01) the gedit prefs links to help (19:37:15) sure (19:37:28) joachim: I am talking about error messages (19:37:28) that's "nautilus-permissions" in the Desktop User GUide, just to be clear (19:37:41) pbor: could the `edit' and `don't' buttons go underneath the alert text? (19:37:47) 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? (19:37:59) (in which case a regular alert would be just fine?) (19:38:21) calum: loading from remote may take a while (19:38:36) I suppose... (19:38:46) calum: alerts block the whole window (19:38:51) oh, btw, does anything happen to show you have an alert in another tab? does the tab icon change or flash or something? (19:39:12) calum: the tab icon is an error in open-error.png (19:39:15) the icon changes (19:39:58) we experimented with a bubble-from-the-statusbar, but for now that is the "crack" drawer :P (19:40:12) heh (19:40:25) charles: so it is... some inconsistency there then :) (19:41:02) I like the per-tab alerts, but those buttons are a long way away from the rest of the action (19:41:35) charles: noted (19:41:44) heh, yep already-open.png should have a warning icon in the tab... (19:41:55) good point (19:42:22) *pbor didn't understand calum's consistency observation (19:42:50) what happens when you click the `don't edit' button? (19:43:18) charles: about the buttons position... we followed firefox... I guess we could put them below, I'll ask paolo what he thinks (19:44:00) "don't edit" causes the doc to stay open in read only mode (19:44:10) which I agree it's confusing (19:44:22) this is one of the main issues I wanted to discuss (19:44:24) "Open Read-Only"? (19:44:33) http://bugzilla.gnome.org/show_bug.cgi?id=324491 is the bug about it (19:45:05) calum: yes, that's an improvement... though I was thinking of getting rid of that button (19:45:36) switching to the alreday open tab seems the most requested action (19:47:16) does seem more reasonable, I assumed you must have some sort of use case for having it open in multiple tabs :) (19:48:00) well, I often want to compare the current version to the original (19:48:23) hmm, ok... sounds more like you want a diff plugin for that sort of thing :) (19:48:39) 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 (19:49:15) yes, that sounds a bit more likely... (19:50:27) "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? (19:50:43) perhaps it could only show the message if the document was already open in the same gedit window? (19:50:56) er, not open, I mean (19:51:03) otherwise, just switch to that tab (19:51:46) wouldn't changing the result depending on the context be a bit surprising? (19:52:09) there are also other use cases to open the same file more than once in the same window (19:52:23) for instance opening a "template" file (19:52:41) which then you change in each tab and save as (19:53:49) pbor: maybe, there's a fine line between "surprising" and "doing the right thing " :) (19:54:13) heh (19:54:30) sorry guys, I really have to go :( Please keep the discussion going if you like, and I'll keep logging the chat session... (19:54:42) ok (19:54:51) thanks for your insight calum (19:55:15) no problem, thanks for coming :) (19:55:24) calAWAY (~cb114949@amfea-proxy-2.sun.com) joined #ui-review (19:55:27) calum quit (Ex-Chat) (19:56:05) so, for this already-open thingie for now I'd prefer someone to suggest: (19:56:13) - a better wording of the message (19:56:37) - a label short enough for the "Switch to alreday open doc" button (19:56:59) does someone have good ideas? (19:57:02) sorry I've been semi-away - do you have a shot of this one? (19:57:13) http://gnome.org/~pborelli/ui-review/already-open.png (19:58:20) since I have to run in a bit too consider that request open and add any suggestion to the bug in bugzilla :) (19:58:25) http://bugzilla.gnome.org/show_bug.cgi?id=324491 (19:58:28) "gedit opened this instance of the file" -- why not "opened this tab"? (19:58:33) since that's what the user sees (19:58:49) joachim: yeah... though we try to avoid "tab" (19:58:56) "gedit has opened this tab read-only" (19:59:07) ok... (19:59:19) "This is a second, read-only view of the document. (19:59:26) sounds better (19:59:40) joachim: that's pretty good (20:00:12) since I have to run too, maybe we can give a quick look at two new dialogs and look for any obvious HIG violations (20:00:30) the dialogs are the ones from the two new plugins (20:00:49) http://gnome.org/~pborelli/ui-review/external-tools-manager.png (20:00:58) http://gnome.org/~pborelli/ui-review/snippets-manager.png (20:01:17) they look ok (20:01:34) the list / edit item combination is something I've been meaning to raise on the list for ages.... (20:01:41) there are so many implementations of it (20:02:01) yup (20:02:22) okay (20:02:35) the other big item on my list is the new print preview (20:02:56) http://gnome.org/~pborelli/ui-review/print-preview.png (20:03:10) the controls are streamlined (20:03:28) (inspired by evince) (20:03:45) and it's directly in the tab instead of a separate window (20:03:57) looks fine to me (20:04:14) very nice (20:04:42) thanks a lot to all of you guys (20:04:47) I need to run too (20:04:58) bye (20:05:12) if you have any other comment or suggestion feel free to file bugs or grab me on irc (20:05:22) bye