[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-freeqt
Subject:    Re: [freeqt] Relay++ library is good for you :)
From:       Olivier Galibert <galibert () pobox ! com>
Date:       1998-09-28 16:53:15
[Download RAW message or body]

On Mon, Sep 28, 1998 at 10:37:37AM +0200, Christian Boos wrote:
> Yeah! It works.

Nice one :-) I should have think about it myself since magna generates
equivalent code to workaround slot functions ambiguities...


> 
> But I guess the need of an overloaded sig() member arose from the fact
> that a different signature was needed for the slot() member, ie when
> you have 'sig(int)' and when the slot is 'slot(double)'. This kind of
> conversion is automatically handled by the default connect function
> when you do:
> [...]

Maybe not.  What   about an  hypothetical QNumberEntry  class  sending
valueChanged(int) or valueChanged(double) depending  on the user entry
(to avoid precision losses), and QLCDNumber?  You could easily have:
connect(entry, SIGNAL(valueChanged(int)), lcd, SLOT(display(int)));
connect(entry, SIGNAL(valueChanged(double)), lcd, SLOT(display(double)));

and the lcd number will happily display the value dynamically.


> I understand your point. I already thought about that.
> Qt syntax is clearly not C++ syntax. Hence the need for a
> preprocessor.
> Simply put, I thought that the syntax needed by Relay is cleaner than
> Qt's one :
> 
> Relay++:
> 	connect (a, SIGNAL(A, clicked), b, SLOT (B, ouch));
> 
> Qt:
> 	connect (a, SIGNAL(clicked(int, int, float, MegaSchpountz*)),
> 			 b, SLOT(ouch(int, int, float, MegaSchpountz*)));
> 
> 
> So I thought you would like this simplification. 
> However if your main concern is remaining SOURCE compatible with
> existing KDE apps, then a preprocessor is required, of course.

It  is.  Not only  we're actually  source-compatible,  but we're  also
invocation-compatible.  You only have to  replace "moc" by "magna" (or
make a link),  and it works.   Actually the name  is different to make
having both Qt and Harmony on a system easier.


> So we can keep magna, and make it produce the appropriate syntax for
> Relay++. The only complexity I see in that process is for handling 
> the very special situation you showed above (sig(int) and
> sig(double)).

That is   another  problem.  You'll  have to  convince   us  that your
solution is better.   For  now I  think  that magna's  code  uses less
ressources, is faster, spends less time in locks and is less complex.


>  > Half of the problem with Qt's syntax is the use of the parameter types
>  > in the signal and slot references in connect().  
> 
>  > The other half is the
>  > lack of signal methods definition.
>  
> Could you elaborate, please I don't understand. (en francais, ca sera
> plus simple :)

problem 1 (for not using a proprocessor):

connect(a, SIGNAL(send(int)), b, SLOT(recieve(int)));

How do you define the SIGNAL and SLOT macros (or  you can make connect
a  macro  itself) so  that  the result  is legal  C++.   I've found no
solution to cope with  the (int) part except  than turning the  signal
and slot name  into a string.  The  the lack  of introspection in  C++
requires a preprocessor to  build  up the  list  of signals and  slots
names.


problem 2 :
You put a signal declaration in the class declaration :
class Blah : public QObject {
  Q_OBJECT

signals:
  valueChanged(int);
};

but nowhere you write any definition.  If you  do write one, your code
won't   work  with Qt  because  of double  definition.  So you  need a
preprocessor to generate  the signal definitions (your "trigger" call,
magna's code is more complex).

These  are  the  two  main problems    with Qt's  s/s which  makes  it
impossible to do without a preprocessor.


>  > You also need the preprocessor for the  RTTI part of Qt (className and
>  > inherits).
> 
> I already tested some things about that. Here's an excerpt:
> 
> 
>   public: // -- RTTI	[note: not source compatible with Qx]
> 	
> 	const char* className () const
> 		{ 
> 		  return typeid (*this).name (); 
> 		}

This one is wrong.  The name is explicitely unspecified (not the class
own name, maybe not the same from one excution to the other).


> 	bool isA (QObject* other) const
> 		{ 
> 		  return typeid (*this) == typeid (*other); 
> 		}
>   
> 	bool inherits (QObject* other) const 
> 		{ 
> 		  return typeid (*other).before (typeid (*this)); 
> 		}

This one is wrong.  The collating sequence is explicitely unspecified.

>   
> 	bool isWidgetType (QWidget* widget) const
> 		{
> 		  return typeid (*widget) == typeid (*this);
> 	  }
> 
> 
> ... not source compatible because in Qt, the class info is only a
> string.
> Perhaps again a preprocessor would do the deal.
> 
> But I sincerely thought that 100% Qt compatibility was not the issue.
> For several reasons:
> 
> - Qt is stable and good for what it is. I don't think we can attract 
> KDE programmers now on that basis (I hope I'll be soon wrong on this :)
> 
> - I am interested in Harmony mainly because it's free,
> partly because it deals with multi-threading, 
> and is promising because it will allow a smooth integration with nice
> feature found elsewhere (imlib, freetype, themes).
> At some point (especially the threads), those added feature are not
> transparent to the programmer, and compatibilty with Qt's  is no more
> possible.

They are if you don't  use them and didn't  try to be too clever about
the implementation.   Themes will only be   a problem for  new widgets
that don't rely on existing ones (which probably means not _that_ many
once  the kde  libs support  themes   too).  Freetype  and imlib   are
transparent.  Threads   are  transparent   if   you  don't   use  them
explicitely (sorry this part of the code has been in my brain for some
time but is not written yet).


> So my proposal is to keep the preprocessor to translate legacy Qt apps 
> to Harmony apps, and use internally what we think is best. Of course
> I would respect your decision not to integrate Relay++ in Harmony, 
> that's why I made a separate lib.

For  now   the  preprocessor   doesn't have   to   translate anything.
Translation  is  a difficult problem,  and personnaly,  were I  mad or
bored enough to attempt  it, I'd target Gtk--  rather than yet another
library.

As  it comes to changing   magna's  generated code, I'm not  religious
about it put I put a great deal of effort in it to make  it the best I
could.  The  only  missing thing right now  is  disconnect.  So you'll
have to show me in which way your code is better  than the current one
to convince me.   BTW,  it's the full  compatibility with  Qt's syntax
which was the  main cause of Jo's code  removal at the time (MT safety
was secondary). See the gtk--* code in the repository.

OTOH, I'm not the only coder here, nor the local bastard with life and
death decision over other people code ;-)


> Olivier, we don't want to translate C++ code into something else,
> it's quite the opposite: translate the non-C++ part (easily 
> identifiable due to the use of the SIGNAL and SLOT macros) of Qt
> into real C++.

Allow me  to doubt the "easily identifiable"  part.  I'm in particular
afraid of the oh-too-clever
  struct {
    QObject *obj;
    char *slot;
  } *slot_list[] = {
    { obj1, SLOT(slot1) },
    { obj2, SLOT(slot2) },
    ...
  };

  OG.

[prev in list] [next in list] [prev in thread] [next in thread]