lilypond-user
[Top][All Lists]
Advanced

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

Re: Appreciation / Financial support


From: Jeff Barnes
Subject: Re: Appreciation / Financial support
Date: Mon, 4 Jun 2012 11:39:48 -0700 (PDT)

> From: Tim Roberts

> 
> Jeff Barnes wrote:
>>  While I'm sensitive to David's request to end the discussion for 
> now, there are some misconceptions about Qt that need addressing.
> 
> That's not entirely clear. 

I don't think starting from here is fair, Tim. You didn't quote enough context.

> The discussion was originally about the
> choice of Scheme as an extension language.  Qt is clearly not an answer
> to that question.  In addition, Qt is not just a library, it is a
> lifestyle.  You would have to throw everything out and start over.  It's
> also not clear to me that Qt is a net win in an application that has a
> console user interface.

From the above paragraph snippet, everything except the first and last sentence 
should have been prefaced with "IMO". But the last sentence, in particular, was 
a fair response to my post, so I should address it. The net win would be Qt's 
meta object system and the built in options for scripting: dynamic and 
generated script bindings. Both have their advantages and drawbacks. 
Refactoring for the exposed Lily api could be gradual in either case. Big gains 
could be realized fairly quickly though, IMO.

> 
>>  First, Qt is cross-platform and runnable on the above platforms and others 
> as well.
> 
> It has the additional benefit of being enormous.
> 

Fair enough. Something to be considered. It's not clear to me that this is of 
itself a deal breaker, though, IMO. You're not saying the CLR is small, though 
are you?


> 
>>  While Qt APIs are required, no new language is required. With Scheme and 
> the other extension strategies, both new API's and new languages are 
> required.
> 
> In what way does Qt represent an "extension strategy"?

Using C++ to extend Lily. With the benefit that there are readily available 
language bindings to popular languages.

> 
>>  I don't think Qt is a language of the moment, though.
> 
> Qt is not a language at all.  It is a library.

Then we agree?

> 
>>  I'm not sure he was being serious in adding Visual Basic to the mix, 
>> but whether or not he was serious, comparing VB to Qt is disingenuous and 
>> dismissive without a fair consideration. VB isn't cross platform. There are 
>> also license differences and Qt is on the right side of that comparison. I 
>> was a 
>> little surprised that someone with a GNU background like his would have made 
>> those remarks.
> 
> VB is, at least, a language, and an embeddable one at that.  VB brings
> with it the .NET Common Language Runtime, which IS more or less directly
> comparable to Qt.  It is cross-platform (via Mono), although not to the
> same degree that Qt is.
> 

If it would suit the platform, extensibility, and license requirements I'd 
consider using it. Would you stipulate that Mono is less mature than Qt? Would 
you agree that saying "VB brings with it the .NET Common Language Runtime" is 
overstating it a little?

> However, this debate is now taking a nasty side-trip into religion, and
> that isn't going to help anyone.

It was not my intent to get religious. Please show me where I was religious 
about Qt and I will gladly recant.

Regards,
Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]