Re: Phil meet y-devel; y-devel meet Phil

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Monday 19 July 2004 00.43 skrev JP Dinger:
> > Why I like Qt? I guess it is much a matter of taste, but I always seem to
> > find things exactly where I'm looking for them. I find the
> > layouting-system to be incredibly agreeable to work with, providing both
> > RAD (in C++-terms anyways) and support for more advanced applications
> > with custom requirements. The Qt designer is great, providing me with an
> > XML-based GUI template that I can simply compile along with the rest of
> > my code. Beeing a C++ developer, I find the signal/slot system to be
> > incredibly useful for various solutions, and I find the QObject-hierarchy
> > to save me a big bunch memory-leaks. It is cross-platform, yet fast and
> > able to provide support for local oddities such as window-embedding on
> > X11. Add the stuff that's in the pipeline for Qt4 and I think Qt is
> > definitely my preferred toolkit.
> Fair enough. But, how do we get the best out of Qt in such a way that we
> don't tie ourselves to C++? Y isn't ment to be language specific, after
> all.
Well, some aspects of the API is not tied to C++ at all. In fact I have a long 
time thought that Qt would be even more kickass if it were built around C# 
instead, but that's just my opinion.

Things that is easily generic from Qt and apply to all languages are things 
like the layouting system. One other thing that might be relevant to consider 
is how to avoid unintentional memory-leaks in the server, as a result of an 
application behaving bad. For instance, an application should hopefully not 
be able to connect to a Y server and create thousands of objects, and then 
forget it's references to them. I don't think the Y server does garbage 
collection, and I don't think we can safely do garbage collection in the 
server, so we'll have to look elsewhere for a decent solution. Perhaps the 
QObject-solution is something that could be applied?

One thing that would be awesome is if Y could have it's own designer-like tool 
to create user interfaces. The Qt designer works by first just creating all 
the necessary widgets and laying them out, instructing how to glue them 
together. This information is then stored in XML, and in the build-process of 
the application, that XML-file is beeing compiled into the native language. 
In case of C++, it will become a C++ class, intended to be subclass and have 
it's behavior defined in the subclass, shielding the developer-contributed 
code from the code done by the UI-designer. Another good thing about the way 
Qt designer does it's work, is that it is fully possible to write a simple 
tool that transforms the XML into some other language, such as Python, C, or 
C#. This functionality makes Qt a very fast toolkit to write small 
applications to be used only locally in a medium-sized company, and it should 
really be taken into account for Y.

Regards
/ Ulrik

- -- 
The universe seems neither benign nor hostile, merely indifferent.
		-- Sagan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+3My069SELtZwIkRAmtnAJ4rfCUk9M9ePD6ByC0BDrlsfE22NQCdF77p
HEHhfuSSIpDTfKWRMNAb1d8=
=OI3C
-----END PGP SIGNATURE-----