LinuxCon: Some advice from Uncle Dirk

My personal suspicion is that the approach I am pushing will work well up to a certain point, but will not scale beyond that. It will depend how much can be achieved by connecting UI components with signals and slots (and how many clever solutions people can find to increase that). As a simplified example: the signal "File menu/open" would be connected to "File chooser dialogue/show", the different components would also be connected to one another ("Directory view/select directory" to "File view/change directory") and "File view/select" would be connected to "File chooser dialogue/hide" and to a text signal into the text process: "OpenFile <filename>". The question is how many uncomfortable details my simplified example simplifies away, but thinking back to Visual Basic 1 (the only one I ever used), I do think that it could work for some applications.

The other point I am hoping may hold is that many more complex applications are built around a single main central widget. For example in MS Word, that would be the editor widget. I hope that at least for some applications, it will be possible for the text controller process to hold some state about that widget (the visible size, the position of the scrollbars), to accept a few events like key pressed, mouse clicked, mouse dragged, scroll down, refresh rectangle and to send a few, like fill rectangle with bitmap, change vertical scroll range, place cursor, while still not knowing implementation details like what the widgets are called, exactly where the scrollbars are and what they look like and so on. (In other words, behave as if it were managing a full screen application like a DOS editor, rather than worrying about the full complexity of a GUI).