[Kde-java] Where is QMap

[Richard Dale]

On Saturday 02 October 2004 18:13, David Goodenough wrote:
> On Saturday 02 October 2004 16:28, Richard Dale wrote:
> > On Saturday 02 October 2004 16:14, David Goodenough wrote:
> > > I realise that without the new features of Java-5 QMap may be of little
> > > use, or rather will require lots of explicit casting, but where it is?
> > >
> > > I am trying to go through all the Qt Designer manual examples, and to
> > > convert them into Java, and I got to the main window example and found
> > > that this class does not exist.  I could use a Java Map object, but I
> > > am not quite sure where this is sufficiently the same.
> >
> > Currently that type isn't supported - it should be a java HashMap. The
> > QtRuby bindings marshall it to a Ruby Hash. I'll add it if I've got time
> > - the KDE 3.3.1 release doesn't get tagged until 8:00, so I've got an
> > hour or two, but I still haven't built the KDE classes yet, just QtJava.
> >
> > BTW, I've fixed the QWidget::polish() loop bug.
>
> Wonderful.
>
> I don't mean to pile further detail on you, but have you given throught
> to providing QString as well.  I ask because it seems to have rather more
> capabilities than String, in particular some message arguement substitution
> functions which seem to go beyond those in MessageFormat.  I realise this
> could not reasonably be done for this drop, maybe the next one?
I'm not very keen on adding QString to the java api because it makes it very 
un-javalike. But that's the sort of thing we can discuss on this list. A more 
problematic example is the java Calendar class which is just awful compared 
with QDate. So should we provide alternative methods with QDate args in the 
api wherever we have a Calendar arg now? PerlQt and QtRuby have QDate in 
their apis, whereas QtJava doesn't. 

The java-gnome bindings have EventListeners, so they could be added to QtJava 
too. However, I personally regard them as a complete 'design disaster' and 
would be very reluctant to add them.

-- Richard