* Now talking on #ui-review * Topic for #ui-review is: currently reviewing http://burtonini.com/temp/sj-start-ripping.png * Topic for #ui-review set by calum at Mon Feb 13 18:13:20 2006 bleah, flaky VPN * calum_ summons elijah again the force obviously isn't with me today.. * tom (~thocon@genericgenus.plus.com) has joined #ui-review got my VM running cool... do you have magnetic windows? :) * calum has quit (Remote closed the connection) yup * sgarrit1 (~steven@rind.silverorange.com) has left #ui-review * tom (~thocon@genericgenus.plus.com) has left #ui-review * You are now known as 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... * elijah (~None@amr.math.utah.edu) has joined #ui-review bingo :) sorry, weather *really* sucks here heh, no worries elijah: so, maybe you can tell us exactly what you'd like us to cover... edge resistance issues specifically? * lmanul (~manu@dan75-4-82-239-58-38.fbx.proxad.net) has joined #ui-review and/or any other stuff? Basically, I want an answer to http://bugzilla.gnome.org/show_bug.cgi?id=321905#c50 If you want to look at other stuff, that's cool, but I didn't have anything specific in mind other than that well, we'll see how we do for time :) can't imagine there'd be much else to cover anyway though... 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 :) right, screenshots will be useless 2.13.13 or better should be good enough anything before that isn't worth bothering with 2.13.90 here 2.13.90? that version doesn't exist that's the gnome build Ubuntu Dapper seems to have 2.13.89 cvs has never used 2.13.90 90 isn't a number in the fibonacci sequence it's a VM Brent Smith made for the docs team you must have a patched version from someone or something it'll probably be okay, though what's Unidirectional vs bi= resistance? Look at calum's ascii art in comment 4 just that it only sticks moving one way If you're moving window A to the right, you'll feel resistance if you're moving it to the left, you won't got it I'd vote for resistance both ways (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) 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? people with RSI or arthritis find small precise movements harder than big ones We were aiming for subtle (so that it wouldn't get in the way) while still being helpful when trying to precisely align stuff sure. but subtle is not the same for everyone I agree this is about right for most people true, but there is always shift as well if aligning is really important I didn't know about that, and it's jumpy and ugly :( * joachim makes note to mention it in the docs though I think it would be good to have at least a GConf pref for overall stickiness Well, right, it's jumpy but that's the point yes but sometimes it shudders & makes me feel I'm fighting the mouse yeah, and it likes jumping in a direction you didn't want to move more than I'd like Maybe shit should do something intermediate between the normal movement (without shift) and the current shit behavior ? shift woops :) 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) yes, seems fine * wolki (~wolki@client418.sg.fr.studentenwohnheim-bw.de) has joined #ui-review 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 so, are you suggesting pulling that resistance back out of the implementation? * calum has another quick play I wouldn't mind the resistance both ways, but I'm ok with the way it is going right in the picture I believe there was one other person who brought up aligning windows beside each other, though. joachim: If I make it both directions, what strength do I give it? wasn't me, but I quite like it well it seems very weak to me right now Do I split and use half the resistance for each direction? I'd say the same both ways yes, the same both ways, but how much is that? but I find precision mouse movement tough I would have said what it is now, both ways So 32 pixels of resistance for this case (16 each way), and moving towards a window only has 16 pixels of resistance overall? Or are you saying 16 pixels of resistance with 8 in each direction? can you make it it's unidirectional but the direction is smart? * Vic (~Administr@87.248.175.182) has joined #ui-review eg if I am moving L t R, it sticks that way and only that way until I let go of the window? just a thought I'm not following Vic, wolki : hi, we're specifically talking about http://bugzilla.gnome.org/show_bug.cgi?id=321905#c50 , in case you're wondering :) calum: Thanks :) ok. with Callu'ms ascii art, I'm moving window A it starts to the left of B I move it till it's like in the picture, and it sticks. not letting go of it, I go past I then decide I wanted it back where it was, so I go back going back, it doesn't stick but if I'd started off with A over to the right, the same thing would happen going left I mean starting with A sort of in the middle of B, and going left never mind :) * calum kind of knows what you're trying to say :) yeah, I think you just gave a good description of uni-directional resistance vs. bi-directional resistance :) * plors (~plors@ip223-231-59-62.adsl.versatel.nl) has joined #ui-review I mean uni-directional resistance that is in the direction of current motion "current motion" meaning "the way you're going when you first reach that edge of window B now I think you're trying to redefine the words I was using 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? sorry wolki: there's still a pixel distance resistance, though joachim: np * jimbly (~jimmy@82-70-97-124.dsl.in-addr.zen.co.uk) has joined #ui-review forget it anyway. it'd be far too compliex for such a minor feature elijah: yeah, but pixel-based resistance doesn't do anything when moving a window quickly, because I (at least) always overshoot elijah: so 16 pixels of resistance with 8 in each direction ? I'll try to write up a patch that does the bi-directional thing so that people can try it out that would give a similar "feeling" to the current code, but bi-directionnal ? Unfortunately, I don't have time for it today, especially with the stinkin' weather having wasted a few hours of my day it's ok when using the titlebar... maybe i'm just too used to it from 2.12 lmanul: right wolki: could be; most everyone seemed to hate the timeout resistance AFAICT I'm glad there was someone else who liked it though, showing that I wasn't totally off my rocker 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 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 wolki: no they won't test it on some users A) They aren't likely to alt-click-and-drag if they don't know about it B) There is at least some (even if small) resistance if they do C) If they click on window borders, the natural reaction of such users, then they can recover the window I probably should... but it's hard to test for errors Even if they never learn about alt-click or alt-f7 wolki: I tested it -- I moved my window offscreen manually and told other users to try to get it back on yes, it's a quite unlikely case... could happen if someone tries to ctrl-drag and gets the wrong key elijah: ok, then i rest my case. 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? 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. :) comment #50: fine as it is currently * xkahn has quit (Ping timeout: 600 seconds) is that your opinion, or are you suggesting we discount that option? :) I think that as we can't think of another option being better, that's it's ok as is * evandro (~evandro@201-26-174-147.dial-up.telesp.net.br) has joined #ui-review * Vic has quit (Ping timeout: 600 seconds) sorry :) 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? * Vic (~Administr@87.248.175.182) has joined #ui-review 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...) Slightly off topic - does metacity pop to the fereground for averry short time then go behind when it should open behind ? Like when you click on a link in evo and continue using it, epiphany should open behind evo vic: you mean no focus stealing? it should, though some apps still seem to steal focus could you consider adding a scaling option to GConf? "Like when you click on a link in evo and continue using it" -- what is "it"? * xkahn (~xkahn@wlanconf-nat-pool-bos.redhat.com) has joined #ui-review also metacity isn't a window so "does metacity pop to the fereground" doesn't make any sense 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. * lmanul has quit (Ex-Chat) isn't that down to the app? elijah: * The window managed by metacity :) Vic: what version of metacity, what apps are involved, don't use "it", and provide more detailed steps for how to reproduce * zwnj (~zwnj@213.233.163.5) has joined #ui-review joachim: http://bugzilla.gnome.org/show_bug.cgi?id=321905#c28, 2nd paragraph that's a fair point. a 'strong' setting would satisfy me :) elijah: cvs HEAD. 1. Open evo with a meeesge containing a link 2. Click to open that link, epiphany should open after a while 3. Continue using evo so that when ephy opens, it opens behind evo Result: Ephy opens in front of evo for a short while, then goes behind evo. I hope this i clearer * is weird you typed or clicked in evo after clicking on the link and before epiphany opened, right? oh wait, there's a race condition in there * elijah grumbles about the stupidity of gnome-url-open but I don't understand the in-front-of-for-just-a-while thing * elijah tries to duplicate how do I change my default browser from mozilla to epiphany again? * elijah always forgets that also, Vic, what version of metacity are you using? * evandro has quit (Ex-Chat) elijah: Prefered aplications, in the control centre elijah: HEAD ok, I gotta go... sorry we didn't actually resolve much :) * Disconnected ().