Skip to content
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

TypeError: 'NoneType' object is not callable #11

Open
nnako opened this issue Apr 22, 2024 · 5 comments
Open

TypeError: 'NoneType' object is not callable #11

nnako opened this issue Apr 22, 2024 · 5 comments

Comments

@nnako
Copy link
Contributor

nnako commented Apr 22, 2024

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 let jigsawwm 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 starting jigsawwm with the configuration nnako.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:

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]
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not callable

The execution stops within the function get_monitor() at this location (line 206):

    def get_monitor(self, monitor: Monitor) -> MonitorState:
        """Retrieves the monitor state for the specified monitor in the virtual desktop

        :param Monitor monitor: monitor
        :returns: monitor state
        :rtype: MonitorState
        """
        monitor_state = self.monitors.get(monitor)
        if monitor_state is None:
-->         theme = sorted(self.themes, key=lambda x: x.affinity_index(monitor.get_screen_info()), reverse=True)[0]
            logger.info("default to theme %s for monito %s", theme.name, monitor.name)
            monitor_state = MonitorState(self, monitor, theme=theme.name)
            self.monitors[monitor] = monitor_state
        return monitor_state

After pressing <CTRL> + <C> within the terminal window, I see the application completely stops:

QObject::killTimer: Timers cannot be stopped from another thread
QObject::~QObject: Timers cannot be stopped from another thread

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?

@nnako
Copy link
Contributor Author

nnako commented Apr 23, 2024

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.

@klesh
Copy link
Owner

klesh commented Apr 23, 2024

@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.

affinity_index=lambda si: (5 if si.inch >= 20 else 0) + (5 if si.ratio >= 2 else 0),

You may update your theme configuration by adding the same function or make it optional

@nnako
Copy link
Contributor Author

nnako commented Apr 24, 2024

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.

@klesh
Copy link
Owner

klesh commented Apr 24, 2024

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..

@nnako
Copy link
Contributor Author

nnako commented Jun 19, 2024

here come some news about the strange issue described above and issue #9 .

  • after setting up a new computer, the 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...
  • the I set up all the other software components that I needed to run my various Python projects. Some are requiring the installation of 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.
  • after de-installation of all those 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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants