Could Tk be D's ideal widget set?

Josh Stern josh_usenet at phadd.net
Tue Oct 10 10:40:39 PDT 2006


On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:

> Josh Stern wrote:

>> Every lib has some limitations.   But its worthwhile to think carefully
>> about which limitations that bother you are based on lib decisions you
>> don't like, which are based on missing features that could be added, and
>> which are based on the application language (which can  be changed with
>> bindings).
> 
> This is interesting. Personally, I have never seen a GUI library that I 
> didn't think was dreadful in some way. And there are so many of them! 
> Why? It could be that it's an intrinsically difficult or practically 
> unsolvable problem. In which case any D GUI would be bound to the same fate.

Can't comment on that without knowing which aspects of existing ones you
find the most undesirable.

> However, it's also possible that it is the language -- I'm inclined to
> think that's true for C++ GUIs. For example, the preprocessor in Qt is
> disgusting, but a D binding would avoid that. 

Perhaps.  Let's take this pre-processor issue as one example and see how
far it can be broken down.   First, let's list which aspects of Qt's use
of the moc pre-processor might be considered objectionable:

1) dislike for *any* pre-processor use because they aren't supported well
by one's favorite source code debugger - this could be classified as
either a language issue, a personal philosophy, or a tool limitation.

2) dislike for use of a non-standard pre-processor - classify this as
mainly a language issue because cpp is particularly sucky, but the
pre-processor or the language itself could be better in many ways and
still not support the same level of source code convenience as moc (yes,
there is build inconvenience, but I get to that in another bullet
point).  In D one could replace part of what moc does with mixins, but not
all of it.  To get all of it mixins would have to be extended with the
capability to use alias arguments in more textual ways and also need to
get access to some of their parsing context (e.g. surrounding class name).

3) build inconvenience - extra step in builds and extra object files need
to be dealt with in the build description process and take some small
extra time to run as well - seems like a devel environment/hardware speed
issue.   I believe that there are various setups for automating the build
stuff.

4) unfamiliarity of generated source (e.g. when doing deep debugging) - I
guess this could be the same issue for mixins;   one has to decide if the
convenience achieved justifies this.

5) methodological choice - the question came up a lot about why they
didn't use templates, and the answer was that template support was too
non-portable when Qt was written and also that Qt's slots/signals provide
different dynamic run-time functionality than what one would get with
templates.

All of the above boil down to the question of whether the functionality
gained was worth the inconveniences and whether there was some better way
to get the same functionality.   Answers in C++ are not obvious to me.  If
one has the capability to design a new programming language around the
desired functionality, then the story is different, but that also comes
with its own disadvantags (e.g. inconvenience using existing libraries,
fewer familiar programmers, etc.).


>It could be that my
> revulsion to some of those libraries is just a result of C++ failings.
> However, I do think that the language limitations show through the
> library, and a wrapper doesn't really hide that.

How so?
 
> (ie, many lib decisions were made because of the application language).

Which ones negatively impact you in important ways as a user?   Again it
is useful to distinguish between the methods that were used to get to a
particular functionality and interface (which you might do differently if
you were writing it for the first time, but which don't affect you once it
is written), and the choices that make the interface less useful to you.  
It's definitely true that adding a bindings layer gives one the capability
to change some but not all aspects of the interface.


> Which would imply that you get
better results wrapping lower level
> libraries than high level ones. (Example: you can easily wrap the
> Windows C API, and make something much better).

I'm not following you here.  Much better than what?  Did you mean a better
interface than the Win32 API or a better GUI toolkit on top of Win32?

Anyway, I think I disagree with the "imply" part in the sense that
whatever one can do theoretically starting from scratch is a different
question than what one can do starting from reality with some X hours to
spend over some time period Y.







More information about the Digitalmars-d mailing list