Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

@Unia, If X doesn't even start then I have no idea. A window manager isn't relevant until pretty late in the Xorg process. You should get several messages about your video driver (I think) and several other Xorg extensions.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Trilby wrote:

@Unia, If X doesn't even start then I have no idea. A window manager isn't relevant until pretty late in the Xorg process. You should get several messages about your video driver (I think) and several other Xorg extensions.

It starts but kicks me out within one second. I do see all the messages about drivers and extensions, but after that nothing. My screen flashes an instant and then returns me to X. Now as I said, it all worked before you added the focusfollowmouse and X does start when I start it with DWM (typing this from it).

My config.h is completely up-to-date too.

If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Just noticed when trying to play a fullscreen video--pretty much any video--from youtube on midori, we get another small window to resize but the top status bar kind of interferes with getting a full window so you have to move the window up--under the status bar--to be able to resize so you can get the progress bar and play, pause, etc buttons.

I just discovered the scroll animation while messing around here and it's kinda neat.

Can't say I'm a huge fan of clicking outside the window to move or resize with mouse without the mod button--seems kind of counter-intuitive to me, clicking outside a window to move/resize--but it's an innovative solution rather than implementing window top bars. Just something to get used to if I were to use this regularly.

edit: Could you include an option for a slimmer border? I prefer about a 1 pixel border, or none, personally.

Last edited by bgc1954 (2012-12-13 20:00:27)

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

For fullscreen video, you can use the 'tagconfig "bar" and 'window, "zoom"' bindings to toggle the statusbar and fullscreen the window. If you want you could combine these into one binding by adding the following function to your config.h

I can certainly add an option for border width. I think I'll also add an option to disable the move/resize without the mod button.

These are easy additions, but I'm out of town for a bit, so I will not get a lot of time to tinker for the next week - commits will be a bit slow, and my responses here may also lag. I will, however, certainly follow up on any issue or question raised when I do get some down time.

The scroll animation was fun (and frustrating) to do. I don't know how useful it is yet, but once I get tiling-per-tag working I think it will really shine. You can imagine opening several windows in one region of the destkop, tiling them in one layout there, then move to another region of the desktop, open more windows, and tile only those new windows at the new location. Then you could "scroll" back and forth between your two (or more) sets of tiled windows. This would effectively give you independent workspaces without sacrificing the "one big workspace" paradigm.

A bonus to be added with that will be a new concept: Checkpoints. Instead of only being able to animatedly scroll back to a given window, you'll be able to set checpoints on the desktop, so if you set checkpoint-a, then scroll/zoom to somewhere else (and maybe set other checkpoints), you can then hit the binding to return to checkpoint-a and be returned to that location and zoom level.

Checkpoints have been implemented in "brain-code" only so far, but I'm imagining them using two prefix bindings. MOD+Shift+c followed by any letter/number to create a checkpoint, and MOD+c followed by any letter/number to return to that checkpoint.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

@Trilby - Thx for the tip on fullscreen keybinding, but it doesn't work quite as expected. When you click on a video's fullscreen button, scrollwm gives you a little box in the upper left--like starting firefox or chromium--and mod+f (myfullscreen), either before or after you pick a fullscreen video, gets rid of the bar but you get the little window which you then need to resize wiith mod+button3. Also, being me, I accidentally hit mod+f once with no window opened and it crashed X.

I can get about the same mileage just toggling the bar with mod+a and then resizing the little box so I don't know if I'll bother to keep that keybinding. Look forward to your ideas when you get back. Hope your parrot handles you out of town better than mine did--when I had him.

edit: Just noticed that scrolling windows doesn't work for me now. Just in the off chance it had something to do with the myfullscreen keybinding, I removed that bit and rebuilt but that had nothing to do with loss of zooming windows. Something else to check when you get back.it was just my numlock key--gotta remember to turn it off using scrollwm or take it out of my .xinitrc, but I am finding the zoom/scroll is working erratically at times on this end.

Last edited by bgc1954 (2012-12-14 19:33:30)

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

I have not had time to really look into this fullscreen video thing yet - though I definitely will, that is something I use to. For the time being though, that temporary "fullscreen" kludge can be prevented from crashing by adding a single test as the first line of the function:

if (!focused) return;

I've also added configurable border widths. I'll also be adding configurable "gap" space for tiling modes - so it can even be removed. I've also just implemented the status reader capability. This is similar to rectabar and ttwm's status setup, but simplified.

Better documentation will be coming, but for now either send data to scrollwm's stdin, or (preferably) launch scrollwm with the name of a program or script that generates status data as scrollwm's command line argument.

The status program/script should generate a line of text for each statusline update (a trivial bash example follows). Aside from text, you can set colors with sequences like the following:

this is default color text, {#FF0000}this is red text, {#0000FF}and this is blue

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Forgot to mention: BGC, if you don't like that mouse move/resize option without the mod key, you can just comment out or remove the mouse binding from the config.h. They are the ones with "0" for the modkey that call window("move") and window("resize").

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Thx for some more tips Trilby. Being out of town and supposedly out of touch--not. My status script from ttwm works fine here and border width option is nice. Could we later see an option for bottom status bar like in ttwm?

Last edited by bgc1954 (2012-12-16 01:31:30)

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Yup, bottom status will be on the way.

I'm about to push the checkpoints to git. These seem to work very well with scrolling around the 'large desktop', and they seem to work OK with zooming - but I think I need to fine tune the latter. Checkpoints use a "prefix" type key. With the default binding this is MOD+c followed by any alphanumeric character to go to a checkpoint, and MOD+Alt+c followed by any alphanumeric character to set a checkpoint.

By default there are 6 checkpoints set. Checkpoint 1 is the inital starting point. If you scroll or zoom around the desktop then hit MOD+c 1 you'll be brought back to the starting poition and (close to) the starting zoom level. Checkpoint 2-5 are full screenheights below 1 - so it is a vertical line from 1 to 5.

Checkpoint 0 (Zero) is actually the same as checkpoint 1: the original position and zoom. But checkpoint zero can't be reset. All other checkpoints can be set wherever you like using MOD+Alt+c followed by a character to associate with it.

In effect checkpoints can be used like workspaces are used in other window managers to switch between collections of windows.

EDIT: you can now choose (or toggle) the status bar to be on the top or bottom of the screen.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Changes seem fine except the config.h setting for topbar. Even when I select topbar False, I still get a topbar. It toggles fine so I can place it on the bottom but it just doesn't start that way.

edit: just noticed that I have to hit the key combo to move the bar from top to bottom twice--the first time--then after that it moves on the first hit every time. Also, mod+a seems to have quit working here--can't hide the bar.

Last edited by bgc1954 (2012-12-16 19:43:03)

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

The topbar issue was my fault. I added the toggleable option, but I forgot to have the initialization code check it on startup - so regardless of the value of 'topbar' it was on top. Then when you toggled it the first time it set topbar to True (aka top) and drew the bar there (where it aready was). This should be fixed now.

I'm not sure why the hidebar binding wouldn't work. Unlike ttwm (and most tiling WMs) hiding the bar will not retile or shift the windows, but toggling the bar is working here. I can take a look to check what could be going wrong, but since it works for me I'm not sure where to start looking.

Also, you'll note a new (currently very ugly) indicator on the statusbar between the overview icon and the title. This is the "target mode" indicator. Scrollwm can be in several different target modes: screen, tag, visible, or all. This determines which windows are included in window cycling and tiling commands.

For example, you can use any of the tiling bindings in the screen target mode and it will only tile those windows in the currently viewable range (defined by windows who's *center* are on screen). This will not tile windows on other parts of the desktop. This - along with the default checkpoints - allows for something much more like traditional workspaces while still keeping the single large scrollable workspace.

BGC, can you explore any of the pattern to the failing toggle-bar? Does it work with topbar=True? Are there any conditions in which it works and others in which it fails?

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Trilby: One step at a time, I guess. Now toggling bar from top to bottom works a treat without the initial two hits of the key combo, but I'm finding that setting topbar to False in config.h gives no bar at all now. I am pleased to tell you, though, that hiding the bar now works.

edit: I think that hiding the bar might have been on my end as when I built scrollwm yesterday, I got a defined but not used error which I didn't pay attention too, since I had commented out those mouse+button outside window actions, then today I got a couple of errors so I totally redid my .scrollwm_conf.h--too many new additions lately. Funny thing is I didn't pick them up using sdiff...oh well, you're not the only one who can make a mistake.

edit2: Just double-checking on my netbook and I can confirm that the bar doesn't appear if you set topbar to False.

Last edited by bgc1954 (2012-12-17 17:08:29)

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

That's pretty cool. Would it be possible to implement an overview that displays the location, outline and name of all open windows? Maybe depending on the "target mode" show only windows by screen, visible, tag, or all. Then you could look up the window position and move there with the scroll gestures.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Another request, if I could, would be to change the config.h slightly so that someone like me--old dog doesn't like new tricks--who can already use the Alt key instead by changing the #define MODKEY Mod4Mask to Mod1Mask, but there are many instances where the existing Mod1Mask needs to be changed to Mod4Mask. In my .scrollwm_conf.h, I already use a #define MOD2 to switch the Alt to Super but anytime there are large changes to the config.h, I can miss things and thus my previous likely error for the hide bar. So, for me, it would require less typing--thus less likelyhood of typos--if I copy over the config.h to replace my .scrollwm_conf.h if something isn't working quite right--lazy, huh.

I also need to do this out of necessity for my old thinkpad as it has no so-called "Super_windows" key so I really have to mix up the key commands.

Last edited by bgc1954 (2012-12-17 20:48:16)

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

progandy wrote:

That's pretty cool. Would it be possible to implement an overview that displays the location, outline and name of all open windows? Maybe depending on the "target mode" show only windows by screen, visible, tag, or all. Then you could look up the window position and move there with the scroll gestures.

This is actually something I had in mind a while back, and it is on the todo list. Basically a more 'advanced' window switcher/cycler. I do have plans for something like this - but it is not high on the list. I'd prefer to focus on getting the core functions more stable for a while ("while" may be about a month or two).

EDIT: @bgc, that is a simple enough and worthwhile request. For the next push I'll put two MOD definitions: one which will be Mod4Key by default and the other Mod1Key (alt) by default. But these deinitions could be changed without modifying each individual binding.

p.s. I also just added a "fullscreen" function which hides the statusbar and fullscreens the current window. This would work for the youtube or other video popup fullscreen windows, but it does require a keypress. Eventually this could be automatic, but this would require EWMH/NET_WM compliance which I will eventually implemented, but to be blunt I'm not a fan of it, so I can't get enthusiastic about making that a priority.

My polemic mini-rant: programs should check whether they are running under a EWMH compliant WM before just assuming they are. I wrote an app that fullscreens it's main window, and it checks whether it is under a EWMH wm and adjusts accordingly. This is much easier to do at the client side than at the window manager side. If some program creates a window that is supposed to be fullscreen, but sets the _NET_WM_FULLSCREEN_ atom and just assumes the WM will handle it, then this should be reported as a bug to the writers of that client program.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Excellent! Just on my netbook now and changing my .scrollwm_conf.h was easy as pie. Thx Trilby. The fullscreen action works well and AFAIC that's enough for me. A keypress is a small thing for a user to do rather than having something in the ether do it all for you--after all, that's likely why we all use linux in the first place.

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

I just implemented all the dirty work for a window-list/switcher. This is bound to Alt+Tab in the default config.

This list only shows windows in the current "target mode". "Screen" is the initial or default targetmode, meaning only windows currently visable on the screen are listed. "Tag" and "Vis" are other target modes, when either of these are engages, they will be displayed in the status bar. In tag targetmote, all windows in the currently selected tag will show up in the switcher (or in window cycling), and in Vis(able) all non-hidden windows will be included. There is also an "all" target mode, but I don't have default bindings for it, and I don't know if it will stick around. Switching focus to a hidden window doesn't make much sense. So hidden windows will likely remain hidden until their tag is unhidden.

I say I've implemented the dirty work as all the functional components should be in place. I'm going to work on the aesthetics a bit and likely include other information in the listing, like tag memberships, and location indicators (where they are relative to the current viewport). Perhaps even icons ... perhaps.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Saw this on the first page:

"Known bugs:- Programs such as firefox that depend on window managers setting the window size on startup show up too small. - The solution is known (full ICCM compliance), but has not been implemented yet."

You need to watch for ConfigureRequest events to have apps like firefox open at the right size, no need for iccm stuffs.

Re: ScrollWM - floating WM with scrolling workspace (and tiling!)

Yep, firefox and even some java apps that were starting really small all work ok now. I can use either mod+f or mod+a to get rid of the bar so the start,pause,progress bar show in fullscreen video. Have you had a chance to see why the bar won't show if you put topbar False in the config.h?

Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz