Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-jambi-interest Archive, August 2006
feedback

Message 1 in thread

http://www.javalobby.org/java/forums/t77115.html

The overall tone swings between "a bit late" to "this is not very Java".

Certainly things to learn from for the real release from a vocal set of 
people.

I certainly hope the Java ethics can be captured even better in a future 
release. :-)

Cheers!
-- 
 [ signature omitted ]

Attachment: pgpGLx0HqaUod.pgp
Description: PGP signature

Message 2 in thread

> .... "this is not very Java".

At least this should be ignored. Same yada yada you can hear for the C++ 
libs. "This is not C++ ... yadda ... you need this ugly moc ... yadda 
yadda. Before that it was the license. Not free ... yadda ... too 
expensive yadda. There are always people who complain. Usually the ones who 
wouldn't or couldn't use the lib anyway.

Guido

P.S. they were right to say qtjambi comes late. ;-)
Message 3 in thread

On Monday 7 August 2006 21:06, Guido Seifert wrote:
> > .... "this is not very Java".
>
> At least this should be ignored. Same yada yada you can hear for the
> C++ libs. "This is not C++ ... yadda ... you need this ugly moc ...
> yadda yadda.

I'd say that plain ignoring is the wrong thing to do.  Just as wrong as 
accepting everything the vocal people say as truth.

One thing noted is that connect() is not very object oriented. And they 
are completely right. But there are advantages to the pattern and its 
simply a different ways to do things. I have the feeling that Jambi is 
not taking enough advantages of the advantages as is.  For example; the 
examples should have the slots methods all set to private IMO. Java 
people care a lot about a clean API.

The public image that Jambi portrays should be truthfull about these 
things. And sell the connect() idea based on the ideas that long time 
Java programmes have. Which are clearly different from the C++ crowd.

The "We use less code than Swing" is clearly not a sales pitch that works, 
Java is well known for its verbosity and its users are seeing that as a 
strength.

Anyway, I'll leave that to Trolltech, whom I hope is listening to these 
things :)
-- 
 [ signature omitted ]

Attachment: pgp4WT5sTc5wl.pgp
Description: PGP signature

Message 4 in thread

Thomas Zander wrote:

> For example; the examples should have the slots methods all set to
> private IMO. Java people care a lot about a clean API.

It doesn't make sence to have the slot setText(String) to private. It 
could be called by anyone, not just via a connection. It is a normal 
function an could be called directly or indirectly.

> Anyway, I'll leave that to Trolltech, whom I hope is listening to these 
> things :)

We are ;-)

-
Gunnar
Message 5 in thread

On Tuesday 8 August 2006 10:08, Gunnar Sletta wrote:
> > For example; the examples should have the slots methods all set to
> > private IMO. Java people care a lot about a clean API.
>
> It doesn't make sence to have the slot setText(String) to private. It
> could be called by anyone, not just via a connection. It is a normal
> function an could be called directly or indirectly.

The point of making it private is to stop it being called by everyone. 
Naturally.  This is inherit in the anonymous inner class idea that most 
java devs are used  to. It means that making a connection does not polute 
the API.
So you are making this decision on implementation details, not based on 
the wanted design.

For example:
I connect a button pressed to a method "addUserPressedSlot()".
Making this a public method means its visible in the API docs, its visible 
to every coder that wants to code against this (remember, the .class file 
is the equivalent of a header file, you only need the compiled class to 
use its methods)
Because it suddenly became public, the naming starts to matter and the 
contract matters. Since all methods are per definition virtual unless 
explicitly made final.

In simple terms;  new public methods that replace anonymous inner classes 
look 'dirty' because they mean more internal design leaks out breaking 
encapsulation.

Anyway, I'll stop preaching Java to you guys now :-)
-- 
 [ signature omitted ]

Attachment: pgpfvzyfbTzkS.pgp
Description: PGP signature

Message 6 in thread

Thomas Zander wrote:
> On Tuesday 8 August 2006 10:08, Gunnar Sletta wrote:
> 
>>>For example; the examples should have the slots methods all set to
>>>private IMO. Java people care a lot about a clean API.
>>
>>It doesn't make sence to have the slot setText(String) to private. It
>>could be called by anyone, not just via a connection. It is a normal
>>function an could be called directly or indirectly.
> 
> 

> The point of making it private is to stop it being called by
> everyone. Naturally. This is inherit in the anonymous inner class
> idea that most java devs are used to. It means that making a
> connection does not polute the API. So you are making this decision
> on implementation details, not based on the wanted design.
> 
> For example:
> I connect a button pressed to a method "addUserPressedSlot()".
> Making this a public method means its visible in the API docs, its visible 
> to every coder that wants to code against this (remember, the .class file 
> is the equivalent of a header file, you only need the compiled class to 
> use its methods)
> Because it suddenly became public, the naming starts to matter and the 
> contract matters. Since all methods are per definition virtual unless 
> explicitly made final.

Hi Thomas,

I think we're speaking past each other ;-)

In the case of:
public void on_resetColorBalance_clicked();

which is clearly event handler for the one case of the action 
resetColorBalance completly I agree. Its a mistake that the demo has 
those public.

If I had a function resetColorBalance(), it could make sense to have 
this public, because I wanted to be able to call it from different 
locations. This was my point with setText(String). You want to be able to do

QLabel l = new QLabel();
l.setText(text);

in addition to doing things like:

progressDialog.progressStringChanged.connect(l, "setText(String)");

So in short, there are quite a few slots that you want to call both as 
normal functions and indirectly using signals/slots, hence they can 
(when you decide) be public.

-
Gunnar
Message 7 in thread

>
> Hi Thomas,
>
> I think we're speaking past each other ;-)
>
> In the case of:
> public void on_resetColorBalance_clicked();
>
> which is clearly event handler for the one case of the action 
> resetColorBalance completly I agree. Its a mistake that the demo has 
> those public.
>
> If I had a function resetColorBalance(), it could make sense to have 
> this public, because I wanted to be able to call it from different 
> locations. This was my point with setText(String). You want to be able 
> to do
>
> QLabel l = new QLabel();
> l.setText(text);
>
> in addition to doing things like:
>
> progressDialog.progressStringChanged.connect(l, "setText(String)");
>
> So in short, there are quite a few slots that you want to call both as 
> normal functions and indirectly using signals/slots, hence they can 
> (when you decide) be public.
>
> -
> Gunnar
>
>
>

I understand that one of the fundamental building blocks in the Qt 
system is the signal/slot stuff, and that you feel this gives you a 
short, flexible and concise
code.

However, registering connections sending text strings of method 
signatures seem for me to be a bit "C-like" and antiquated.
Wouldn't it be better to use interfaces for things like this?

I'm not a Qt expert in my Java way of thinking I would expect classes 
that would want to be connected to signal senders to implement a interface
for doing the updates

interface Connectable {
    update();
}

and register towards certain signal emitters with

progressDialog.addSignalListener(this, QProgressDialog.PROGRESS_CHANGED);

(one may also then unregister using 
progressDialog.removeSignalListener(this);)

This way you would clearly declare where to find code that do the 
processing of signals. More code, I know, but clearer design, and easier for
good IDEs like IntelliJ to show the structure in the code and 
manouvering in it.

Best regards,
Helge Fredriksen
Message 8 in thread

Am Dienstag, 8. August 2006 22:16 schrieb Helge Fredriksen:
[...]
>
> This way you would clearly declare where to find code that do the
> processing of signals. More code, I know, but clearer design, and easier
> for good IDEs like IntelliJ to show the structure in the code and
> manouvering in it.

IDEs could easily support signals and slots, whether the mechanism uses 
strings or not, including code completion and refactoring. Some IDEs in the 
free software world have demonstrated that already. For an IDE, all code is a 
string anyway, it can choose to parse statements within a special construct 
within quotes as well.

Signals and slots are a powerful and versatile mechanism. Qt developers have 
used it for years successfully, and I haven't yet met anybody who didn't like 
it. Microsoft implemented the same basic idea in .net (many years later, I 
may add), only calling them events and delegates. So I don't think we were 
entirely wrong although Sun didn't see the light of modern inter object 
communiation when they designed Java ;-)

I don't like the quotes in the connect statement either, but they are 
necessary to work around a limitation in Java itself. The way to fix it would 
be to extend the Java to support function closures.

I don't want to write 

    sender.progressStringChanged.connect(receiver, "setText(String)")

I want to write

   sender.progressStringChanged.connect(receiver.setText)

but this isn't possible in Java. It would be easy to support, though. 
Maybe we can address this through the Java community process once Jambi is 
tremendously succesful?

Until then, some compromises are always necessary. Not being able to compare 
strings with operator== is worse in my book, and the java development 
community learned to live with it.

Keep up the good feedback!

Matthias
Message 9 in thread

On Wednesday 9 August 2006 09:34, Matthias Ettrich wrote:
> I don't want to write
>
>     sender.progressStringChanged.connect(receiver, "setText(String)")
>
> I want to write
>
>    sender.progressStringChanged.connect(receiver.setText)

Just picking this email since it reminded me of a first impression that 
looked funny to me.
What about writing  connect(receiver, "setText") instead?

I may be biased since this way is what I have always done in my connection 
based frameworks, but it does give you more power to do cool things.

-- 
 [ signature omitted ]

Attachment: pgp7Nct4IzW4N.pgp
Description: PGP signature

Message 10 in thread

Hi, Thomas.

Thomas Zander wrote:

>What about writing  connect(receiver, "setText") instead?
>
>I may be biased since this way is what I have always done in my connection 
>based frameworks, but it does give you more power to do cool things.
>
>  
>
This might work as a convenience on top of the current system, but I 
don't think it can be a substitute for the current solution, as it would 
prevent connecting to a specific overload of the method setText.

E.g.
public Signal1<String> this_signal_takes_a_string;

void setText(String s) {}
void setText() {}

this_signal_takes_a_string.connect(this, "setText(String)");
this_signal_takes_a_string.connect(this, "setText()");


-- Eskil
Message 11 in thread

On Wednesday 9 August 2006 11:32, Eskil A. Blomfeldt wrote:
> Hi, Thomas.
>
> Thomas Zander wrote:
> >What about writing  connect(receiver, "setText") instead?
> >
> >I may be biased since this way is what I have always done in my
> > connection based frameworks, but it does give you more power to do
> > cool things.
>
> This might work as a convenience on top of the current system, but I
> don't think it can be a substitute for the current solution, as it
> would prevent connecting to a specific overload of the method setText.
>
> E.g.
> public Signal1<String> this_signal_takes_a_string;
>
> void setText(String s) {}
> void setText() {}
>
> this_signal_takes_a_string.connect(this, "setText(String)");
> this_signal_takes_a_string.connect(this, "setText()");

Really, its not that bad. Since you have the source datatype you can 
generate all likely target signatures and search for them specifically.
In practice the example you gave should just connect to setText(String) 
for the simple reason that the source has a string to pass. And if there 
is only a setText() it can fallback to that one.  But you have to admit 
that people are far more likely to call the second 'resetText()' making 
this not a problem at all.
In practice (having used my suggested method for several years in a 
professional setting) I can tell you that your fears are not warrented.

If you have doubts this can work, I'll be happy to answer any questions 
(or provide code, I have most of it already living on my HD) off list.

Cheers!
-- 
 [ signature omitted ]

Attachment: pgppAfVFos6q5.pgp
Description: PGP signature

Message 12 in thread

Thomas Zander <zander@xxxxxxx> wrote on 08/07/2006 09:48:05 PM:
> Anyway, I'll leave that to Trolltech, whom I hope is
> listening to these things :)

We are, and we are taking all your feedback into consideration.

It's very important for us to get things right with Qt Jambi
and make sure it is a success in the Java community. The team
has done a great job so far and I know they're completely
dedicated to Qt Jambi.

Keep that feedback coming to us, people.


    Eirik Chambe-Eng (co-CEO and co-founder of Trolltech)
    -----