Could Tk be D's ideal widget set?

[Don Clugston]

Josh Stern wrote:
> 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.


and
6) unnatural - fits poorly with any other library in the language.

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


I don't disagree with that. This is why I said, maybe it's an unsolvable 
problem.

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

Things like:
* Why do I have to put this in a class? Why can't I just use a free 
function? (typical for GUIs that originated in Java).
* In a C++ GUI, you can usually tell that the original language didn't 
have delegates.

The biggest problem, I think, is that GUI libraries tend to interfere 
too much with app structure.

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

I mean a simpler interface than raw API calls, taking out lots of 
repetitive code. Eg, a simple OO wrapper that puts the HWNDs in a class, 
so you can remove lots of 'hwnd's. The benefit is obvious (the code size 
decreases). But when you wrap a high-level framework, you have a lot 
less freedom.

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

That's certainly true. But there's also the problem of getting a 
consensus on those X hours. How can you convince everyone to work on the 
same thing? It just seems to be really difficult. I worked on the 
Windows API headers because I knew that no matter which framework was 
used, it would still be useful.

The thing that really drives me nuts is that there are *so many* GUI 
libraries for Windows and Linux, and they are all ultimately using the 
same hardware! I just think it's so ridiculous. If you look in the 
coding of any of those frameworks, you find that huge chunks of them are 
the same. And so I wonder if there is some intermediate level at which 
you can create widgets (or at least parts of them) that would work 
regardless of what GUI framework was ultimately used.