The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qt license



On Fri, 31 Oct 1997, Mark Baker wrote:

> On Fri, 31 Oct 1997, Jason Gunthorpe wrote:
> 
> > I -really- like how GTK is designed (Deitys widget's follow an almost
> > identical path, even though I had no knowledge of how GTK worked till very
> > recently) but I highly dislike the use of a contrived OO mechanism ontop
> > of plain C.
> 
> But a lot of people prefer C; can your widget set sensible be called from
> C at all? 

Well, this is they grey area. Is GTK really C anymore? Or is it a new
language (GTK-C) built up with pre-processor directives and the like. If
you look at the sample I posted you notice things like:

    gtk_container_border_width(GTK_CONTAINER(window),10);

If I were to formalize this I would say that the above has several
statements above and beyond the mear C function call,
  - The function is part of the gtk container class
  - The function manipulates the border width attribute of a container
  - GTK_CONTATINER safely converts a generic base class pointer into
    a GtkContainter pointer for use by the function
It seems to be what they have done is to extend C to encompass their own
OO language, like it or not. The statement 'I prefer C' really has no
meaning when you are looking at things from this perspective. Anyone who
wants to use GTK is going to have to learn their ideas of how to express a
method call against an object, which are not the same as the usual C
style, they have these odd casting macros.

>From the client side things in GTK are not as bad as my perceptions of
library side is [not -that- familiar with GTK widget building so get out
the salt!]. GTK is going to start to fail compared C++ widget sets when
you begin deriving new widgets. Some simple comparisions have suggested
that so far my C++ library's widgets are over 30% smaller (line count)
than GTK counterparts. I have learned from experiance that widget sets are
many times more usefull for esoteric applications if it is -very- simple
for the client programmer to derive special case widgets from the library.

For instance Deity uses an immensly customized tree widget which contains
modified drawing routines to get the data out of the memory cache. This
wouldn't be possible if it were not for the ease of custom widget
generation.

As for the widget set I designed, I presented an direct example based on
the GTK code. You tell me if that makes sense to a C user -- ie someone
whoe likes functions and won't use classes. I will tell you that it works
either way, you can use it quite happly as an extended C syntax and never
use the word 'class', from a client side of course. As soon as you begin
extending the library you have to derive new classes. Also if you like
using classes there are mechanisms to realize events into classes systems
and so on. Both fit nicely into a well rounded program, and allow the
concept of reusable event handlers, but that is another story.. :>

> A widget set really is an obvious example of where object orientation is
> good, so it isn't surprising that they've attempted to use object
> orientation in C. Incidentally Xt is object oriented too---there's a lot
> wrong with Xt, but the way they've handled the object orientation isn't
> one of them, it is very nicely done IMO. 

All widget sets are OO, like it or not. But I think GTK went to far in
it's use of public non-language supported constructs such at
GTK_CONTAINER(x).

The best C API I have seen would be Photon, they had this very clever idea
about widget resources which allowed them to have an very clean,
extendable and easy to use client side perception of the widget state. The
above example would go something like..
  PtSetResources(window,Pt_ARG_BORDER_WIDTH,10,0);
They did everything that way, no special cases. Kinda neat actually.

> You mean the API isn't very nice, or what? I haven't looked at it really,
> as just its licence put me off. [WRT to QT]

I think it is populated with too many special cases, it's a bit complex
and it isn't really C++ either. They have a front end compiler (moc) that
generates C++ code from a mutant form of C++ they developed. This is part
of their event mechanism and I don't like that one bit.

We should probably take this to debian-devel if there is another post on
this thread.

Thanks,
Jason


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .