<[email protected]> <[email protected]>) Mime-Version: 1.0 Content-type: text/plain; charset="UTF-8"
>> And we need to rethink bindings for group operations, because when my wish >> "I want to see group my email client", I would obviously prefer to be able >> to summon the relevant group in some consistent way, even if my focus is on >> another head. >> >> In that case I guess we change quite a lot of things at once (not only in >> code, >> but also conceptually), so the question is what do we want to get if we >> change >> everything anyway. > >Obviously if such a fundamental change is to be made, it should be >done in a branch on its own and then see if it does work or not. Well, my point was that it is a good idea to think before doing a branch... >> Maybe I should not care because I have reached the state where I almost >> avoid group switches. I have even managed to overcome dirty hack with doing >> a pseudo-modeline out of XTerm by use of frame tagging (using XTerm is not >> a dirty hack per se because I have some status watching sripts for longer >> than >> I use StumpWM and I want seconds in my clock). In some sense, I >> have virtual heads inside heads and groups of windows are inside them. (I >> will >> probably post something on this tag-based solution to the list later, I want >> to play with it to be sure it works as I intended - if anyone wants to look >> at >> complete beta, I can send this now) > >Well, I must say that I too have found many workarounds that end up >making my dual-head experience pretty smooth and I don't really miss >independent heads so much anymore. With tags I try to have at least a semblance of some conceptual system, not a mere workaround. Whether I succeed is another question. >The problem is that I don't see anyone volunteering to make such a >drastic change to the stumpwm codebase. Sabbets or Male are the only >two contributors to the project that I've ever seen making such huge >modigications (Male, by the way, wrote most of the current >Xinerama/multi-head code, and it was no small chore). Does it have to be a huge rewrite? I don't volunteer because it will not fit _my_ usage patterns that is well-served by tags; but tags allow to have completely different experiences without being a lot of code - this change should probably be a smaller change. >Maybe the morale is that the current behaviour is the Stumpwm Way and >such a fundamental change would belong to a whole new WM? After all, >stumpwm started as a rewrite of ratpoison, and I've seen several >people complain of a certain code rot in the stumpwm codebase. Maybe >it'd be simpler to just start a new WM, having learned of the >strengths and weaknesses of stumpwm. Of course then the question would >be: what language next? :) Until we write next WM in the language that StumpWM becomes, we haven't succeeded in writing StumpWM in Common Lisp... _______________________________________________ Stumpwm-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
