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

On Mon, Jul 19, 2004 at 09:07:26AM +0200, Ulrik Mikaelsson wrote:
> Monday 19 July 2004 00.43 skrev JP Dinger:
[snippety! liking Qt in detail]
> > 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.

Err, indeed. I am not a fan of C#, but then I'm not about to say you
can't be. :-)


> Things that is easily generic from Qt and apply to all languages
> are things like the layouting system.

I feel that it'd be great if we could automate most of that, but I fully
agree that such is a wish for some far future Y. And in the meantime a
layouter is an incredibly useful tool to have.


> 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?

While C doesn't natively sport a GC, it has been shown that you can in
fact use a GC with C. So if there is a way to elegantly put one in the
Y server, we could consider that. I'd prefer it so that it's an option
along with a CG without the coverup but with a noisemaker instead: a
memory leak detector. In an ideal world we'd never need either, but hey.

I don't know about QObject to comment, but I'm sure there's other
people on the list that can elaborate in detail about the pros and cons
of the QObject model. On a more general note, a well-thought out model
is good to have. I'd say this is a perfect excercise for someone wanting
to try out writing software that's mathematically provable correct.

On another thought, I always wanted to try out a model checker like
spin. The network protocol came to mind first, but I think it can be
applied with success to the memory allocator, too. Provided you can
work out how to use the thing at all, that is. Spin seems a powerful
tool, but with some learning curve attached.

As soon as I get the book and some quality time with it I'll try and
get started with it. That'll take time though.


> 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.

How does the Qt designer store what it knows about widgets? I mean,
couldn't we just kick out the Qt specifics and put in Y ones instead?
Don't know about the Qt legalese here, but as a first shot it's probably
worth the effort. At least for some quick returns. :-)


> 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.

That is a fairly common method with OO designers. IME that is.
(Are there other methods that are at least as elegant?)


> 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.

ACK. Sounds useful.


-- 
  j p d (at) d s b (dot) t u d e l f t (dot) n l .