As for window grouping, I think the concept goes beyond the idea of stacks of paper. It's also useful for windows to be bound as adjacent for move and resize, as well as doing their raise, lower, iconify, and desk-change collectively.
Playing with prototypes, I've found that one of the issues is that it's not very friendly to ask people to repeatedly regroup the same sorts of windows together for every instance. I'm pretty happy with specifiying grouping patterns by WM_NAME and various other attributes like pid and client leader. This way I can get paned applications every time I launch them. The other thing that I've been told is that people weren't too keen on their windows being changed around, like with the idea of browser tabs and shifted title bars. Long ago, I toyed with a tab/partition module, but the imposed ornamentation of connecting edges and the tab bar weren't all that pleasing. I tried drag&drop, as well as a sticky grab button, in that partition module. It was awkward. I'm now using colored buttons: red group, blue group, etc. Click, click, click, no drag. It's pretty easy to use and also lets you survey who is in what group very quickly. Using the new proxy prototype in production for a month or so, I'm pretty satisfied delegating this functionality to the proxies. There are no visible changes except when you toggle for them to appear. I've added stacked-sheet behavior as an option to window groups. That's nice for shells, but I don't really have much use for stacking otherwise. Vim does it pretty well internally with the minibufexpl plugin and everything else is either spread out on its own desk or served better by plain proxy functionality. As for the auto-paning functionality of window groups, I'm starting to use that all over the place. What did I ever do before? -- _ ( \ _ \ /_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon [EMAIL PROTECTED] // [EMAIL PROTECTED] (/ On Thu, Jul 13, 2006 at 02:27:06PM +0100, David wrote: > On Thu, 13 Jul 2006 11:34:58 +1000, "Scott Smedley" <[EMAIL PROTECTED]> > said: > > Hi David, > > > > > I'm trying to find out how to have multiple windows sharing the same > > > frame. > > > I'm playing with FvwmTabs but I also want to experiment with a simpler > > > implementation on my own. > > > > Simpler? Hmmmm. > > > I just want to get four functions working - add, next, close and detatch > tab. > That is enough functionality for what I want to do. I want to see what > would > be possible if it was integrated into fvwm. > > It would remove the need to create a tabber first - just join any two > windows > together; and also remove the second title bar - it could be integrated > into the > main one. The aim would be to make it transparent to the user rather > than > offering alot of functionality and configuration. It's just an idea I > wanted to > play around with based on how pekwm does this. > > > > > You need to use XSetInputFocus(). > > The client window does get input focus and works normally, except that > the > frame decor isn't changed when the focus does. The event handlers aren't > called so I can't think of anywhere to put this that would work. I also > think > that it is a problem with events in general and not just input focus. > > The thing I don't understand is how the second client is different from > the first. > When they are selected, they are both equal to fw->wins.client. They > have the > same parent, the same FvwmContext and similar setting from add_window. > > -- > David > > -- > http://www.fastmail.fm - A no graphics, no pop-ups email service > >
