On Fri, Mar 03, 2006 at 12:30:19PM +0100, Uriel wrote: > On 3/3/06, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > > The concept is still dynamic, even much more dynamic and > > acme-like than the larswm concept. > > You got 3 kinds of column arrangement, stacking, maximized and > > equal (like larswm's tiled stack). If you need to concentrate on > > a specific client, you maxmize it in the column, if you want to > > check a different client, you can check with stacking for its > > title or with equal for its contents on the fly. If you want a > > client in another column, you just send it to the specific > > column (prev, next, or numeric beginning at 1). > > That is already all about it. It is _not_ like larswm, but it is > > very similiar to the acme approach. > This is all complete nonsense, nothing of the things you mention here > implies that automatic column creation should not work just fine.
I never argued that it would not work fine, I argued that it is unnecessary complex. > And let me tell you, acme col management _sucks_ (actually, works well > for the somewhat limited context in which acme works, acme is after > all not a general purpose wm and you rarely fiddle with cols.) Why? As usual, no justification... > > In the old concept, once a column got destroyed, and another one > > created, I often had to fix the column widths, that was a very > > frking task all the time. With allowing empty columns this is > > gone now. > More nonsense, a way to easily and fast col resizing is needed anyway, > so this should be a non-issue, and really, it should be trivial to do I began writing wmi, because resizing my clients manually all the time sucks. Why should resizing cols all the time sucks less? > because cols can only be resized along the x axis, so all you need is > a grow operation(maybe a shrink one, but that can be emulated by going > to the neighbour col and growing it, just as individual windows are > managed in a single col) That was not the point. The existing resizing is easy to achieve, but it makes rarely sense to resize again and again if columns disappear from time to time. > > Exclusive flag is not simplier, it is just the special case > > capacity=1 for the general case. > Generality often implies extra complexity, and in this case for no > good reason at all. The code would be the same, if you check nclient > 1 or nclient > capacity, both might have the same impact. > > 1. You have two kinds of maximized clients in a column which you > > cannot easily check. > WTF? There is a single kind, the exclusive bit has no effect on the > client itself. It only kicks in when you try to add a new client to an > existing col. Still there are two different ways to achieve client maximization. > > Is a client maximized in a column or is the > > column itself exclusive? > WTF does this have to do with exclusive? You could as well have a > single client(non-maximized) in a column and it would look the same as > a maximized client in a col with more clients. (Easy solution, change > the color of the grab box for maximized clients) A single client attached to a non-exclusive column is not the question. The question is if a second client is attached. Then you have two ways to get defacto-maximization with different impacts. In acme there is only one way. > > 2. Once you dynamically create/destroy a column, the width of > > the other columns is destroyed, this is very nasty often. > Of all the issues you list, this is the only one marginally valid, and > as I explained above, it should be a non-issue, also it should not be > hard to keep track of the previous column layout and restore it when a > column is added. (Eg., if you delete the 3 col, and then it's created > again, you keep track of what was the width the last time you had a 3 > col, this can admittedly get messy, and maybe it's not worth doing, > but anyway you need a fast way to resize cols, so who cares? Well might be a minor issue, agreed. > > 3. If you have set all columns to exclusive, where do you create > > a new column? Just right of the current one, or most-right? > Just pick one, IMHO most right makes most sense and is probably > simplest to implement. Assumed that the adjacent column is exclusive as well this will be messy. Despite of the fact that such exclusive flag is something like locking (like we got rid in frames), the main question is not that a new column is created implicitely or not, the main question is, how does the zooming works. In the way I proposed like it is in acme, it is totally easy, just set a column into max mode and all clients are maximized if you cycle through the attached clients. Here, with an exclusive column you would need to define how to bring other clients to it, sendtoarea next (and there is a exclusive flag'ed column) would be interesting what happens. Does the selected column gets destroyed and its client is pushed rightwards, the right column pushes its client rightwards as well, because it is exclusive? If the selected column is not destroyed, where does it gets the other client from (assume the adjacent column is exclusive as well). Does it grab a client from rightmost column, which might be column 4? Where is the requested predictability? I think you haven't thought enough about all the impacts. > > 4. If you kill the client of a exclusive column, do you destroy > > the exclusive column or do you try to fetch the client from the > > adjacent column? If adjacent, what do you do, if it is set > > exclusively as well... > Ok, this is a more interesting case, but I can't see why it should be > hard. To have pure-larswm behaviour, yes, I suspect you need to try to > grab a client from the right if you run under one client. But still if > you didn't do this and you would just kill the window, dynamic col > creation still would be worth it. It is possible to find a way, but either way will be more complex than necessary. See the other issue above. > > I think this are only some issues I yesterday encountered, there > > might be even more. And you can easily guess that this gets very > > messy in the code. Especially sucking was the 1st point, because > > you got two different ways for the same, and that is bad design. > I can't see any reason why code should be messy to implement, the > concepts are very simple and clear. And the 1st point was the most Then enlighten us about the simplicity and clarity in the concepts. I don't think they are that clear and simple, because I have thought about it quite a lot already. And believe me, I know now why LarsWM consists of two columns only. I also understand why acme is like it is. Because it is easy to understand. Well assumed you would use column layout like in LarsWM it wouldn't be too hard to be implemented, but assuming you allow more columns it gets tricky'er. > lame and pointless of all, exclusive and max are totally independent, > exclusive just means the wm enforces having a single client on this As I pointed out, you missed the point. > > That is true. But your idea is not approved yet to be implementd. > > If the current concept is kept, the empty CN event is only for > > updating the client title in the bar (though I'm convinced that > > we don't need to display the client title in the bar anymore). > Holy fuck, not more "update titlebar" script insanity! I thought we > were over with that crap. There is no update titlebar script. But if a client title changes wmii produces CN <new title> as event which can be read from /event and used in scripts. The main event loop writes the argument to /bar/2/data, this simply displays the client title in the bar. Nothing else. > > I don't favorize the larswm concept anymore, I get too used to > > acme already. And see the other points above. > Acme is certainly nowhere as dynamic as it could be(and maybe for good > reasons, but again acme is not a general purpose wm.) And see above as > to why the "points" are pointless. Well, then propose a detailed way how to handle all problems I mentioned above in a simple, clear and predictable way. > > Same with the proposed changes. You just send windows to a > > specific column or you just destroy/create new columns if you > > need them. There's not much difference in pressing Alt-n to get > > a new empty column which is selected already or to Alt-n and > > taking the selected client to it, or if the current column is > > set exclusive to create a new column on the fly. > Little difference? a whole 100% overhead! (it takes twice work), and > the worst is that then you have to keep track of the newly created > col, and 1) make sure you get rid of it once you don't need it so it > doesn't waste space(more work, and delayed work which you will pay for > later, which is more annoying) and you have to keep track that once Getting rid of an empty column is somewhat overhead agreed, but for which price? And pressing Alt-r to get rid of a column is not that difficult. > you create the col, the process changes and then you have to first > select the col and then open the new client(or if it was spawned No, if you create a col, it is just selected. To run a new term in a new col you do Alt-n Alt-t. To let an exclusive column do the job you do Alt-x (set exclusive) Alt-t Alt-Return (because you have to send the new client back to the exclusive column). Same interaction points. Your only point is removal of columns. And this is lesser predictable. I agree with you, that the tiled layout in 2.5.x or LarsWM is fairly predictable, because it only consists of two columns and does not change. but it is rather limited if you got much screen space or if you want to work in a 2x2 grid or something similiar. And all those additions you mentioned here are pretty tricky and only simple and clear at first glance. But not if you think further about it. > Yes, and in acme 1) creating/deleting cols suck, 2) when new windows > show up in the wrong col, you have to re-arrange them by hand, which > is quite annoying. I agree that manual creation/removal of cols is not great, but it sucks less then cluttering all predictability with locking crap for too few benefit. > Lets see who is the closed-minded-dogmatic now. I'm not dogmatic. I (beside of others in IRC) used both concepts already, that is why I changed my mind.. You can believe me, that my proposed way is really much simplier, much more predictable, intuitive, without corner cases and clear then adding LarsWM stuff to columns. Regards, -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
