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

On Mon, Jul 19, 2004 at 12:12:15AM +0200, Ulrik Mikaelsson wrote:
> Sunday 18 July 2004 23.27 skrev du:
> > > [...] I still haven't spoken to a single developer that have really
> > > tried Qt and disliked it. (After this posting I expect that to change,
> > > though ;) )
> > I'm not a developer, but there are things I really dislike about Qt.
> > Most of my objections are in the operational use, not in architecture
> > and design, as I know hardly about them. That shouldn't stop anyone from
> > looking at how Qt does things. OTOH it won't hurt to keep in mind that
> > what you think reasonable someone else might not. So, if it doesn't
> > really matter, you might as well not make the assumption.
> Of course not. I'm fully aware that different people prefer different things, 
> for instance there seems to be quite a bunch of people out there who prefers 
> GTK. Why is way over my head, but nevertheless Y will have to attempt to 
> satisfy them as well as people who prefer WinForms, PicoGui, pure Y, or Qt.

If we find one of those we could ask why, just as I did to you about Qt.
:-)


> > But that leaves open the question why you like Qt. Oh, I already asked.
> > Call me impatient. :-) The answer is of course important to making the
> > Y api usable and fun to write for. (this just sounds so.. share and enjoy!)
> 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.


> I'm sure there are a bunch of more benefits to get from Qt, as well as there 
> are benefits to WinForms, or even GTK. I certainly don't think Y should be 
> biased to, and especially not limited to, what Qt does, but since I and many 
> others have found Qt to be an agreeable toolkit, the good things about it (in 
> terms of layouting, especially) should be available in Y as well. One other 
> thing that would be wise is to make sure that all the native-widgets of Qt 
> (as well as GTK) has a counterpart in the native widget-set of Y, to enable 
> the Qt/GTK compability discussed below.

Well, at least Y would do well to look why Qt is so nice and learn from
it. That's why I asked in the first place. :-)


> > > No matter how much you want Y to resemble/differ from Qt, I think we
> > > all can agree on one thing: The protocol MUST be flexible enough to
> > > create a pure, non-X11 based GTK2 backend, as well as a Qt4 backend.
> > I couldn't care less if GTK2 fell over dead tomorrow. But if it's
> > important to you, go ahead. :-)
> I agree, unfortunately there are still some GTK-application I would not want 
> to be without, such as Gimp, Sodipodi, and XChat. So far I haven't found 
> anything free for Linux that beats them in their respective areas. However, I 
> would not touch GTK-code myself, unless my life depended on it.

I happen to use none of them, but firefox seems to depend on GTK2 so I
still have to have it installed. I'm fairly happy that seems to be the
most of the gnome infection though. And it doesn't show too much.


> On the Qt4, I would be interested to dig myself down for a couple of
> weeks and try to create something useful, but I'm afraid I don't have
> much time, working two jobs right now, and once the second job is
> over, I'll keep working on my masters degree.

You do whatever needs doing first.


> > We don't have a stable api yet, having a shot at making such a backend
> > might give useful insights to a stabler api. OTOH, there's this little
> > danger of tailoring the API to be only just and nothing more than a
> > $foo backend. Still, with that pitfall in mind, it could be a useful
> > excercise.
> Absolutely. It's important to keep in mind that even if making Qt/GTK work 
> under Y is important, the main task is to make Y itself work.


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