You are not logged in.
Also can I name that, to XMVRSZ or something more macro'ish ?
and are XMoveWindow and XResizeWindow affected (see mousemontion) ?
Should they switch to use the macro too ?
Yeah, name doesn't matter.
XMoveWindow and XResizeWindow aren't affected as they aren't used by any tiling code.
Mousemotion stuff should just work without any monitor offseting (however, moving window to other monitor isn't yet a feature. It will act as if the client is still on monitor you moved it from)
that's good, although it won't be much problematic to have those mixed.
If the branch will be kept in sync with the master using rebase, then if you
resolve the conflict once, it is remembered will be resolved automatically
on updates (future rebases).
Yeah, this is something I can do in the end (revert changes, reorder and apply them again before pull request on seperate branch)
Currently it helps a bit for me to seperate the multi-monitor code from monsterwm.
I guess the simplest thing for desktopinfo() would be to wrap it in a for loop,
over all the monitors and provide one more number, that would indicate the
monitor (fprintf got one more %d and the corresponding 'm' var).
(this is editing the desktopinfo() function):
Ok, I'll take this route then.
aside from that, MONITORS looks like a #define, while it's not,
and I think it's not needed (use LENGTH(&monitors) ?)
I also think you can drop the fallback function and merge it to xine_magic().
On the Makefile, you may want to add -g on LDFLAGS too
I don't think your LENGTH macro will work on pointer(?), at least sizeof should not.
The monitors is dynamically allocated on xinerama_magic.
The variable is called MONITORS, just so it makes sense with the DESKTOPS define.
Fallback function could be merged yeah.
The reason it's there is, that if I make xinerama_magic() work with monitor detecting where it will complicate the logic a bit thus avoiding code duplication on possible future "failures".
Offline
Can anyone confirm that CLICK_TO_FOCUS is still broken?
Offline
Can anyone confirm that CLICK_TO_FOCUS is still broken?
Yes, is broken here.
Also added the desktop info for monitors, rotate function and other basic functionality.
Guess that would leave the more advanced such as adding new monitor when plugging a physical one in.
Offline
Can anyone confirm that CLICK_TO_FOCUS is still broken?
Yes, is broken here.
Works fine here.
Offline
Cloudef, I'm running your multi-monitor fork right now, looks good at first sight. I don't have the time to do further testing, but I think I'll keep this as my wm for the next days.
A very old bug seems to be still in monsterwm. I mentioned this earlier in this thread: I want to start an application with MOD4+y, but this key combination isn't being caught by monsterwm, neither is MOD4+z, which lead me to the conclusion, that it's caused by my non-american keyboard layout (I have a german layout, in which the y and z keys are swapped compared to the american layout). I'd be happy to help debugging it, please give me a hint how I can provide helpful data!
Offline
kuraku wrote:Can anyone confirm that CLICK_TO_FOCUS is still broken?
Cloudef wrote:Yes, is broken here.
Works fine here.
as I said on irc, it works fine here too. I cant understand why it wouldnt work for you kuraku.
would you please share your config so I can test with that ?
I actually need the buttons[] array and the variables defined on top
.:[ git me! ] :.
Offline
A very old bug seems to be still in monsterwm. I mentioned this earlier in this thread: I want to start an application with MOD4+y, but this key combination isn't being caught by monsterwm, neither is MOD4+z, which lead me to the conclusion, that it's caused by my non-american keyboard layout (I have a german layout, in which the y and z keys are swapped compared to the american layout). I'd be happy to help debugging it, please give me a hint how I can provide helpful data!
either something else is cathing that (another app has set those bindings)
or the command binded with those is wrong
or the keycode is not recognised.
check with xev, see the keycode produced, and try using that directly
also post what you've binded it with if that's a custom command
Last edited by c00kiemon5ter (2012-04-27 19:35:21)
.:[ git me! ] :.
Offline
@Cloudef I merged your branch with tiny formatting changes and using XMVRSZ macro
also updated all branches/patches to use that too,
and updated the README patches section to point to your repo->multi-monitor branch
btw: you can drop other upstream branches by: git push origin :branch
this wont affect them locally, they just wont show on your github repo branch list
also you can make multi-monitor your default branch through the admin panel,
so if one visits your repo he'll be in multi-monitor by default
edit: updated again; multi-monitor rebased on current master
I think it'd be easier to continue working on that now
check the network graph
all but the last commit on multi-monitor are yours, and last commit is rearranging the header and macro and minor formatting changes
Last edited by c00kiemon5ter (2012-04-27 21:03:57)
.:[ git me! ] :.
Offline
@Cloudef I merged your branch with tiny formatting changes and using XMVRSZ macro
also updated all branches/patches to use that too,
and updated the README patches section to point to your repo->multi-monitor branch
Neat, I merged back the changes you made and deleted the other branches.
Cloudef, I'm running your multi-monitor fork right now, looks good at first sight. I don't have the time to do further testing, but I think I'll keep this as my wm for the next days.
Please let me know how it goes, I think the basic functionality right now that is there should be quite stable.
Last edited by Cloudef (2012-04-27 21:27:24)
Offline
I saw that
if you're on multi-monitor and supposing upstream is a remote pointing to my repo
$ git fetch upstream; git rebase upstream/master
should get your initial branch line to start from the last commit of my master
that wont really change anything in the code, just the graph aesthetics mostly
(it will move the point from where you initially cloned master and built multi-monitor upon, to the current tip of master)
try that if you'd like, w/e happens the code is there so you don't have to worry
and if rebase conflicts you can always: git rebase --abort # and restore things back or fix the conflict and: git rebase --continue
git is funny
.:[ git me! ] :.
Offline
I saw that
if you're on multi-monitor and supposing upstream is a remote pointing to my repo
$ git fetch upstream; git rebase upstream/master
should get your initial branch line to start from the last commit of my master
that wont really change anything in the code, just the graph aesthetics mostly
(it will move the point from where you initially cloned master and built multi-monitor upon, to the current tip of master)
try that if you'd like, w/e happens the code is there so you don't have to worry
and if rebase conflicts you can always: git rebase --abort # and restore things back or fix the conflict and: git rebase --continue
git is funny
Yeah, I was bit confused by that at first. I've hard resetted the master and multi-monitor to your's for now.
I'll do the rebasing proberly in future.
Offline
as I said on irc, it works fine here too. I cant understand why it wouldnt work for you kuraku.
would you please share your config so I can test with that ?
I actually need the buttons[] array and the variables defined on top
I aksed here to find out if someone else is expiriencing bugs like i do. Cloudef confirmed it too so it must be something.
Anyway, my config.h: http://ix.io/2lt/c
The build itself is really looking fine:
cleaning
monsterwm build options:
CFLAGS = -std=c99 -pedantic -Wall -Wextra -Os -I. -I/usr/include -I/usr/include/X11 -DVERSION="cookies-git"
LDFLAGS = -s -L/usr/lib -lc -L/usr/lib/X11 -lX11
CC = cc
CC monsterwm.c
monsterwm.c:443:6: warning: ‘last_desktop’ defined but not used [-Wunused-function]
monsterwm.c:644:6: warning: ‘prev_win’ defined but not used [-Wunused-function]
CC -o monsterwm
installing executable file to /usr/local/bin
installing manual page to /usr/local/share/man/man.1
Offline
btw: any reason to use Os instead of O2 as default?
Offline
@kuraku, using your config both on master and on monocleborders CLICK_TO_FOCUS works, if you set it to True (it's False on the pasted conf). tested it using some xterms and chromium. once you click, the focus is on that window.
@el mariachi, not really, optimizations arent meant for production though
(though! this isnt actually "the industry" or much of "production")
Os is safe, O{2,3} can hide compiler errors in logic analysys
also do optimizations here make any difference ?
Last edited by c00kiemon5ter (2012-04-27 23:03:09)
.:[ git me! ] :.
Offline
@kuraku, using your config both on master and on monocleborders CLICK_TO_FOCUS works, if you set it to True (it's False on the pasted conf). tested it using some xterms and chromium. once you click, the focus is on that window.
So we can leave this then. Maybe there is something wrong on my debian box, who knows.
Thank you for your patience
Last edited by kuraku (2012-04-27 23:22:38)
Offline
$ git clone git://github.com/c00kiemon5ter/monsterwm
$ cd monsterwm
$ git checkout monocleborders
$ wget http://ix.io/2lt
$ mv 2lt config.h
$ sed -i 's/CLICK_TO_FOCUS.*False/CLICK_TO_FOCUS True/' config.h
$ sudo make clean install
<Alt><Shift><Q> # to quit monsterwm
$ startx # on tty - start it again
that's all I did, and click to focus works as expected.
.:[ git me! ] :.
Offline
I think I have an easier way to add multiple monitor support to a catwm base.
It involves a different approach tho.
Instead of approaching it like "I have two monitors, how do I draw to each one", it uses what X gives us for $DISPLAY which is a big rectangle to draw on. For example, with two monitors set up side by side, X's big rectangle is the width of both of them and the height of the tallest. Here's a pic do show that:
So the problem for the window manager is where in X's big rectangle to draw so different desktops are on different monitors. With xinerama we can get where in X's big rectangle the monitors are and with catwm's desktop paradigm it can be fairly simple.
In broad strokes:
add geometry values to the desktop structure so each desktop can be drawn in the right spot in X's big rectangle to show on the monitor we want it on.
struct desktop{
...
unsigned int x, y, w, h;
};
keep a record of the visible desktops
typedef struct {
int visible_desktop;
} MonitorView;
populate those with xinerama info, adding the next desktop to show in X's big rectangle in the right spot for the next monitor
XineramaScreenInfo *info = NULL;
if(!(info = XineramaQueryScreens(dis, &num_screens)))
logger("XINERAMA Fail");
//printf("\t \nNumber of screens is %d\n\n", num_screens);
screen = DefaultScreen(dis);
root = RootWindow(dis,screen);
int last_width=0;
for (i = 0; i < num_screens; i++) {
for(j=i;j<DESKTOPS;j+=num_screens) {
//printf("\t **screen is %d - desktop is %d **\n", i, j);
desktops[j].x = info[i].x_org + last_width;
desktops[j].y = info[i].y_org;
desktops[j].w = info[i].width - BORDER_WIDTH;
desktops[j].h = info[i].height - (panel_size + BORDER_WIDTH);
//printf(" \t x=%d - y=%d - w=%d - h=%d \n", desktops[j].x, desktops[j].y, desktops[j].w, desktops[j].h);
// Master size
if(mode == 2) master_size = desktops[j].h*MASTER_SIZE;
else master_size = desktops[j].w*MASTER_SIZE;
desktops[j].master_size = master_size;
desktops[j].mode = mode;
desktops[j].growth = 0;
desktops[j].numwins = 0;
desktops[j].head = NULL;
desktops[j].current = NULL;
desktops[j].transient = NULL;
desktops[j].screen = i;
}
last_width += desktops[j].w;
}
XFree(info);
// Select first desktop by default
for(i=num_screens-1;i>=0;--i) {
const Arg arg = {.i = i};
change_desktop(arg);
}
when a desktop gets tiled get it's width and height and plug in where in X's big rectangle we start drawing so the desktop ends up on the right monitor
int scrx = desktops[current_desktop].x;
int scry = desktops[current_desktop].y;
sw = desktops[current_desktop].w;
sh = desktops[current_desktop].h;
XMoveResizeWindow(dis,head->win,scrx,scry+y,sw+2*BORDER_WIDTH,sh+2*BORDER_WIDTH);
You can see how the different approach works with dminiwm.multiview. I think approaching it differently makes the job easier. Hope it helps.
You're just jealous because the voices only talk to me.
Offline
that's what Cloudef is doing
a struct monitor holds the vars needed for each monitor (ie different set of desktops) including 'wh, ww, wx, wy' (your x,y,w,h)
each time we point to the current_monitor struct, so those vars are set and used globally.
and XMoveResizeWindow calls are wrapped in a macro to add 'wx,wy' (your scrx,scry) so the window spawns in the corrent monitor.
Last edited by c00kiemon5ter (2012-04-28 09:30:34)
.:[ git me! ] :.
Offline
I saw the bit about
Currently only way to switch monitor is the change_monitor function
and thought I would throw my 2 cents worth in. Hope I didn't offend anyone.
Good luck
You're just jealous because the voices only talk to me.
Offline
I saw the bit about
Currently only way to switch monitor is the change_monitor function
and thought I would throw my 2 cents worth in. Hope I didn't offend anyone.
Good luck
Yeah, that's just because I din't implent the rest of monitor functions. Currently there is rotate_monitor, client_to_monitor etc...
Suggestions are welcome though what to add.
Offline
I tried to point out that with the catwm base and a different approach to what X gives us to work with there's no need for functions like rotate_monitor. X ignores the monitors and gives us one big rectangle to colour in, so adding a monitor paradigm to the wm seems to me to be going against the way X works. If you look at the code for dminiwm.multiview there's not much extra code involved from my post above. I was happy to find another benefit of using catwm as a base and was well chuffed in how few lines I could do it in, so I wanted to share the approach. It's taking a different approach that's the hard bit. If what you're doing is working for you just ignore my sharing.
Last edited by moetunes (2012-04-28 12:48:42)
You're just jealous because the voices only talk to me.
Offline
I just pushed a work around for some clients that steal input focus, such as chromium.
if one is on a terminal, say looking on an irc session, and one posts a link, clicking that link would leave the terminal/irc hightlighted, but the input focus would be transfered to chromium. this is fixed now.
this also seems to be a side-effect of xembed windows. if anyone knows how to have input focus to xembed windows, without having to get the mouse over the xembed window, please come forward.
also reported here
.:[ git me! ] :.
Offline
Guess I'll share my panel configuration here (for people not familiar with making a panel)
Here's the startup script which uses "Some_sorta_bar"
#!/usr/bin/env bash
: "${wm:=monsterwm}"
: "${ff:="/tmp/${wm}.fifo"}"
some_sorta_bar &
[[ -p $ff ]] || mkfifo -m 600 "$ff"
while read -t 60 -r wmout || true; do
if [[ $wmout =~ ^(([[:digit:]]+:)+[[:digit:]]+ ?)+$ ]]; then
read -ra desktops <<< "$wmout" && unset r
for desktop in "${desktops[@]}"; do
IFS=':' read -r d w m c u <<< "$desktop"
case $d in
0) d="null" s="" ;;
1) d="web" s="::" ;;
2) d="foo" s="::" ;;
esac
((c)) && f="&3" && case $m in
0) i="T" ;;
1) i="M" ;;
2) i="B" ;;
3) i="G" ;;
4) i="F" ;;
esac || f="&2"
((u)) && f="&2"
((w)) && r+="&2$s $f$d $w " || r+="&2$s $f$d "
done
fi
xsetroot -name "&L$r&5 [&3$i&5] &R$(~/bin/statusbar)"
###xsetroot -name "&L$r&5 [&3$i&5] &R$(~/bin/statusbar)"
done < "$ff" &
$wm | tee -a "$ff"
Also here's a statusbar script which prints info you want, I just use it to print clock at the moment
#!/usr/bin/env bash
datey="$(date +"%H:%M")"
printf "&2%s "\
"${datey}" \
Note: "&2%s" etc. stands for a color which is set in some_sorta_bar.c
Color etc. part from my some_sorta_bar.c file (if you want my colors):
#define TOP_BAR 0 // 0=Bar at top, 1=Bar at bottom
#define BAR_HEIGHT 15
#define FONT "-*-ohsnap.icons-medium-r-*-*-12-*-*-*-*-*-*-*"
#define colour1 "#080808" // Background colour
#define colour2 "#5e7175" // The rest colour the text
#define colour3 "#a90e50"
#define colour4 "#00dd99"
#define colour5 "#ffffff"
#define colour6 "#ffff00"
#define colour7 "#ff00ff"
#define colour8 "#f0f0f0"
#define colour9 "#00ff00"
Because I'm a copy-cat I thank cookieboy for his startup script
Last edited by Shinryuu (2012-05-05 23:26:23)
Offline
Is floating mode not an option with the xcb fork?
Offline