fuhsjr00 / bug.n

Tiling Window Manager for Windows
GNU General Public License v3.0
3.35k stars 214 forks source link

Dead links to tutorials #207

Open kheaactua opened 5 years ago

kheaactua commented 5 years ago

I keep coming across links to tutorials which are dead links, for instance, at the bottom of this page

Tutorials would really be helpful, as I've just wasted an hour just trying to move windows from one monitor to another, and have to give up and get back to work :(

Other than Config_syncMonitorViews, I can't find much info on what to do with multiple monitors. And what's the numbering of the monitors?

joten commented 5 years ago

I removed the dead link from the tutorial in the wiki; it only referenced the repository the tutorial itself was copied from.

The hotkeys regarding monitors can be found in doc/Default_hotkeys.md. To move the currently active window to the next monitor you can use WinShift..

There is not much you can do with monitors in bug.n; they are more or less an external dependency. The numbering is retreived by AutoHotkey via SysGet; no choice here either.

kheaactua commented 5 years ago

Okay, thanks for removing the dead link.

I think one issue I had with moving windows is that the decor was off, and different apps act differently with that (I could move my VS2017 window but not my VS2010 window.)

I suppose the learning curve is simply really steep. I've gone through the docs several times now, and tried the example configs, are there really no tutorials? Or is there any validation on the config file lines? I tried for two hours to get my Config_rules to put my mintty, VS, and Eclipse Windows into a monocle on my monitor 1 (or just the same monitor), and despite having the same settings, they'd appear on different monitors, and I have no idea why.

joten commented 5 years ago

Sorry, there are no more tutorials than the one in the wiki, nor does bug.n currently do much validation or error handling -- just the basics to get it running.

What rules have you set? If the windows are handled differently it might be that the part identifying the window does not match.

kheaactua commented 5 years ago

I think I was trying to same rule for all Visual Studios:

Config_rule_#1=.*;.*Microsoft Visual Studio.*;;1;1;1;0;0;0;maximize

which, I understand as, "Match any class of windows, with the Microsoft Visual Studio in the title, place o Monitor 1, View 1, consider it managed, and maximise it.", but it was either ignored, or working differently for different VS versions. I also couldn't get my msys and Eclipse windows to behave the same was as VS even with the same config, etc..

How much does the order of config options matter, and, from the docs, I wasn't clear whether I need to number to rules (e.g. _#1) or if Bug.n would handle that automatically.

I'm hoping to use Bug.n though, because if I understand right, it can help me hide the Interactive Service Detector popup that appears every 40 seconds on my screen and is driving me insane :)

Also, because of the Config file, I was hoping to sort of set up a "session" like I would in tmux, i.e. I always have some IDE open that I want maximised on one monitor, and then some other apps to run the code, and because it's Windows I need what seems like 50 explorer windows open where I can spend most of my day alt-tabbing through, some consoles, and some floating browser windows. It'd be amazing if all these windows just knew their place.

Thanks for any help, I'll try to play with Bug.n more today. I bet once I get it it'll really help me out.

joten commented 5 years ago

bug.n applies rules in reverse order, i.e. beginning with the one with the highest index applying the first match. Therefor Config_rule_#1 is the last rule, which is considered and serves as a default rule. Only use an explicit index, if you want to replace the behaviour for a given window. Therefor you should add Config_rule=.*;.*Microsoft Visual Studio.*;;1;1;1;0;0;0;maximize to your Config.ini. Rules do not have to be numbered explicitly; bug.n appends the rules from Config.ini, which are not indexed, in the given order to the 'array' of existing rules.

If you set a rule for the "Interactive Service Detector" pop-up with a specific view and have Config_onActiveHiddenWnds=hide set in your Config.ini, you should be able to suppress the window, but I think it will flicker. I guess it does not make sense to close the window directly.

bug.n does not start applications from a session file; you could start the applications via Windows Autostart or running bug.n as a script utilizing the Run command for starting the programs and have bug.n set the windows created this way to different views via rules.