GNOME Bugzilla – Bug 111835
Change spacing in HST, and BME
Last modified: 2004-12-22 21:47:04 UTC
we should remove the 6px border so that when you maximize the window you can scroll the bms and targe topics by throwing your mouse against the screen edge. This may not seem like a common use case for us with large monitors, but for those on 640x480 or 800x600 this is useful for sure and just good design. Patch on the way, oh and it adds a 6px border to the search box so that it does lay up against the hpane.
Created attachment 16101 [details] [review] /me wishes moz text entries weren't borked. oh patch :)
Please commit. Thanks !
Created attachment 16126 [details] [review] patch part2
the attached patch is necessary to make the claims in patch 1 true. there were two problems. 1. ephy-state was saving and setting the position of maximized windows (bad dave!) 2. setting the shadow to GTK_SHADOW_IN on the scrolled windows, adds one pixel or so, to both edges of the screen breaking lots of stuff, so i just removed that since it is not necessary anyway. ok to commit?
+ if ((x >= screen_width) || (y >= screen_height)) + { + x = y = WINDOW_POSITION_UNSET; + } + + /* If the window has a saved position set it, otherwise let the WM do it */ + if ((x != WINDOW_POSITION_UNSET) && (y != WINDOW_POSITION_UNSET)) + { + gtk_window_move (GTK_WINDOW (window), x, y); + } Is this necessary ? You already checked for UNSET. I think you can just check the out of screen thing now. Like if ((x >= screen_width) || (y >= screen_height)) window_move;
About the shadow thing, I dont think we should change the style it's used everywhere else in gnome and epiphany.
re: comment one, that code is in the original code you approved way back when :) It is needed to check the initial condition. Ie. the first time a window is added to the state_node, it has an initial position of (WINDOW_POSITION_UNSET, WINDOW_POSITION_UNSET), since we assign that value when the node is created). However if we try to set the position to that point, metacity at least will move it to the closes on screen point which is probably (belowpanel, 0). So intead of setting the position we just let the wm choose the optimal point. re: comment two, nautilus for instance doesn't set the shadow in for this exact reason. There is no good way for gtk to fix this, it can't change the shadowing just because is maximized. Adding the shadow adds an extra one pixel border around the trees which makes slamming against the edges impossible.
re 1: Ooops I missed some - in the patch, I thought there was an unnecessary double check. re 2: Uhhhm I'd need to see it. Well check it in. I'm just worried it will look inconsistent with other treeviews :/
i actually think it looks better now.
ehm.. I think it looks butt-ugly now, and inconsistent with the rest of GNOME with the shadows gone. also it would be nice to remove the padding left and right of search label + entry, would make things line up a bit more nicely.
the padding on the search label is nice so that it doesn't rub up against the grab bar. Using shadow in sucks rocks here, you end up with a double bevel at the top of the topics view, and can't hit the edge of the screen with the mouse to select stuff when maximized. Nautilus using shadow_none here for the same reason for the list view and tree view and no one seems to complain. We could fake shadows on the grab bar and over title tree, but comparing the too when i was testing, the extra bevels just looked like visual noise to me anyway.
Ouch I agree with jorn that without border is incredibly ugly :/ Ihmo we should revert that. About the padding I prefer it this way though, it will never line up correctly and the spacing is nice.
Reverting shadows for release, then we can decide. I volounter to re-revert ;)
guess current status is ok