Re: redesign of GUI event handling

[Daniel J Sebald]

On 09/19/2012 02:44 AM, Jacob Dawid wrote:
> Dan,
>
>         The patch is for GUI items signals and slots, i.e., the file
>         editor tab being notified directly by the _main_window using a
>         signal rather than having to go through the file editor which
>         then distributes the notification to the file tabs.  Saves a
>         small hunk of code.
>
>
> I am sorry, I got a bit confused, since you seemed to response to jwe's
> email with the subject "redesign of GUI event handling", which is a
> different topic.
>
> I spoke about that on IRC and I saw that people are convinced that
> dynamic_casts are an evil thing per se, though to be honest I would not
> apply the patch.

It depends.  Sometimes there is a level of abstraction of container 
classes and so on.  But still, it seems to me that once one has to do 
casting (and the GUI system is well designed) then one could be stepping 
slightly outside the intended paradigm.

Consider this example:

      file_editor_tab *fileEditorTab
        = dynamic_cast <file_editor_tab*> (_tab_widget->widget (i));
      if (fileEditorTab)
        fileEditorTab->notice_settings ();

Casting the pointer upward and then calling notice_settings is 
ostensibly the concept of a virtual function.  That is, if 
notice_settings() were a virtual function in QWidget, then there'd be no 
need to cast upward.  Of course, we can't add such a function to 
QWidget.  So that's a no go.

Distributing notice_settings as above isn't real bad, but its drawback 
is that it is very coding dependent.  That is, imagine if one were to 
create a project builder that lays out windows and the interconnects. 
For an application like that, manually coding the distribution of 
functions isn't generic enough, even though that approach may have been 
something a GUI designer would have done in the nascent age of OOP and 
C++.  Instead, I imagine a way to go about it is to build a table 
consisting of the signal and slot definitions and then let the designer 
fill in the code for the slots.

I'll make a suggestion below.


>  The reason is the following: Every Qt object that works
> with signals and slots is a QObject. The hierarchy is:
>
> QObject -> QWidget -> QFileEditorTab
>
> It is considered bad design (in Qt) to send information in signals about
> the sender,

Is that too much like the callback-function paradigm?  I suppose so. 
One can remove passing "this" as part of the signal.  Shouldn't be a 
problem.


>  but there is a "trick" to gather that information:
> QObject->sender() will query the meta object layer to find out who
> invoked the slot. So I could also downcast the QWidget with the same
> effect, saving the dynamic_cast and not changing the signal to what is
> considered bad design. The reason I do the dynamic_cast is to query RTTI
> to see whether the object invoking the slot is really appropriate for
> that kind of operation I am doing. In fact, i am downcasting
> QFileEditorTab implicitly to QWidget afterwards.
>
> Also, the notice settings signal is a signal that will be emitted on a
> change of settings (ie. in the settings dialog). The file editor
> receives that signal and distributes it to the editor tabs. If you
> remove that, the changing fonts and other settings on the editor should
> not have any effect anymore.

OK, I thought that went through the _main_window only.


I think there are a couple ways one can go with this that avoids the 
dynamic cast and distributing calls, both of which involve connecting 
the slots of the file_tab_editor:

1) Set up the signals/slots of file_tab_editors to both the _main_window 
and to the settings dialog, thereby bypassing the file_editor object.

or

2) Set up the signals/slots of the file_tab_editors connecting with the 
file_editor so that when file_editor gets it signal to handle 
notice_settings it can simply turn around and emit a signal to the 
file_editor_tabs.

Let me think about the second approach; that one sounds about right for 
the Qt paradigm and the layout you've created.  I'll update the patch at 
some point in the next few days.

Thanks Jacob,

Dan