Re: [dwm] New layout
Looking into your patch I more and more come to the conclusion
to add an extra void *aux field to Client for extensions like
this (or the previous extensions proposed in the toggle{vert,horiz} patches.
With this in 5.1 you could easily keep your patchset upwards
compatible if you use Client-aux to store all the extensions to
Client.
What do you think?
Then you could separate all your functions into dwmii.c which is
included in config.h instead.
Kind regards,
Anselm
On Wed, Jul 02, 2008 at 05:18:59AM +0200, QUINTIN Guillaume wrote:
Hello everybody !
First forgive my english because I am french.
I am a new user of dwm. I used wmii before (for about one year). I tried dwm
on my eeepc because it is the fastest wm and because the display can be
optimzed at best on little screens (800x480 on my eeepc). I enjoyed dwm very
much so I decided to put it in my main computer whose screen size is
bigger of course. More I used it and more I feel a lack. With wmii, I was
able to have several columns, several windows on each column, to change the
windows' heights and the columns' width, etc... But these features are not
in dwm. So I decided to write a patch for dwm 5.0.1.
MODKEY + SHIFT + ( LEFT | RIGHT ) = move current window to the end of the
previous / next column.
MODKEY + SHIFT + ( UP | DOWN ) = swap the current window with the previous /
next window in the same column.
MODKEY + BUTTON3 = Resize the current window.
I have tested it but not enough(I use it now all the time to find bugs). So
if you find any bug or have any critical remark or if you want to improve
it, add features, or change some please tell me.
Kind regards.
QUINTIN Guillaume
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] New layout
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
Looking into your patch I more and more come to the conclusion
to add an extra void *aux field to Client for extensions like
this (or the previous extensions proposed in the toggle{vert,horiz} patches.
With this in 5.1 you could easily keep your patchset upwards
compatible if you use Client-aux to store all the extensions to
Client.
What do you think?
Then you could separate all your functions into dwmii.c which is
included in config.h instead.
Kind regards,
Anselm
I like the idea, I think it would be well worth to give it a try.
--
- yiyus || JGL .
Re: [dwm] New layout
On Wed, Jul 02, 2008 at 11:35:38AM +0200, yy wrote:
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
Looking into your patch I more and more come to the conclusion
to add an extra void *aux field to Client for extensions like
this (or the previous extensions proposed in the toggle{vert,horiz} patches.
With this in 5.1 you could easily keep your patchset upwards
compatible if you use Client-aux to store all the extensions to
Client.
What do you think?
Then you could separate all your functions into dwmii.c which is
included in config.h instead.
Kind regards,
Anselm
I like the idea, I think it would be well worth to give it a try.
Well, I'm not totally sure, since *aux won't work without adding
at least a void (*cleanupaux)(void *); callback as well. So the
layout algorithm would need to check
if(!c-aux)
c-aux = malloc(Foobar);
before doing anything. However I had another look into the
patch, and it hooks into some other core functions of dwm as
well. Is there any way to get rid of this interference or to
discuss further hook possibilities?
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] New layout
On Wed, Jul 02, 2008 at 11:30:58AM +0200, Anselm R. Garbe wrote:
Looking into your patch I more and more come to the conclusion
to add an extra void *aux field to Client for extensions like
this (or the previous extensions proposed in the toggle{vert,horiz} patches.
With this in 5.1 you could easily keep your patchset upwards
compatible if you use Client-aux to store all the extensions to
Client.
What do you think?
No.
I had a look into the wmii patchset by Guillaume, but a proper
dwm integration would need much more hooks, like hooks into
focussing etc. So my decision is, to not extend Client with
*aux pointers. Such kind of heavy patches need to interfere with
dwm anyways.
@Guillaume:
To check if the layout in use is wlayout, use
lt[sellt]-arrange == wlayout, instead of these expensive
strcmp() calls. Note that lt[sellt] is the lt- pendant in hg
tip and upcoming 5.1.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] New layout
Another thing: I don't think that the design of dwm fits well with the layouting concept of wmii. This is because dwm depends on the assumption that the layout algorithm in use is dynamic enough to deal with arbitrary amounts of windows which are singly-linked, whereas wmii basically has more high-level data structures to organize windows and assumes the column concept in its definition. Thus its layout algorithm is less dynamic unfortunately. An algorithm I have in mind is more dwm-wmii like is somethink like: AACCBB CC DDCCEE This layout only shows 5 windows at maximum, and it uses slight overlapping to achieve a better screen real estate, the amount of overlapping could depend on mfact. The focused window is C and any focusstack() action will end up in a re-arrange(). C is always the list center. It scales for less than 5 windows as well. Just a random idea. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
[dwm] little bug
Hi, A little bug I found, so I fixed it ! When deleting a window, no call of wnohole() so holes appeared in the wtable so warrange() didn't resize windows properly ! Kind regards. QUINTIN Guillaume. dwm.wmii.diff Description: Binary data
Re: [dwm] little bug
On 7/2/08, QUINTIN Guillaume [EMAIL PROTECTED] wrote: A little bug I found, so I fixed it ! this is the dwm ml, there is a wmii ml as well
Re: [dwm] little bug
On 7/2/08, Szabolcs Nagy [EMAIL PROTECTED] wrote: On 7/2/08, QUINTIN Guillaume [EMAIL PROTECTED] wrote: A little bug I found, so I fixed it ! this is the dwm ml, there is a wmii ml as well oh sorry i misread (..wmii.diff confused me) ..so this is a dwm patch
Re: [dwm] New layout
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
Another thing:
I don't think that the design of dwm fits well with the
layouting concept of wmii. This is because dwm depends on the
assumption that the layout algorithm in use is dynamic enough to
deal with arbitrary amounts of windows which are singly-linked,
whereas wmii basically has more high-level data structures to
organize windows and assumes the column concept in its
definition. Thus its layout algorithm is less dynamic
unfortunately.
An algorithm I have in mind is more dwm-wmii like is somethink
like:
AACCBB
CC
DDCCEE
This layout only shows 5 windows at maximum, and it uses slight
overlapping to achieve a better screen real estate, the amount
of overlapping could depend on mfact. The focused window is C
and any focusstack() action will end up in a re-arrange().
C is always the list center. It scales for less than 5 windows
as well.
Just a random idea.
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Well, if we start with random ideas, I have one: we could have a new
lt[sellt]-restack (probably renamed to some better name I cannot
imagine now) and if it is NULL the floating behaviour will be used.
This way it would be easy to have layouts where focusstack rearrange
windows, or having a monocle where floating windows are resized.
Just an idea, but I would be glad to write tha patch if somebody finds
a better name than restack for the function.
--
- yiyus || JGL .
Re: [dwm] dwm sloccount through the time #3
Szabolcs Nagy [EMAIL PROTECTED] wrote: here is a time vs sloc plot (instead of revision vs sloc) I like that one. Maybe we should have x-axis descriptions for time, revision and releases ... but maybe thats overkill then ;-) meillo signature.asc Description: Digital signature
[dwm] The wmii layout and some help bout the mailing list
Hi Each time I want to post I start a new thread, how do I do to answer somebody ? @Anselm : Well, adding a void* aux to the Client structure sounds like a good idea but it is a first step towards adding official (or simply more advanced) support for plugins, I think. I mean that you will have to add an argument to the function lt-arrange indicating to the layout arrange function what action was performed on the window. This way no modification of the file dwm.c is needed, the patch (or plugin) can hold in a separate .c file with an #include only in the dwm.c. I think that it is a choice that has to be done. Plus, it won't add many lines (well to be sure I should try it !). This way no modification of the dwm.c (just an #include !). To do with the current version without modifying the dwm.c. It is simple. I thought of that before. It suffices to add a compare algorithm which compare the wtable and the clients linked list to see if some windows were added or deleted or simply moved into another tag, etc ... But such an algorithm is (not complicated to write) long in terms of line of code and it will take much more memory than hooking into the dwm.c (That's why I decided not to implement it). In some way the wlayout function is a beginning of the algorithm. It checks if the windows tag has changed in the clients linked list and report the changes to the wtable. For the lt[sellt]-arrange == wlayout, you damned right, why did I not think of that ??? The first time I wrote the patch I used a tree instead of a 2D-array. So the layout could easily look like this : CCC CCC CCC CCC GGHICCC EEFFGGHIJJJ EEFFGGHIJJJ But I don't think that users (me included) will use this kind of structure (or hierarchy or layout). It is too complicated to manage and the code will grow up quickly in lines of code. A simple 2D-array will fit the needs of (almost) every user. I will (when I will have enough time) add a the possibility to mange the wmii layout by rows (at this time it is only by columns) because sometimes I need this kind of layout and a simple inversion of the height and width of windows should make it with few new lines of code. Best regards, QUINTIN Guillaume
[dwm] The answer to Anselm
Well, I figured out how works (I hope) the mailing list ! @Anselm Hmm, how would an action argument to arrange() help? What might this argument look like? The first idea that pops in my head is to have 3 arguments. An int one which is an ID defining the action performed on the window : #define CREATE_WINDOW 1 #define DELETE_WINDOW 2 #define TAG_WINDOW 3 #define UNTAG_WINDOW 4 and so on The second argument is of type Client*. It represents the window. And the third argument is a parameter depending on what action is performed. This way my patch can hold in a separate file. Only the resizemouse function is altered. We can imagine some lt-resizemouse function, but does that correspond to the philosophy of dwm ? Because, like I said it would be the first step to support plugins, and, to continue into this way, all functions that performs actions on windows like togglefloating, toggletag, mousemove, mouseresize, ... should be lt--ed. Well as I told, the wmii column layout is rather static, because it keeps certain clients at a fixed position (in a specific column, at a specific position) [...] And that's it already. You can move the windows into the column you want, you can change the windows' orders in each column and their sizes within the columns. Plus the layout is pertag-ed. I don't understand why you think that the layout is static ? When no window are moved it acts exactly like the tile layout ! Only some wzoom function is missing but it is trivial to add it. So the wmii layout adds in some ways more functionalities to the tile layout thus it should be considered less static than the tile layout. Do you plan to : * have a pertag-ed wmii layout ? * resize each window ? * move window into column ? * move windows' order within columns ? Why should the wmii layout be restricted to 3 columns ? When I work on a 22 screen I like to have 4 or 5 columns. It has already happened. The way you describe how windows are added into the columns is like mine expect when there is only one column, but a simple modification in wadd will make it. Why restrict the number of windows in a column ? What you want to do seems a lot like the tilecols layout contained in the nmaster patch to me. And that is not what I wanted. In contrast to this, dwm is designed for layouts which are totally independent from clients itself. There might be some ways to deal with a wmii-like approach in dwm, however they always will end up in heavy patching. Well, I agree that the clients linked list is not designed to do what I want to do. But I don't think that my patch is heavy patching. There is probably a better way to interact with dwm code. Kind regards, QUINTIN Guillaume
