Open nnako opened 4 months ago
I just rewinded to a former commit and discovered that this issue seems to have the same source as the issue#9, which I had closed, hoping that a one-time-reset of my docking station would prevent further problems.
But this "new" state of my docking station seems to be a possible "normal", as all other operating system features concerning the monitor control seems to work properly. Just JigsawWM
doesn't like that and returns a NoneType
object at significant locations.
When I have time, I would try to track down the effect and look for alternative ways to handle the effect. Hoping that this would be a workaround.
@nnako Aah, sorry, I added a method named affinity_index
to the Theme
class for picking the proper default theme for monitors based on Physical Size automatically.
https://github.com/klesh/JigsawWM/blob/f5d457e809562693e2fcf74492790cf0d0b3794d/examples/wm.pyw#L41
You may update your theme configuration by adding the same function or make it optional
Hi @klesh , thaks for your reply.
I added respective parameters affinity_index=...
to the constructors of the Theme
class while building the themes
list in my example file. Together with a variation of affinity_index=...
for my own theme "static_bigscreen_8". The tool now seems to run beyond the point where the last error regarding the "NoneType object" occured. So, the windows are located according to "something", as I don't know how to properly set the affinity_index
for my need in the "static_bigscreen_8" theme. Couold you explain the proper usage of this new parameter?
The other thing is that now, the old error from issue#9 has returned:
Traceback (most recent call last):
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\wm\manager.py", line 142, in _consume_sync_queue
self._sync(init, restrict)
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\wm\manager.py", line 183, in _sync
monitor_state = virtdesk_state.get_monitor(monitor)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\wm\state.py", line 206, in get_monitor
theme = sorted(self.themes, key=lambda x: x.affinity_index(monitor.get_screen_info()), reverse=True)[0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\wm\state.py", line 206, in <lambda>
theme = sorted(self.themes, key=lambda x: x.affinity_index(monitor.get_screen_info()), reverse=True)[0]
^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\w32\monitor.py", line 175, in get_screen_info
if monitor.name == self.name:
^^^^^^^^^
File "C:\Program Files\Python311\Lib\functools.py", line 1001, in __get__
val = self.func(instance)
^^^^^^^^^^^^^^^^^^^
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\w32\monitor.py", line 140, in name
return self.get_info().szDevice.decode("utf-8")
^^^^^^^^^^^^^^^
File "C:\Users\USER\_NEXTCLOUD\_TOOLS\_Python\APP__JigsawWM\src\jigsawwm\w32\monitor.py", line 159, in get_info
raise WinError(get_last_error())
OSError: [WinError 1461] Ungültiges Handle für den Monitor.
I'd appreciate any help on these two effects.
Thanks.
The affinity_index
takes a ScreenInfo
and return an index
value to indicate how well the Theme
fits given Screen (scale bad 0~10 good).
For example, mono
is better for small screens (<20inch) so it returns 10
for the case.
While Dwindle
is better suited for screens >24inch or above, etc.
I have no idea what might cause #9 at this point..
here come some news about the strange issue described above and issue #9 .
JigsawWM
application was nunning flawlessly, again. This was astonishing, as I came to think that the cause for the misbehaviour (and the error about the "monitor handle") came from a strange hardware defect within the connected docking station. Anyway...Microsoft Visual C++ Compiler Tools
as they use the cython
tooling. Installing these "compiler tools" (about 10GB of data... no clue what all that has to do with the compiler tools, anyway) led to the return of the strange "monitor handle" error, again.Microsoft Visual C++...
stuff, the "monitor handle" error vanished, so that I am now able to run the code base using my preferred configuration.I don't have a clue why it is the fact that Microsoft alters a lot of other system parts just through installing ordinary compiler tools. This is one reason, I don't like working (developing) on Windows. So much unnecessary complexity.
Trying to figure out how to find and install a minimal set of compiler tools for a functional application of cython
...
Hi again,
I just updated to the latest commit on
main
branch in order to prepare a small PR, but sadly,jigsawwm
throws an error. Now, the error occurs before the windows have been arranged on my big monitor (which is different than the now closed issue#9, where the error occured after it). In order to at least be able to letjigsawwm
arrange my windows, I will have to go back in commit history...Here are the details: After walking into the project and virtual environment (where I already updated the last new modules using
pip
) I start the tool. After startingjigsawwm
with the configurationnnako.pyw
from the examples folder (as I generally do), without any change on the window locations, I get the following error message in the calling terminal window:The execution stops within the function get_monitor() at this location (line 206):
After pressing
<CTRL> + <C>
within the terminal window, I see the application completely stops:I've tried to set a breakpoint to line 204, but it oddly seems to be ignored when executing. Maybe, the code is already running at some other thread / place and would thus rather be inaccessible for the debugger?
Any hints? Can I check something?