1 * Now talking on #ui-review
   2 * Topic for #ui-review is: currently reviewing http://burtonini.com/temp/sj-start-ripping.png
   3 * Topic for #ui-review set by calum at Mon Feb 13 18:13:20 2006
   4 <calum_> bleah, flaky VPN
   5 * calum_ summons elijah again
   6 <calum_> the force obviously isn't with me today..
   7 * tom (~thocon@genericgenus.plus.com) has joined #ui-review
   8 <joachim> got my VM running
   9 <calum_> cool... do you have magnetic windows? :)
  10 * calum has quit (Remote closed the connection)
  11 <joachim> yup
  12 * sgarrit1 (~steven@rind.silverorange.com) has left #ui-review
  13 * tom (~thocon@genericgenus.plus.com) has left #ui-review
  14 * You are now known as calum
  15 <calum> So, I guess elijah wants some closure on http://bugzilla.gnome.org/show_bug.cgi?id=321905 ... but without him here I'm not sure we can help him too much...
  16 * elijah (~None@amr.math.utah.edu) has joined #ui-review
  17 <calum> bingo :)
  18 <elijah> sorry, weather *really* sucks here
  19 <calum> heh, no worries
  20 <calum> elijah: so, maybe you can tell us exactly what you'd like us to cover... edge resistance issues specifically?
  21 * lmanul (~manu@dan75-4-82-239-58-38.fbx.proxad.net) has joined #ui-review
  22 <calum> and/or any other stuff?
  23 <elijah> Basically, I want an answer to http://bugzilla.gnome.org/show_bug.cgi?id=321905#c50
  24 <elijah> If you want to look at other stuff, that's cool, but I didn't have anything specific in mind other than that
  25 <calum> well, we'll see how we do for time :)  can't imagine there'd be much else to cover anyway though...
  26 <calum> so, I suspect people are really going to want to have a recent version of metacity in front of them for this one, if possible... screenshots probably aren't going to help :)
  27 <elijah> right, screenshots will be useless
  28 <elijah> 2.13.13 or better should be good enough
  29 <elijah> anything before that isn't worth bothering with
  30 <joachim> 2.13.90 here
  31 <elijah> 2.13.90?
  32 <elijah> that version doesn't exist
  33 <joachim> that's the gnome build
  34 <lmanul> Ubuntu Dapper seems to have 2.13.89
  35 <elijah> cvs has never used 2.13.90
  36 <elijah> 90 isn't a number in the fibonacci sequence
  37 <joachim> it's a VM Brent Smith made for the docs team
  38 <elijah> you must have a patched version from someone or something
  39 <elijah> it'll probably be okay, though
  40 <joachim> what's Unidirectional vs bi= resistance?
  41 <elijah> Look at calum's ascii art in comment 4
  42 <joachim> just that it only sticks moving one way
  43 <elijah> If you're moving window A to the right, you'll feel resistance
  44 <elijah> if you're moving it to the left, you won't
  45 <joachim> got it
  46 <joachim> I'd vote for resistance both ways
  47 <elijah> (also, if you're moving A down you'll feel resistance, if you're moving A up, you won't -- but that part I think is right; I'm just not sure about the left/right thingy)
  48 <joachim> but I actually find all of this quite difficult with my mouse. I'd like it all to be stickier. there's no setting for that is there?
  49 <joachim> people with RSI or arthritis find small precise movements harder than big ones
  50 <elijah> We were aiming for subtle (so that it wouldn't get in the way) while still being helpful when trying to precisely align stuff
  51 <joachim> sure. but subtle is not the same for everyone
  52 <joachim> I agree this is about right for most people
  53 <elijah> true, but there is always shift as well
  54 <elijah> if aligning is really important
  55 <joachim> I didn't know about that, and it's jumpy and ugly :(
  56 * joachim makes note to mention it in the docs though
  57 <joachim> I think it would be good to have at least a GConf pref for overall stickiness
  58 <elijah> Well, right, it's jumpy but that's the point
  59 <joachim> yes but sometimes it shudders & makes me feel I'm fighting the mouse
  60 <elijah> yeah, and it likes jumping in a direction you didn't want to move more than I'd like
  61 <lmanul> Maybe shit should do something intermediate between the normal movement (without shift) and the current shit behavior ?
  62 <lmanul> shift
  63 <lmanul> woops :)
  64 <calum> I guess one question to ask would be:  if I'd never mentioned the situation in comment 4, does it seem like everyone is generally happy otherwise with the current implementation?  If so, I'd say it's perfectly valid just to close the bug and move on with our lives :)  (Since nobody else seems to need to line up windows like that, and they can use Shift to do so if they need to)
  65 <joachim> yes, seems fine
  66 * wolki (~wolki@client418.sg.fr.studentenwohnheim-bw.de) has joined #ui-review
  67 <elijah> well, had you not mentioned it there wouldn't have even been a resistance for e.g. moving window A to the right in your picture
  68 <elijah> so, are you suggesting pulling that resistance back out of the implementation?
  69 * calum has another quick play
  70 <joachim> I wouldn't mind the resistance both ways, but I'm ok with the way it is going right in the picture
  71 <elijah> I believe there was one other person who brought up aligning windows beside each other, though.
  72 <elijah> joachim: If I make it both directions, what strength do I give it?
  73 <joachim> wasn't me, but I quite like it
  74 <joachim> well it seems very weak to me right now
  75 <elijah> Do I split and use half the resistance for each direction?
  76 <joachim> I'd say the same both ways
  77 <elijah> yes, the same both ways, but how much is that?
  78 <joachim> but I find precision mouse movement tough
  79 <joachim> I would have said what it is now, both ways
  80 <elijah> So 32 pixels of resistance for this case (16 each way), and moving towards a window only has 16 pixels of resistance overall?
  81 <elijah> Or are you saying 16 pixels of resistance with 8 in each direction?
  82 <joachim> can you make it it's unidirectional but the direction is smart?
  83 * Vic (~Administr@87.248.175.182) has joined #ui-review
  84 <joachim> eg if I am moving L t R, it sticks that way and only that way until I let go of the window?
  85 <joachim> just a thought
  86 <elijah> I'm not following
  87 <calum> Vic, wolki : hi, we're specifically talking about  http://bugzilla.gnome.org/show_bug.cgi?id=321905#c50 , in case you're wondering :)
  88 <Vic> calum: Thanks :)
  89 <joachim> ok. with Callu'ms ascii art, I'm moving window A
  90 <joachim> it starts to the left of B
  91 <joachim> I move it till it's like in the picture, and it sticks.
  92 <joachim> not letting go of it, I go past
  93 <joachim> I then decide I wanted it back where it was, so I go back
  94 <joachim> going back, it doesn't stick
  95 <joachim> but if I'd started off with A over to the right, the same thing would happen going left
  96 <joachim> I mean starting with A sort of in the middle of B, and going left
  97 <joachim> never mind :)
  98 * calum kind of knows what you're trying to say :)
  99 <elijah> yeah, I think you just gave a good description of uni-directional resistance vs. bi-directional resistance :)
 100 * plors (~plors@ip223-231-59-62.adsl.versatel.nl) has joined #ui-review
 101 <joachim> I mean uni-directional resistance that is in the direction of current motion
 102 <joachim> "current motion" meaning "the way you're going when you first reach that edge of window B
 103 <elijah> now I think you're trying to redefine the words I was using
 104 <wolki> sorry if this was already discussed, or is fixed (didn't boot into dapper for a few days), but shouldn't the top edge resistance (for alt-dragging windows) be reinstated now that there's no longer a time-based resistance?
 105 <joachim> sorry
 106 <elijah> wolki: there's still a pixel distance resistance, though
 107 <elijah> joachim: np
 108 * jimbly (~jimmy@82-70-97-124.dsl.in-addr.zen.co.uk) has joined #ui-review
 109 <joachim> forget it anyway. it'd be far too compliex for such a minor feature
 110 <wolki> elijah: yeah, but pixel-based resistance doesn't do anything when moving a window quickly, because I (at least) always overshoot
 111 <lmanul> elijah: so 16 pixels of resistance with 8 in each direction ?
 112 <elijah> I'll try to write up a patch that does the bi-directional thing so that people can try it out
 113 <lmanul> that would give a similar "feeling" to the current code, but bi-directionnal ?
 114 <elijah> Unfortunately, I don't have time for it today, especially with the stinkin' weather having wasted a few hours of my day
 115 <wolki> it's ok when using the titlebar... maybe i'm just too used to it from 2.12
 116 <elijah> lmanul: right
 117 <elijah> wolki: could be; most everyone seemed to hate the timeout resistance AFAICT
 118 <elijah> I'm glad there was someone else who liked it though, showing that I wasn't totally off my rocker
 119 <wolki> elijah: not me, but i agree a lot of people did. I haven't heard any complaints about the resistance at the top of the screen though
 120 <wolki> and if someone accidentally moves a window with alt-clicking out of the screen, but doesn't know about that feature, she is going to have a hard time getting that window back since the titlebar is no longer visible
 121 <elijah> wolki: no they won't
 122 <elijah> test it on some users
 123 <elijah> A) They aren't likely to alt-click-and-drag if they don't know about it
 124 <elijah> B) There is at least some (even if small) resistance if they do
 125 <elijah> C) If they click on window borders, the natural reaction of such users, then they can recover the window
 126 <wolki> I probably should... but it's hard to test for errors
 127 <elijah> Even if they never learn about alt-click or alt-f7
 128 <elijah> wolki: I tested it -- I moved my window offscreen manually and told other users to try to get it back on
 129 <wolki> yes, it's a quite unlikely case... could happen if someone tries to ctrl-drag and gets the wrong key
 130 <wolki> elijah: ok, then i rest my case.
 131 <calum> so... back to comment #50, are we saying that we really can't decide without being able to try it hands-on?  Are there any of the four options there that we can definitely discount?
 132 <elijah> yeah it's a good point that you brought up though.  I did have to try out a few things before I got it so that things were recoverable for such users in my testing; my first couple attempts didn't work so well.  :)
 133 <joachim> comment #50: fine as it is currently
 134 * xkahn has quit (Ping timeout: 600 seconds)
 135 <calum> is that your opinion, or are you suggesting we discount that option? :)
 136 <joachim> I think that as we can't think of another option being better, that's it's ok as is
 137 * evandro (~evandro@201-26-174-147.dial-up.telesp.net.br) has joined #ui-review
 138 * Vic has quit (Ping timeout: 600 seconds)
 139 <joachim> sorry :)
 140 <elijah> maybe I'll try to make up some patches to test the other options when I have some time and we can revisit this later?
 141 * Vic (~Administr@87.248.175.182) has joined #ui-review
 142 <calum> sounds reasonable to me... I don't think there's any point trying to rush in a decision for 2.14 when it's a bit of a corner case anyway (no pun intended...)
 143 <Vic> Slightly off topic - does metacity pop to the fereground for averry short time then go behind when it should open behind ?
 144 <Vic> Like when you click on a link in evo and continue using it, epiphany should open behind evo
 145 <wolki> vic: you mean no focus stealing? it should, though some apps still seem to steal focus
 146 <joachim> could you consider adding a scaling option to GConf?
 147 <elijah> "Like when you click on a link in evo and continue using it" -- what is "it"?
 148 * xkahn (~xkahn@wlanconf-nat-pool-bos.redhat.com) has joined #ui-review
 149 <elijah> also metacity isn't a window so "does metacity pop to the fereground" doesn't make any sense
 150 <Vic> Yep, I meant focus stealling prevention. Recentrly it started missbehaving for me. App that use it and did work prevously, now pop in front of everything for a short period of time, then go behind the active window, as they should have done in the first place.
 151 * lmanul has quit (Ex-Chat)
 152 <joachim> isn't that down to the app?
 153 <Vic> elijah: * The window managed by metacity :)
 154 <elijah> Vic: what version of metacity, what apps are involved, don't use "it", and provide more detailed steps for how to reproduce
 155 * zwnj (~zwnj@213.233.163.5) has joined #ui-review
 156 <elijah> joachim: http://bugzilla.gnome.org/show_bug.cgi?id=321905#c28, 2nd paragraph
 157 <joachim> that's a fair point.
 158 <joachim> a 'strong' setting would satisfy me :)
 159 <Vic> elijah: cvs HEAD. 
 160 <Vic> 1. Open evo with a meeesge containing a link
 161 <Vic> 2. Click to open that link, epiphany should open after a while
 162 <Vic> 3. Continue using evo so that when ephy opens, it opens behind evo
 163 <Vic> Result: Ephy opens in front of evo for a short while, then goes behind evo.
 164 <Vic> I hope this i clearer
 165 <Vic> * is
 166 <elijah> weird
 167 <elijah> you typed or clicked in evo after clicking on the link and before epiphany opened, right?
 168 <elijah> oh wait, there's a race condition in there
 169 * elijah grumbles about the stupidity of gnome-url-open
 170 <elijah> but I don't understand the in-front-of-for-just-a-while thing
 171 * elijah tries to duplicate
 172 <elijah> how do I change my default browser from mozilla to epiphany again?
 173 * elijah always forgets that
 174 <elijah> also, Vic, what version of metacity are you using?
 175 * evandro has quit (Ex-Chat)
 176 <Vic> elijah: Prefered aplications, in the control centre
 177 <Vic> elijah: HEAD
 178 <calum> ok, I gotta go... sorry we didn't actually resolve much :)
 179 * Disconnected ().