From: Tony H. <h...@re...> - 2004-06-05 19:21:26
|
In <200...@ho...>, Jonatan Liljedahl wrote: > On Fri, 4 Jun 2004 17:05:29 +0100 > Tony Houghton <h...@re...> wrote: > > > In <200...@ho...>, Jonatan Liljedahl wrote: > > > > > On Fri, 4 Jun 2004 13:31:23 +0100 > > > Tony Houghton <h...@re...> wrote: > > > > > > > * Using the Agua theme, which has rounded corners, the top-left > > > > corner > > > > of dialogues (not other windows) has a black border filling it > > > > out to a square. I use |HMC for my buttons, I don't know if > > > > that's making a difference. > > > > > > Yes, I've also noticed that and I have no idea what's happening. =) > > > It is only visible if you have different buttons enabled for normal > > > windows and dialogues in the Settings GUI. So if you can't live with > > > the black corner, you'll have to enable/disable the same buttons in > > > both. > > > > Or use a theme with square corners. But I quite like that one; oh > > well, the black bits aren't that bad. > > The dialog_buttons option was Guido's patch, so you'll have beg him to > take a look at it.. ;) Probably not much chance of me being able to work it out if you can't :-(. > > > > * Another one that you'd be tempted to blame on something else, > > > > but > > > > doesn't happen in Metacity: gkrellm isn't being hidden from > > > > Pager. > > Aha, I see. What does xprop say, is _NET_WM_SKIP_PAGER set on the > gkrellm window? Do you mean _NET_WM_STATE_SKIP_PAGER? xprop gives: _NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_BELOW > I'm quite new to this sort of stuff, does all property-changes have to > go through the WM or can an application set a property on it's window > without the WM having to handle it? Not sure what you mean now, but I've just thought of something which may be related to whatever you mean (IYSWIM!). I've got gkrellm configured not to be handled by the WM. > > What do you think of making the current options smart rather than > > having a separate smart placement option? I think it would give > > everybody the best of both worlds without cluttering up the options. > > I don't think it would be too much clutter with three options: At mouse > cursor, At center of screen, Auto/Smart placement. > > > Xinerama also makes the centre on screen option kind of silly but > > Yes, you're right. And I'm not sure anyone uses the centre of screen > option anyhow? =) > > > there's a little bit of a dillemma. Coding-wise there's some > > difference between trying to find a bit of free space anywhere and > > adjusting a position relative to a fixed point to avoid other windows, > > so in the absence of Xinerama I'd prefer to just write the second case > > and use the screen centre or the pointer position as the starting > > point depending on the user option. But which monitor should it choose > > the centre of for Xinerama? Always the one under the pointer? But I > > often launch, say, Firefox, from the panel in my monitor 0 and want it > > to open in monitor 1. So if the wm finds there's space on both (or > > neither) monitors how should it decide which one to use? Whichever has > > the most space, fewest windows, or let the user set a bias? > > I'd say that it should open on the monitor you were on when you launched > it. But I'm not sure, haven't thought about this very much. It's beginning to look like it would be sensible to either have "under pointer with smart adjustment" only, or a choice between that and "pure" smart placement. What do you think? Probably the latter is better even though it means more coding. Trying to adjust a centered window could easily miss a handy chunk of free space because of a small window near the middle of the screen getting in the way, unless the code is very clever. > > GDK's Xinerama support is very basic and simple (aside from some > > potentially confusing terminology about screens and monitors), so > > hopefully it shouldn't be much worse with the lower level X libs. > > Probably not... I guess there's just some command to fill a struct with > the info about the screens and their geometries, and then you'll do some > calculations in the relevant functions. xinerama.sf.net seems pretty empty, for docs anyway, but I looked at Xinerama.h and it's exactly as you say, easy enough to understand with no other docs. -- TH * http://www.realh.co.uk |