0

I can catch the user resizing or repositioning the window simply by defining functions:

def resizeEvent(self, event): ...
def moveEvent(self, event): ...

But I also have 2 QSplitter, and would like to know any new split the user has applied to make it also a default for the next start. QSplitter also has a resizeEvent(), but I can't catch it, because it is already used by the apparently higher ranking functions above.

How can I get hold of QSplitter's resizeEvent?

I now use as a workaround def paintEvent(self, event):... which does allow me to get the needed info, but it feels a bit clumsy :-/

ullix
  • 333
  • 1
  • 3
  • 14
  • Your question is unclear. What do you mean by "to know any new split the user has applied to make it also a default for the next start"? What are you trying to do? – musicamante Jan 23 '23 at 12:41
  • A split is a division of a box into 2 halves, one left, one right. The split is anything from 100:0 to 0:100. This split ratio is what I need. And on the next start of the program, this exact split should be set. – ullix Jan 23 '23 at 16:31
  • You could use [`size()`](https://doc.qt.io/qt-5/qsplitter.html), but if your purpose is to restore the position for next sessions, then you should use [`saveSate()`](https://doc.qt.io/qt-5/qsplitter.html#saveState) and [`restoreState()`](https://doc.qt.io/qt-5/qsplitter.html#restoreState) instead. – musicamante Jan 23 '23 at 17:43
  • The problem is that I need to be informed first that a change has occurred! This is what the QSplitter.resizeEvent can be used for - but I don't know how to get it. – ullix Jan 24 '23 at 09:38
  • When you get a resize event, the resizing has already happened, and even if it wasn't, you don't get a resize on QSplitter when you move the handles, because that doesn't resize the splitter but its internal layout. Please explain what you're trying to achieve, and why you want to get the splitter positions before resizing. – musicamante Jan 24 '23 at 12:07
  • You are stating what I did not say, please read the post again. I want to get noted of a change that had occurred. – ullix Jan 27 '23 at 08:18
  • Maybe I misunderstood your comment above, but the point remains, why do you need to know about the resizing (before or after, doesn't matter)? If you just want to restore it for the next session, there's absolutely no point in storing positions at *each* change, just do it when the window is closed or the application quits. – musicamante Jan 27 '23 at 11:23
  • Sure, and I am doing it by some other way. However, my headline is "How do I catch the PyQt5 QSplitter.resizeEvent?" So, I want this answered, no matter what workaround might also be used. Please, this is the question! – ullix Jan 27 '23 at 13:03
  • You can get a resize event just like any other widget: either subclass and override `resizeEvent()`, or install an event filter. But that will ***not*** make you receive resize events when the splitter handles are moved, because those do ***not*** resize the QSplitter. If that's what you need, then the questions above remain, and I asked them for very specific reasons. – musicamante Jan 27 '23 at 13:15
  • I need to handle EVERY event. Are you saying that the QSplitters resizeEvent does NOT signal that the splitter's split-ratio was changed? Then what does it signal, a change in the total size the QSplitter covers? So my workaround will be ok even if this is true. But, now I am really curious how to get the resizeEvent from the QSplitter. Subclassing and overriding seems all to be done by PyQt5. – ullix Jan 28 '23 at 12:24
  • Filtering is not possible as my resizeEvent function as shown in first post is never called by QSplitter's resizeEvent, no matter what I change? – ullix Jan 28 '23 at 12:30
  • First of all, do not confuse signals and events. While they seem to do similar things, they are not. Signals are emitted by objects and "received" by the slots/functions they're connected to; events are, well, *events*, that are **sent** to an object which may (or may not) handle them and can eventually be propagated back to their parents within the object tree. Signals can be "subscribed" (connected) to almost anything, events not. I don't know why your function above doesn't work, because you didn't provide a valid [mre] to start with, but it seems you're misunderstanding how all this works. – musicamante Jan 29 '23 at 22:38
  • Yes, resizeEvent of QSplitter doesn't "signal" anything, not only because, as said above, signals and events are different things, but also because the *only* signal QSplitter has (except those inherited by QWidget/QObject) is [`splitterMoved`](//doc.qt.io/qt-5/qsplitter.html#splitterMoved) which, as the documentation explains, "is emitted when the splitter handle at a particular index has been moved to position pos", meaning that *the user* moved it. When the splitter is resized due to resizing of the parent (or itself, if it's the top level window), the signal is **not** emitted. – musicamante Jan 29 '23 at 22:43
  • Filtering **is** possible, as long as you do it properly: either override `resizeEvent()` of a QSplitter subclass, or use `installEventFilter()` and override `eventFilter()` on the target filter. If you're hoping to receive a `resizeEvent()` of the splitter by overriding that function on a parent, then you're wrong: contrary to other event types (most importantly, *user* events, like mouse or keyboard ones), resize events are not propagated to their parents. In fact, it's usually the other way around, and that's why you need to override it for the QSplitter subclass or use an event filter. – musicamante Jan 29 '23 at 22:45

0 Answers0