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