-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not all screens are disabled #207
Comments
Thanks for reporting this issue. I couldn't reproduce this on my Linux Mint system. I will try further and let you know the fix. Thanks |
I have the same issue. |
Care to ... comment if you looked through same files, what kind of OS do you have, etc, etc? |
|
Two monitors, same issue: only the left one is blocked during the break. Weird, because everything was fine in the previous version.
|
Hi all,
Thanks in advance. |
Well, for me it would have to be Monday ... so enjoy your weekend :-D |
Hi @slgobinath, |
@slgobinath I seem to agree too :/ I will keep this version and "try" to replicate it though in the meantime |
Hi all, To pull the recent change, use |
Small, somewhat rookie question: Which channel would you recommend us following? Also, the debug.log from all that execution (if it helps at all) |
I recommend
Have you came across the same problem later while running the Thanks |
@slgobinath so far no, I consider it to be safe enough. Of course, I'd prefer if all followers gave a +1 and not "depend" on me for that 😄 |
@slgobinath Not meaning to be pushy: When is the merge commit expected to reach apt-get repo? Or is it auto-synced once in origin/master? |
Hi, Today I am going to release the new version. |
Fix released in 2.0.2 (2.0.1 has a dependency issue) but Launchpad is waiting for a day to build :-( |
Hi @stdedos, |
Why do the server has to build it, and not you provide the "packages"? :/ That's a big bottleneck right there ... |
That's how Ubuntu Launchpad works (according to my understanding). |
Hi @stdedos, |
Hi @slgobinath, |
@slgobinath Weird ... neither does it work for me anymore :/ |
Okay. |
I doubt how much helpful I can be, since you already got my
|
@stdedos I made my fix for Unity. That's why I asked again for confirmation. |
@slgobinath I use Unity. |
@slgobinath Unless I take a break from the leftmost screen (1680x1050), there is a one-off issue: |
@slgobinath I may have a bit of information for you .... I was in In that mode, for some reason, a lot of things don't work e.g. Media Player keys. And I noticed something really interesting! My middle screen had actually 2 break windows! Is it possible that, you "somehow" had a fix for it already, and then you broke it by "fixing" it out-of-order? 😛 |
Hi @stdedos, Meanwhile, if anyone is interested, please have a look at the code in between BreakScreen.py:200 - BreakScreen.py:207 which is responsible for moving windows. |
Hi @slgobinath, Unfortunately the latest fix is not working even for two monitors. |
Hi,
The log should contain something like this:
|
@slgobinath IMHO 2.0.5 fixes it correctly. I activated each screen multiple times, and breaks seem to come correctly on the correct screens (see attached log). Is it possible that you log all of these entries regardless? It would've been helpful to log where does your program "gets drawn" in the first place - if you had those entries, then triangulating this would be faster for everyone. And, after all the "schooling" ... thank you for such a helpful program 😄 |
Yea, it might be a good idea to turn on debug mode by default, especially since SafeEyes already uses RotatingFileHandler.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
…On March 20, 2018 10:27 AM, Stavros Ntentos ***@***.***> wrote:
***@***.***(https://github.com/slgobinath) IMHO 2.0.5 fixes it correctly. I activated each screen multiple times, and breaks seem to come correctly on the correct screens (see attached log).
[safeeyes.log](https://github.com/slgobinath/SafeEyes/files/1828651/safeeyes.log)
Is it possible that you log all of these entries regardless?
Log guru's can help you with that, and decide what's best (since I'd do the most stupid thing anyway).
However, if no viable solution exists, at least write them in /tmp/safeeyes-*.log or something - so that we don't have to go out of our way to help you, and we can report happenings on the first try. 10kbs for ~6 breaks don't seem like a waste of Disk/RAM space 😉
It would've been helpful to log where does your program "gets drawn" in the first place - if you had those entries, then triangulating this would be faster for everyone.
And, after all the "schooling" ... thank you for such a helpful program 😄
My eyes thank you
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, [view it on GitHub](#207 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AH9MgZUspdtlRDA0HPdIJOeJI2kbTcFlks5tgMuagaJpZM4QCwcT).
|
Great!!! @tonymihay could you please confirm the fix. Please close this issue if it has been fixed. |
Hi @slgobinath, |
@slgobinath I assume you mean |
It was in older versions. As a solution to this Safe Eyes Debian bug report, writing logs was limited to debug mode and the location was changed to Currently, if you execute Safe Eyes in debug mode, you will get |
I was talking about creating the log file regardless and prune it every week ... but I guess that's a bigger task. |
Pruning is already taken care by the Python logger library I use. |
weirdly this issue affects me again on different laptop and os, now on GNOME. Apart from that, I cannot see the tray icon.
|
Hi @Asalle,
Do you use the kStatusNotifier Gnome Shell plugin? |
No I don't and when I tried to install it, it totally smashed my fedora installation, I think. |
TopIconsPlus also works to an extent but not recommended as it has some issues. Anyway, no tray icon in Gnome is a design decision made by Gnome so we have to go with it. Safe Eyes supports RPC API which can be used in future to develop a Gnome plugin. For the moment, you can control Safe Eyes using command line arguments. Execute |
ok, no icon is not a big issue
|
I experienced a similar issue on Fedora with TopIconsPlus. Do you have TopIconsPlus installed? If so, please disable it temporarily and restart the computer. Then check if you can access Safe Eyes. |
No I don't have TopIconsPlus
|
ok, this may be interesting for you @slgobinath : |
Hi there. $ neofetch
-`
.o+`
`ooo/ dori@xps7390
`+oooo: ------------
`+oooooo: OS: Arch Linux x86_64
-+oooooo+: Host: XPS 13 7390 2-in-1
`/:-:++oooo+: Kernel: 5.5.2-arch1-1
`/++++/+++++++: Uptime: 4 days, 19 hours, 1
`/++++++++++++++: Packages: 1053 (pacman), 4
`/+++ooooooooooooo/` Shell: zsh 5.7.1
./ooosssso++osssssso+` Resolution: 1920x1200, 1920
.oossssso-````/ossssss+` WM: sway
-osssssso. :ssssssso. Theme: Tomorrow Night [GTK3
:osssssss/ osssso+++. CPU: Intel i7-1065G7 (8) @
/ossssssss/ +ssssooo/- GPU: Intel Iris Plus Graphics G7
`/ossssso+/:- -:/+osssso+- Memory: 3279MiB / 31889MiB
`+sso+:-` `.-/+oso:
`++:. `-/+/
.` `/ |
I am seeing a bug related to #121
When I am on secondary monitor according to BIOS priorities (because otherwise ~/.config/monitors.xml has no primary monitor set), Safe Eyes only appears on said monitor.
Blocking or otherwise work perfectly, it's just that one of the monitors (the 'Primary') appears active
The text was updated successfully, but these errors were encountered: