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

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

> > 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.
What exactly do you mean by automatic layouting?
The Qt system of layouting is as automatic as I can imagine it'll get in a 
pinch. Using Qt-layouts, especially if working from the designer through the 
XML-UI framework, you don't do any layouting yourself. You simply specify 
parameters on how widgets should be grouped, and what their size-constraints 
are. The rest is automagic.

> > 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.
Hmm, is it possible to do useful GC:ing on a network-protocol with different 
client-implementations? For instance, how would the server know if a client 
is REALLY still using it's reference to an object? Is it possible to 
garbage-collect memory, or even detect memory leaks from a misbehaving 
client?

> > 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. :-)
Qt designer stores all information about a UI-dialog in an XML-file. So this 
of course could apply to Y. I don't know if altering the Qt designer to 
become a Y designer is a viable idea, though. There are a number of issues 
with it, such as the fact that Qt Designer uses the Qt widgets to preview and 
edit the GUI. It's a graphical tool closely tied to Qt, and I think it's less 
work creating a usable equivalent for Y, then to attempt to modify Qt 
Designer.

> > 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?)
Well, all the 5 UI-design tools I've worked with before (C++, C# and Java) 
does edit the source-code directly, with a serious overhead on subclassing 
for editing. (Double-click a button and a new non-virtual method will be 
added to the UI-class itself to handle OnClick etc.) As long as it works, 
it's fine, but as soon as you hand-edit something in the source-file, the 
designer may go wild and go berseker on your code.

Regards
/ Ulrik

- -- 
Breadth-first search is the bulldozer of science.
		-- Randy Goebel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/ptM069SELtZwIkRAhbcAJ46Pt78IwGBsq6n1UE6x9t7uzb7OQCgpLJc
KGBxrgsY08Pzp4S+DZDk3c0=
=Efo2
-----END PGP SIGNATURE-----