fuhsjr00 / bug.n Goto Github PK
View Code? Open in Web Editor NEWTiling Window Manager for Windows
License: GNU General Public License v3.0
Tiling Window Manager for Windows
License: GNU General Public License v3.0
Hi,
i am using Bug.N in a dual-monitor (24", both run FullHD resolution via DVI) setup on a Windows 7 SP1 64bit, local user is running as administrator, i am running the application "run as administrator" as well. I provide a path to the application and i have write access there.
Since 20141031_bug.n-dev Bug.N is not usable anymore since windows seem to constantly change the focus, it is flickering and i cannot select any windows. Stopping Bug.N via the taskbar icon works (fortunately).
20141213_bug.n-dev shows the same behaviour, i am currently working with 20140930_bug.n-dev.
How can i provide more useful infos? Since i cant seem to attach the files directly, i uploaded my log.txt (http://pastebin.com/raw.php?i=MBe1v5q3) and my Config.ini (http://pastebin.com/raw.php?i=t6Kwrcrp).
Other programs that i am using that might interfere are launchy (http://www.launchy.net/) and InputDirector (http://www.inputdirector.com/), though Bug.N seems to struggle the most with IBM Lotus Notes.
Thanks for such a great piece of software, using i3wm on linux, Bug.N makes windows somewhat comfortable :)
Hi. I use "bug.n" always.
I love this tool.
I was not able to manage Chrome from yesterday.
Windows Google Chrome Version
34.0.1847.116 m
ID: 0xd041a
class: Chrome_WidgetWin_1
title: New Issue · fuhsjr00/bug.n - Google Chrome
process: chrome.exe
style: 0x17CF0000
metrics: x: -4, y: 8, width: 1608, height: 1168
tags:
Thank your for reply.
I was very happy with bug.n on Win7 at work. I had to install Win8.1 at home, so bug.n was one of the first thing I installed, and it behaves very badly. :^(
Has anyone succeeded in having bug.n work in Win 8.1?
Firefox, when the view contains only it and it is maximized, only fills in the space left by the taskbar and the status bar, regardless whether they are hidden or not. Only when not maximized does it fill the whole screen. So I wonder if there is a way to force window not to maximize.
There is a conflict between the two active window managers:
Sometimes switching a view from an empty view to a non-empty view causes a monitor switch. This one can't be reproduced as reliably as the previous case.
#,
hotkey#Up
and #Down
. I can't recommend a specific pattern.#.
hotkeyObserve: Sometimes the active monitor will switch back to monitor 1.
The active monitor should not change, and the window activated should be the active window for the non-empty view on monitor 2.
DONE
Observe: Focus will now instantly switch back to the "master" window on monitor 1.
This makes it impossible to work on another monitor without using the Hotkey for Manager_activateMonitor(1) and Manager_activateMonitor(2) everytime you want to change between monitors.
It would be more comfortable if I just got the window I clicked on on the other monitor as active.
Observe: Monitor focus changes back to monitor 1. This happens regardless of whether the closed window was the last window in the view.
I think that the behavior should be to stay on the empty view on that monitor until the user explicitly changes monitor or view.
Remainder of the original post:
Hello,
I am not sure this is the right place to write stuff but I didn't find a better one.
I don't know if the following is intended behavior or not but it feels weird so I mention it.
[bug report, see above]
Another question: Is it possible to make bug.n automatically focus windows on mouseover (like xmonad does for example).
I didn't find anything about this in the documentation but I might have missed something.
Thanks for this program, it makes Windows bearable to work on.
Check it out : http://www.cheatography.com/gamer204/cheat-sheets/bug-n/
I am using Windows 8.1 64-bit with GNU Emacs 24.4 64-bit Windows binary.
The problem is when I create new frames with C-x 5 2
, all the resulting new frames have a top margin shown in the screenshot.
The only one without that margin is the original frame opened with runemacs
, the second in the stack.
Should be Config_hotkey
Hi, i have a 3840x2160 monitor with windows 7 running with 150% scaling and only seems to use roughly half of the screen, it never maximizes windows larger than what looks like 2400x1500 in the upper left corner.
Import from berliOS:
Date: 2012-Jul-02 06:31
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 5
Bug Group: None
Resolution: None
Summary: Unexpected monitor focus changes
There are a few places where monitor focus changes unexpectedly (I believe).
Case 1: When the last window on a view is closed in a multi-monitor
setup, the active monitor is switched to another monitor.
Expected: I think that the behavior should be to stay on the empty view
on that monitor until the user explicitly changes monitor or view.
Case 2: Sometimes switching a view from an empty view to a non-empty
view causes a monitor switch. This one can't be reproduced as reliably
as the previous case.
Reproduce steps (assume 8.2.1 default hotkeys):
Observe: Sometimes the active monitor will switch back to monitor 1.
Expected: The active monitor should not change, and the window activated
should be the active window for the non-empty view on monitor 2.
2012-Dec-05 01:40 fuhsjr00
I've submitted the suggested fix for case 1 at r145:dc91cfafb64c. I
think it agrees with the former behavior of bug.n much better.
I can still frequently reproduce case 2.
2012-Dec-04 04:07 fuhsjr00
I think this fixes the problem in a way that clashes with the original
flow of the system. I used to be able to change the active window with
the mouse. Now I can't. In fact, bug.n somewhat violently resets the
window.
I think an approach that would work better would be to, on close:
This might keep the monitor/window focus from unexpectedly changing
without forcing the user to use the hotkeys to navigate.
2012-Dec-01 21:44 joten
This should be solved. If there is still a problem this ticket can be
re-opened.
2012-Oct-16 18:12 joten
I changed the behaviour of bug.n. Instead of changing the monitor
accordingly to the active window, the active monitor is maintained and
the active window set accordingly.
2012-Oct-14 18:47 joten
I could reproduce case 1.
The problem might be that Windows activates the next window in the stack
and bug.n resets the active monitor accordingly. I will have a look into
it.
I could not reproduce case 2.
2012-Oct-13 19:54 joten
I will try to reproduce the problem.
2012-Jul-02 06:43 fuhsjr00
Case 1 should be adjusted to indicate that killing a window on one
monitor can, in any case, cause the active monitor to change.
Reproduce steps:
Click on window on monitor 1. Click on window on monitor 2 and close it
via "#c".
Observe: Monitor focus changes back to monitor 1. This happens
regardless of whether the closed window was the last window in the
view.
When running bug.n in an environment with display scaling on, it doesn't handle it well, and most of the bar is off screen.
Windows 8.1, 64 bit
Enable display scaling in Windows. There are two kinds
a. Enabling the "size" of elements option, from smaller to larger
b. Enabling the "Let me choose one scaling size for all monitors" option, and setting that to a percentage greater than 100%.
Start bug.n
I would enjoy a way to force the re-tiling of a window when its position is bad. It happens regularly when windows change their own position and do not e.g. take well into account the taskbar that I use vertically.
My main example: when the Delphi IDE switches to/from execution mode, it resizes itself, and becomes too large for the workarea.
My current workaround:
#+d
to show the bar#+f
twice to force it to be retiled from a non-fullscreen positionSome details:
#+f
twice doesn't work. It seems that when already thought well-tiled, re-tiling does nothing, so I have to force a resize first. This solution would be enough for me if it worked.#+s
doesn't work in this case (cursor ok but window refuses to resize), so I have to use the show-bar + click thing. I don't know why; it usually works.What do you think about memorizing window informations, when we open this window instance (after it didn't exist) it would just be placed where it was last placed (memorized) !??
We would need a way to distinguish between different window instances.
By that I mean: If we had two editors with different files and we wanted the first to be on the first view and the 2nd in the 2nd. After a computer reboot, for example, when we first open the editor to the first file, it would be nice to have this window immediately placed in the first view as memorized.
Same thing for the 2nd window but in the 2nd view (as memorized).
We would need to distinguish between the two windows.
The title (+ class id, + process) would be good candidate for this, but it must not change when the process is loading the window.
What do you think about window position memorization and how would it be possible to implement it ?
Hi, bugn.exe on my system uses up most of the resources of one core, though seems to be working and responding well. Is this normal? If not, is it possible to see what's might be keeping it busy in my case, i.e. enabling logging of some sort?
Would be great for attracting new users. Or even a video.
Import from berliOS:
Date: 2013-May-19 23:24
Submitted By: fuhsjr00
Assigned To: joten
Category: None
Priority: 8
Bug Group: None
Resolution: None
Summary: bug.n can hang on ResourceMonitor_getNetworkInterface
I'm running a completely clean version of bug.n tip (161:7ce56a6850b6)
with no config file on Windows 7 Professional.
When I start up bug.n, it hangs in the call to
ResourceMonitor_getNetworkInterface and more specifically in the
following loop:
Loop, % NumGet(ResourceMonitor_networkInterfaceTable)
It never gets past the "Continue" line. I haven't done much
investigation beyond this. I'm going to disable the call to
ResourceMonitor_getNetworkInterface until this is resolved to keep the
tip build working for all.
2014-Mar-04 21:02 joten
I revised the parts of ResourceMonitor.ahk regarding the network load.
Please give it a try. You will need to set Config_readinNetworkLoad to
an identifying string for the interface, which should be monitored, e. g.:
Config_readinNetworkLoad=Wireless
or
Config_readinNetworkLoad=Qualcomm Atheros
2014-Mar-04 02:32 fuhsjr00
I have nothing special set up on my dev machine. It's using a pretty
standard on-board ethernet adapter. If you can't reproduce the issue,
then we can close it, and I'll investigate again if I run into it.
2014-Mar-03 18:20 joten
I tested rev. 161 and the current one, completely clean on Windows 8.1
(Notebook with activated WLAN and deactivated LAN ; no problems beside
bug.n not recognizing the right network interface (maybe the loopback
adpater). I think I ran rev. 161 of bug.n on Windows 7 Pro, too, without
any problems.
Do you have any special network configuration?
If Outlook 2013 is running, I will eventually have focus problems with bug.n. The most common is that either Outlook cannot be focused, or Outlook will grab focus and not let it go. Occasionally there are other weirdnesses, such as Outlook composer or message windows re-opening themselves after being closed. Restarting bug.n may solve the problem for a while, but not reliably. Exiting Outlook always solves the problem.
I don't have very useful debugging information on this, but if you'll tell me how to gather some, I will.
I find that temporarily hiding a window can still be handy even in a tiled WM (where is it anyway a lot less necessary than in the standard WM). Hiding a managed window is currently a bit awkward:
I propose two ways for managing hidden windows (I suspect the second is simpler to implement):
First reported in #26: but investigated a bit further:
Config_hotkey=#t::View_toggleFloatingWindow()
does not work (my initial feeling that "#t
cannot be rebound" was wrong, no key will work).
There doesn't seem to be an option to set the background of the bug.n bar to a custom opacity. Is this a technical limitation or by design?
using latest dev exe from eb4395f
trying to reload configuration using #^r::Main_reload()
gives this error:
full reload with #^+r::Reload
works fine
Using bug.n and really happy with it, but often i'll find a program that will completly ignore bug.n's placement like Naver Line's chat program, not only will it show in all desktops but it won't resize or organize. Any way to fix this?
Thanks
Since after feb 17th, especially with the feb 23th commit,
Visual Studio 2012 (.NET WPF) apear on all views of a monitor.
Sometimes my xplorer^2 too, by when I terminate it, then restart it it appears to fix this.
Google Chrome sometimes do the same thing...
A more mouse friendly interface or non Super key dependent hotkeys would be nice.
Another issue is that Config.ini is created with a Super key shortcut, which makes it increasingly difficult to change that.
Config_rule_#1=.*;.*;;1;0;0;0;0;0;
By default all windows are managed, not allocated on a specific monitor or
view, not floating (i. e. tiled), the window title bar is not visible, the
title is not hidden on the bug.n status bar and no window action is taken, when
the window first is created.
The parameter responsible for window title bar is actually next-to-last.
Hello,
Is there a mailing list, a forum, an IRC canal where I can speak with the authors ?
Regards.
With two adjacent screens, is there a way to maximize a window so it covers both screens?
Thanks for your consideration,
Christian
not sure if this is related to #27, but possibly. I'm using the latest dev exe from from eb4395f
some applications, most notable Outlook 2010 and primarily Lync have an issue there after some indeterminate time an invisible window is tiled.
win+i
while focused on the empty space gives me this information in an about box with a lot of blank space:
ID: 0x3006c
class: Progman
title: Program Manager
process: explorer.exe
style: 0x96000000
metrics: x: 0, y: 0, width: 4890, height: 2160
tags:
Config_rule=Progman;Program Manager ;;0;;;;;0;
as you can see in this screenshot:
A window that is run as administrator prevents to change view, as if it could not be left for a normal window.
A fix consisting of not managing elevated windows would be ok for me. For processes that I always run as elevated (as ProcessExplorer) I can add a rule for that. However, for those that I can run both ways (such as a debugging environment or a console), the rules do not enable to tell the elevated case apart.
My current workaround is to reload a modified config.ini that stops managing the windows that I want elevated. When all are closed, I resume my usual config.ini.
This is for version 8.3.1, as version 8.4 does anyway work badly for me with respect to focusing and view-changing behaviours.
I have an AZERTY keyboard, and the #<n>
key binding does not work as the number keys above the letter section are not assigned to the same characters. 1
, 2
, 3
, 4
, 5
, 6
, 7
, 8
, 9
and 0
triggers respectively &
, é
, "
, '
, (
, -
, è
, _
, ç
and à
in such a layout.
For the moment, I modified my Config.ini
in order to make view/tags key bindings work, but it would be great if bug.n automatically detects the current keyboard layout and loads the correct key bindings.
(I don't have access to my modified Config.ini
while writing this, but I will add it toworrow)
Maybe linked with #53
Hello,
I believe there is a misstaken copy + paste in the documentation here:
https://github.com/fuhsjr00/bug.n/blob/master/doc/Default_configuration.md line number 177:
"
Config_layoutGapWidth=0
If true (=1), the system battery status is read in and displayed in the status bar. This only makes sense, if you have a system battery (notebook).
"
Import from berliOS:
Date: 2012-Oct-26 17:35
Priority: 5
Submitted By: jbremer
Assigned To: fuhsjr00
Category: None
Status: Open
Summary: Hidden Window View
Date: 2012-Dec-01 21:41
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
'hul!' was not implemented in version 8.3.0, but a solution
for the problem of lost windows is in development ([ Bug
#18649 ] Window can be lost).
Date: 2012-Oct-26 18:12
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
That more sounds like a bug -- like [ Bug #18649 ] Window
can be lost. But I could not reproduce this behaviour.
By design, it should not be possible to remove a window from
a view, if this view is the only one the window is on.
But I know of the problem from the beginnings of bug.n, when
I wrote another script, 'hul!' [
http://www.autohotkey.net./~joten/hul.html ], which can
restore lost windows. I already planned to integrate it into
Debug.ahk of version 8.3.0.
Date: 2012-Oct-26 17:35
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
As far as I can tell, there's no way to get hidden
windows back.
So my suggestion is to add view zero, accessible
through the #0 hotkey, which contains all views which
would otherwise be hidden.
E.g. my firefox window may at some point be in two
views, then I delete it in one of the views, and I
accidentally remove the window in the other view as
well (true story), so now I'd like to get it back.. in
view zero.
Or, if there's a better solution, than that's fine with
me as well.
👍
Import from berliOS:
Date: 2012-Jul-02 06:02
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 5
Bug Group: None
Resolution: None
Summary: Window can be lost
There is a sequence of actions that can cause bug.n to lose a window (no
longer displays it).
#^2
, #^1
(Monitor_setWindowTag(2), Monitor_setWindowTag(1))Found:
Neither view 2 nor view 1 show the window. A dump of the windows on 2
will reveal that it has an ID, but it's not correct (looks like a digit
gets removed from the end).
Expected:
The view should stay on 2. The assignment to view 1 should have no
effect since the view is empty.
2012-Nov-26 00:26 fuhsjr00
One more thing to note: When I stop bug.n, fixup semicolons in the
_WindowState.ini file, then start bug.n, all missing windows show up in
their correct views.
2012-Nov-26 00:24 fuhsjr00
I can still reproduce this readily. It also seems that it causes windows
on other views to disappear.
Now that I get a dump of the current window state every 5 seconds, I see
this:
View_#1_#1_wndIds=0x20672;0x404fa0x304cc0x301ee;0x3026c;0x30368;
View_#1_#2_wndIds=0x110570
View_#1_#3_wndIds=
View_#1_#4_wndIds=;0x8505c8
View_#1_#5_wndIds=0x10630
View_#1_#6_wndIds=
View_#1_#7_wndIds=
View_#1_#8_wndIds=
View_#1_#9_wndIds=
View_#2_#1_wndIds=0x203f6;
View_#2_#2_wndIds=0xf0560;
View_#2_#3_wndIds=0x190484;
View_#2_#4_wndIds=
View_#2_#5_wndIds=
View_#2_#6_wndIds=
View_#2_#7_wndIds=
View_#2_#8_wndIds=
View_#2_#9_wndIds=
Note that the formatting for some of those views looks really messed up.
Lots of missing semicolons.
2012-Oct-14 16:20 joten
I could not reproduce the problem.
#3
/ #1
#E
-> Explorer on view 3 / 1#^2
#^1
The same with the current development version.
2012-Oct-13 19:55 joten
I will try to reproduce the problem.
First mentioned in #26 but precised here.
I work with two monitors, synchronized by Config_syncMonitorViews=1
.
#y
from any monitor pops it up on monitor 1 (which would be acceptable for me). Clicking on the bar shebang only works on monitor 1.#y
, the command windows pops up under the window, so it practically works only when the view is empty. I think it is under because sometimes I can see the flicker; maybe it just closes quickly.When I open a few new tabs with Ctrl+t in Chrome, bug.n sometimes detects a new window. This leads to a split in the tiling view with the active region empty.
When I focus a different Window or open a website in the new tab, bug.n detects the mistake and resizes chrome again.
If you need further information please ask :)
This commit makes about all of the hidden windows of my system to become visible windows.
The taskbar becomes full, #+i also list them all.
This is probably due to bug.n trying to communicate with the window while it cannot respond since it is under debugging
Hi,
Please can you add developer documentation on "how to debug" and "how to build the project" ?
I'm very interested in this project but I'm totally noob with autohotkey and I don't know how to start.
Thanks
When using bug.n with a multi monitor setup my secondary monitor permanently displays 'CPU: 0%' for readinCpu on the bug.n bar. This is happening on windows 7 where all of the other readin displays work correctly.
Import from berliOS:
Date: 2013-May-20 01:40
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 6
Bug Group: None
Resolution: None
Summary: bug.n window list leak
If monitoring %APPDATA%/bug.n/data/_WindowState.ini
, you'll notice that
it slowly grows over time.
Normal windows that are controllable by bug.n seem to get added and
removed as expected. However, pop-up windows (such as Win-R) get
recorded in the window list and stay. This also means that the window
forever remains in the internal Manager_allWndIds list because this is
exactly what is being dumped to _WindowState.ini.
I'm able to eventually get bug.n to saturate a core (_WindowState.ini
was around 260 lines with Config_maintenanceInterval set to 100ms). Once
this happens, bug.n is virtually unusable. However, the window count
doesn't seem to be the only factor because I can restart bug.n and see
CPU consumption fall back down to 1-2% with the same _WindowState.ini file.
Work-around:
Exit and restart bug.n. The _WindowState.ini file won't get smaller, but
the application may become usable again. If your WindowState.ini file
is ridiculously large, it is safe to delete window entries that don't
appear in the View* list. The windows of interest will not have
descriptions.
2014-Mar-05 21:11 joten
The problem might indeed be the use of Manager_allWndIds. This list
first was intended to allow restoring of windows, when bug.n crashed and
unintendedly left windows from an unvisible view hidden; therefore every
window is listed.
I added a comment in front of Manager_sync regarding Manager_allWndIds.
Manager_managedWndIds is used in Manager_cleanup, which previously
served a similar (but one sided) purpose as the session management.
Perhaps managedWndIds should be used in this case, too (?).
The questions also might be, if Manager_allWndIds is really used
anywhere in the current code rev.
Read in volume
The default Windows taskbar shows battery, volume (approximated and whether or not it's muted), and time. The bug.n bar replaces most of these and adds disk, CPU, memory, and network readings.
I think that volume is a natural extension of this.
Use SoundGet
Could display a bar similar to the battery bar with "VOL: 00%" and maybe when muted "VOL:MUTE". That, or display a different color when the volume is muted, as technically you still have a volume level. So it could be "VOL: 50%" in a color, then when muted it could keep that text but display a different color. This runs the risk of mal-configuration leading to a bad user experience, though.
Then the config line could be something like Config_readinVol=1
Import from berliOS:
Date: 2011-Oct-04 17:41
Submitted By: djsumdog
Assigned To: fuhsjr00
Category: application compatibility
Priority: 5
Bug Group: None
Resolution: Later
Summary: Remote Desktop windows do not resize/position correctly
I've had some trouble with bug.n and Remote Desktop. If remote desktop
starts as full screen, I realize that is a problem. But even if I tell
it to start in a scaled window, bug.n seems to incorrectly determine the
window size and either give it a really small area or have it overlay
all the other windows.
I've tried using other remote desktop tools like Remote Desktop Manager
and Terminals, but they all use the standard windows libraries for RDP
and render to the screen the same way.
Also, when I open sessions in a window, over half the time the remote
machine will not receive mouse or keyboard events. Occasionally the
mouse cursor I see is 100 or so pixels off from where the event
registers on the remote machine. There is no way to send events to the
machine without first quitting bug.n
Operating System: Windows 7 64 Ultimate
Resolution: 2x 1920x180 monitors
2012-Nov-24 15:47 fuhsjr00
You can configure RDP to capture hotkeys when not in full-screen mode.
When I do this, I'm completely unable to interact with bug.n until I
change focus to another window with the mouse.
I've not seen any rendering problems with RDP, but I usually use RDP in
mono mode.
2012-Mar-27 19:36 tammeri
Hello,
I was experiencing the same problem, until I discovered the Window Rule
feature. I included this rule in my Config.ini:
Config_rule=TscShellContainerClass;*;;1;1;0;1;1;0
Now the remote desktop app (mstc.exe) works as expected! If fullscreen,
the remote desktop takes over the keyboard and mouse. If windowed, the
window works as a managed floating window. Has saved me a lot of
headaches!
2011-Oct-06 13:31 joten
I am not sure I can build a test environment for this; but I will see.
Regarding the second problem, I can imagine, that there might be a
conflict, which will be difficult to solve, since, as far as I know,
both applications (bug.n and Remote Desktop) monitor the keyboard and
mouse input.
Import from berliOS:
Date: 2012-Nov-26 01:28
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 5
Bug Group: None
Resolution: None
Summary: bug.n does not handle display changes well
To start, the configuration that I'm immediately interested in is a
dual-monitor (1680x1050) system connecting to another dual-monitor
(1920x1080) system via RDP.
If I attempt this forcing the local RDP resolution to 3840x1080 it
works, though somewhat awkwardly. If I accidentally do something that
causes bug.n to re-measure monitor 1 (#Space), then monitor 1 takes up
the entire 3840x1080 RDP session, and monitor 2 (of the original setup)
is near impossible to use.
If I use the /multimon switch ("Use all my monitors for the remote
session"), monitor 1 will resize correctly (to match my local monitor)
when I do something to indirectly resize it. However, monitor 2 is still
stuck at its original position and resolution.
When I connect a single-monitor (less than 1680x1050) station to the
same dual-monitor bug.n setup via RDP, the experience is awful. Setting
the resolution to 3840x1080 makes everything usable, but extremely
awkward (and suffers from the same resize problem above). If I just use
the full screen single-monitor settings, the second bug.n monitor is
completely unavailable. I think this use case calls into question the
one-to-one "Monitor" to physical display relationship that bug.n
currently enforces.
infos:
Import from berliOS:
Date: 2012-Oct-26 15:51
Priority: 5
Submitted By: jbremer
Assigned To: fuhsjr00
Category: None
Status: Open
Summary: Save Window Layout
Date: 2012-Dec-05 17:35
Sender: fuhsjr00
Logged In: YES
user_id=62445
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Ah, that was my mistake. I was so happy about getting a
working merge candidate that I forgot to option it out. I'll
do that tonight.
Date: 2012-Dec-05 17:32
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
The first test looks good. But no configuration options yet?
Date: 2012-Dec-04 04:52
Sender: fuhsjr00
Logged In: YES
user_id=62445
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
There is support in the repository as of
rev:143:5825bd55a69d for session save/restore.
This should be considered experimental pending more testing.
Date: 2012-Nov-26 12:16
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
This sounds great -- much greater than my proposal; it has
the feature 'restore on failure'.
I think there should be an configurable option for setting
the flavours:
a) off: do not restore and therefor do not save
b) on: do all the magic
c) ask: when restarting bug.n, ask if the session should be
restored (provides safety, but allows a clean start)
Date: 2012-Nov-25 23:14
Sender: fuhsjr00
Logged In: YES
user_id=62445
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
I think I have an experimental version of session saving. It
does the following:
Caveats:
Date: 2012-Oct-31 20:39
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Why didn't I think of that.. (The firefox thingy)
Thanks for the other info as well :) it all makes sense now.
Date: 2012-Oct-31 20:32
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
is managed
: If 0 (false), windows are totally ignored,
i. a. is not tiled or cannot be tagged.
m
: Set the monitor for the window in a
mult-monitor environment.
is floating
: If 1 (true), the window is not tiled
(initially); this can be changed by default with the hotkey
Win+Shift+F.
is decorated
: If 0 (false), the title bar of the window is
hidden.
Firefox on view 1 and 3:
Config_rule_#11=MozillaWindowClass;.*Mozilla
Firefox;;1;0;5;0;1;0
Set the floating layout for view 3 on monitor 1:
View_#1_#3_layout_#1=3
Date: 2012-Oct-29 22:33
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Omg, I was about to ask why my stuff didn't work when I
noticed that instead of a "" wildcard, the wildcard is
actually "." hehe.
Also, would you be able to tell me if there's anything
special to is managed
, m
, is floating
, or is decorated
?
And finally, another question, you mentioned that such
Config_rule entries result in a win+shift+#num
, but would
it be possible to get a firefox instance in two views (e.g.
#1 and #3.) I find this useful as it allows me to have one
view for "stuff" and one view for development (e.g. one view
with only firefox, a terminal, and vim.)
Oh, also.. how do I automatically set a view to floating?
The View_#1_#3_layoutMFact stuff (if related at all) is not
really clear to me, yet.
Again, thanks a lot for your support. I think bug.n is
pretty awesome :-)
Date: 2012-Oct-29 14:44
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
This makes sense, thank you.
Date: 2012-Oct-28 00:05
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
` You'd just have to make sure that there are no duplicate
entries.
Agreed.
It is the "16" = 2^(5-1), a bit mask. The general
description of a rule in version 8.2.1 is as follows:
Config_rule_#i
:= 'class
;title
;style
;is managed
;m
;tags
;is floating
;is decorated
;hide title
'
You need to put the bit mask in the "tags
" position; e. g.
to put a window on view 3 and 5, you need to set tags
to
2^(3-1)+2^(5-1) = 20.
In case of tags
=16 bug.n does the equivalent to
Win+Shift+5 on the window selected by
'class
;title
;style
', i. e. move the window in the
view. As far as I remember there is no option for
simultaniously switching the view; this is only possible for
the manual tagging of the active window (Win+Shift+tag
),
if Config_viewFollowsTagged is set to 1 (True) in config.ini.
By the way there is no irc channel, my quick responses are
just fortunate circumstances ;-)
Date: 2012-Oct-27 19:27
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
That sounds like a good idea (commenting the lines out by
default.) You'd just have to make sure that there are no
duplicate entries.
You showed me an example of a Config_rule entry, but I'm not
completely sure where it says that it should be shown in
view #5, so could you explain a little bit more about that?
(So I can manually set up some rules for now.)
And I assume that when I set those rules up that, when I
start an application which has a rule (e.g. iTunes -` view
#5), that it will automatically "open" the application in
the correct view (perhaps even jump to that view) ?
Thank you very much for your quick responses :)
P.s. is there an official irc channel?
Date: 2012-Oct-26 18:05
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Yes, that would be possible. To keep things easy, I would
add a line (commented-out, i. e. ;Config_rule_...) for each
window, which is managed by bug.n (tiled and floating).
But it would take some time to implement this -- perhaps I
can put it into the release of version 8.3.0 towards the end
of this year.
Date: 2012-Oct-26 17:51
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Ah, that's cool, actually might be even better (to only
hardcode those applications that you really want, instead of
windows which change location/view every 10 minutes; such as
terminals.)
In that case I'd be interested to know if it's possible to
get a macro that does this for you.. ;P
For example that if I hit #p that it will write the line to
configuration (one such as you've just pasted), and that
I'll be able to edit it to make it more generic (e.g. "New
Message - Thunderbird" -` "* - Thunderbird"), so I can hit
What do you think?
Date: 2012-Oct-26 17:25
Sender: joten
Logged In: YES
user_id=60039
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Yes, I have to admit, there is no 'real' session management,
as you described it. bug.n only saves its own session
status, which does not include the running applications.
Therefor, in your case, bug.n saved your previously active
view (2 -- you must have been on view 1) and the master
factor for view 3.
I once thought of 'real' session management, but came to the
conclusion that I could not implement it to my own
satisfaction, since I could restart the executables, but
could not reset the status of those applications (e. g. open
files).
But you can configure bug.n to set specific application
windows to different views by rule. E. g. the following
entry in config.ini sets Claws-mail to view 5:
Config_rule=gdkWindowToplevel;.* - Claws Mail .*;;1;0;16;0;0;0
Date: 2012-Oct-26 15:51
Sender: jbremer
Logged In: YES
user_id=63021
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
I feel very stupid for asking this.. But I've read the
documentation files a few times, and I think I'm
missing something here.. So basically when I hit #^s I
get the following lines in my Config.ini file:
Monitor_#1_aView_#2=2
View_#1_#3_layoutMFact=0.550000
However, since I'm running almost a dozen applications,
this is not going to cut it.
So when restarting bug.n it tiles all applications in a
single view.
Happen to know what I'm missing, or what's going wrong?
(Btw, there's nothing fancy in my Config.ini file that
would mess stuff up.)
Cheers,
Jurriaan
Import from berliOS:
Date: 2012-Nov-26 01:28
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 5
Bug Group: None
Resolution: None
Summary: bug.n does not handle display changes well
There are other cases where display updates might be useful:
2012-Dec-01 21:50 joten
It seems, that you are already working on this problem.
2012-Nov-26 14:26 fuhsjr00
Ah, yes, this bug does cover [ Bug # 18669 ].
"Reload" may fix my most immediate concern, but I'm looking for behavior
along the lines of "do something reasonable automatically", so I'm
probably still going to do something with this.
2012-Nov-26 12:40 joten
The following bu may refer to the same problem: [ Bug #18669 ]
"adding/removing monitors is not recognized".
I'd like to change monitor by giving its absolute number (like Xmonad does). Currently, Manager_activateMonitor(d)
switches relatively to the current monitor.
I have done it empirically on a clone by replacing (in Manager.ahk
) the call to Manager_loop
in Manager_activateMonitor
and Manager_setWindowMonitor
by a version that starts from 1. It works, but I think a proper configurable solution would be nice.
I noticed the nice addition to #i
of the rule representing the current window state.
Is it possible to add ''which'' actual rule was used for this windows? (e.g., "configured by rule 2")
My problem is that I have a rule that doesn't seem to work:
Config_rule=#32770;.*TortoiseSVN;;1;0;0;1;1;0;
It should override rule 3 to let TortoiseSvn windows be managed and floating. It seems well-formed, matching #i
info, but the windows still comes unmanaged. I even tried to make it rule 18 in Config.ahk
, with no success. It worked well in 8.3.1.
I don't know what tools are available to confirm this kind of problems.
Is there a way to customize the date and time format shown in the status bar without modifying the source code/rebuilding the executable? I tried a few things in the Config.ini file, but that didn't seem to take.
Ideally I would also be able to create a time widget that shows time in other timezones, not sure how much more difficult that would be.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.