Community
Participate
Working Groups
I20050527-0900, GTK+ 2.6.4, KDE 3.3.2, X.org 6.8.2, Linux 2.6.11 The minimized intro and the fast view bar both have drag/grab bars on the top/left side of them. These bars are drawn as dotted lines, essentially. However, they are drawn differently. This is particularly noticeable if they are placed next to each other.
In this corner hailing from T Dot, wearing the red trunks, I give you.... DEJAN THE DESTROYER! The the other corner hailing from sunny Ottawa, wearing the blue trunks, I gice you... BOXCAR STEFAN! Let me introduce the referee for this bout - Michael "The Breeder" Van Meekeren. This fight will be to 10 rounds, with each round lasting 2 minutes. GO!
Personally, I would rather use the CoolBar and let it render the handle any way it wonts. I got it close to working but had to back out because CoolBar does not support vertical orientation (there is a feature request against SWT). I think CoolBar would give us a portable solution becuase its dragger would be native-friendly. Now, whose idea was that I need to wear these hedious red trunks :-)? They make me look fat.
I agree that a native dragger would be better... and synchronizing our algorithm would be the next-best choice. I based my code on the IntroBar, but changed the appearance slightly to ensure that the margins were symmetrical. We should probably go with whatever looks closest to the coolbar-with-xp-manifest look.
So we can track this, dejans bug for coolbars supporting vertical is Bug 92013. Since it is not going to happen for 3.1, our options are make both dotted lines the same with the same spacing or go with a separator. Linda was going to propose a common spacing solution, Linda? I could not find a bug logged by you so why not comment here? I suggest we either 1) stick with the dotted line until 92013 is fixed OR 2) remove the feature and just use a cursor change (as in the curve on the top right for the perspective switching bar) to show this feature. I'm not sure that dragging it around is all that important and while it should be possible most people will probably leave it where it is.
We can do the following: 1) Use the same algorithm to render grab bars so that there is no difference between fast views and Intro 2) Render the grab bars only on Windows. This way, we will look polished on Windows while avoiding the non-native look on other platforms.
Even on windows, the grab bars are themeable and we can't always get it right.
IIRC, the 3.0/3.1 look is supposed to look "less busy" than the R21 look (that was one of the reasons for changing it). So to keep that spirit would mean removing that box around the fast view bar and intro bar, remove the dotted drags, and remove the little x close icon on the intro bar. All these appeared in a recent RC so they should be easy to back out.
minimally for RC4 we should make the two gripper areas and layout wrt spacing the same for the fastview and welcome bars. to be reviewed June 21
approved for RC4
Will do.
Assigning to intro for now because intro launch bar needs to be adjusted.
Tweaked intro launch bar grab handle to look like the fast view bar handle. Also swapped the location of the 'close' button relative to the grab handle.
Created attachment 23665 [details] patch to workbench Dejan here is what I was planning for the fastview bar to tighten it up. I will load your code from head to see if they are different still.
I would be very surprised if they are. Let me know when you are done so that I can catch up.
Created attachment 23667 [details] updated patch
Created attachment 23668 [details] the fast view bar in all positions Dejan please copy this , I'm testing this patch on other platforms now
Dejan, please hold off and copying this till tomorrow. I found some issues on other platforms that I need to investigate.
Actually now that I have had some sleep and looked at this again. I think we should just leave it as it is now that Intro matches the fast view bar. There is a decent amount of space on the side of the gripper that could be tightened up but this also gives more affordance when trying to grab it and move it and it turns out when the fast view bar is empty and shrinks down to the thin bar it is important to have a few extra pixels on the sides of the gripper. I amd marking this as FIXED for RC4, thanks Dejan.
That was my sentiment too - I was surprised that you wanted to further play with it. You need some margin around the grab bar, otherwise it becomes difficult for mouse-challenged users.
Actually you only assigned it - I am marking it fixed now :-).
