Friendly GUI for windows building?

[Francois Guillet]

Hi

Creating many windows and controls is very tedious when the parameters
of the CreateWindowEx function have to be set manually.

I'm looking for a tool able to build code automatically from drag and
drop of objects (buttons, check boxes, edit controls...) onto a first
empty window, and allowing repositionning, sizing, property settings...

This was provided in environments like C++ builder, but I'm searching
for a more light tool that would generate simple cpp and h files to
include in my project and that wouldn't need an obscure and heavy
library (I'm using codeblock/gcc/mingw).

Some advises?

Thanks

[Alf P. Steinbach]

Look for "Resource Editors". These generate dialog resources and header
files. It's pretty old technology but sounds like what you're after.

A dialog can be main window.

You can create such a window from a dialog resource embedded in the
executable, by calling e.g. the DialogBox API function.


Cheers & hth.,

- Alf

[David Brown]

What about using wxWidgets rather than raw Windows API? I don't know
where you draw lines for "heavy" and "light" libraries, but wxWidgets is
certainly not obscure - and there is very good support for it in
Code::Blocks.

[Mr Flibble]

wxWidgets looks too much like MFC making it a bag of shite like MFC is a
bag of shite.

Try Qt; it is the least worst option.

/Flibble

[Ike Shaffer]

Mr Flibble wrote:

>> What about using wxWidgets rather than raw Windows API? I don't know
>> where you draw lines for "heavy" and "light" libraries, but wxWidgets
>> is certainly not obscure - and there is very good support for it in
>> Code::Blocks.
>
> wxWidgets looks too much like MFC making it a bag of shite like MFC is a
> bag of shite.
>
> Try Qt; it is the least worst option.

Yes, and pay for the shit as well. I guess he goes back to CreateWindowEx

[Mr Flibble]

You only pay for Qt if you want to link statically mate.

/Flibble

[woodb...@gmail.com]

On Saturday, January 4, 2014 4:08:00 PM UTC-6, Mr Flibble wrote:
>
> You only pay for Qt if you want to link statically mate.
>

Please don't swear here. I didn't like MFC either.

Brian

[Mr Flibble]

Your repeated requests to stop fucking swearing will ALWAYS be ignored
so you may as well stop requesting it.

/Flibble

[woodb...@gmail.com]

We'll see.

[Ike Shaffer]

Well, this is not right fible, you need to pay for that qt shit in anycase,
otherwise you may not distribute your compilation. You are an idiot,

[Mr Flibble]

You are a tool.

"Qt is available under the following copyright licenses:[42]
GNU LGPL[4] 2.1 version with Qt special exception
GNU GPL[43] 3.0 version
Commercial Developer License[5]"

Now go learn what LGPL is, you idiot.

/Flibble

[Ike Shaffer]

Why, can't you read "Commercial Licence"? Idiot.

[Mr Flibble]

You don't have to accept the commercial licence, idiot. You can accept
the LGPL licence, idiot.

/Flibble

[Ike Shaffer]

Mr Flibble wrote:

>> Why, can't you read "Commercial Licence"? Idiot.
>
> You don't have to accept the commercial licence, idiot. You can accept
> the LGPL licence, idiot.

You mean I need to read that crap first. That spoils the fun, since it
would tell me I may not distribute the compilation unless paying a big bag
of money to them.

They are from Finland, they all are gays.

[Mr Flibble]

LGPL lets you distribute your application (and the other party's DLLs)
free of charge, idiot.

/Flibble

[Ike Shaffer]

Mr Flibble wrote:

>> You mean I need to read that crap first. That spoils the fun, since it
>> would tell me I may not distribute the compilation unless paying a big
>> bag of money to them.
>>
>> They are from Finland, they all are gays.
>
> LGPL lets you distribute your application (and the other party's DLLs)
> free of charge, idiot.

Not if you letter charge for your efforts, imbecile.

[Mr Flibble]

LGPL lets you distribute commercial proprietary software (i.e.
chargeable) linked with the other party's LPGL DLLs (for free), idiot.

You think changing the follow up group to "alt.ufo.reports" is funny?
It is certainly childish, idiot.

/Flibble

[Ike Shaffer]

Mr Flibble wrote:

> On 04/01/2014 23:46, Ike Shaffer wrote:
>> Mr Flibble wrote:
>>
>>>> You mean I need to read that crap first. That spoils the fun, since
>>>> it would tell me I may not distribute the compilation unless paying a
>>>> big bag of money to them.
>>>>
>>>> They are from Finland, they all are gays.
>>>
>>> LGPL lets you distribute your application (and the other party's DLLs)
>>> free of charge, idiot.
>>
>> Not if you letter charge for your efforts, imbecile.
>
> LGPL lets you distribute commercial proprietary software (i.e.
> chargeable) linked with the other party's LPGL DLLs (for free), idiot.

Then you contradict yourself, making the "Commercial Licence" invalid,
asshat.

[Mr Flibble]

There is no contradiction, idiot. The commercial licence is totally
separate to and what it offers is different to the LGPL license, idiot.
You can choose one or the other, idiot. The LGPL licensed Qt has no
charge, idiot; but you can charge for *your* software, idiot.

If you read my initial reply telling you to read about what LGPL is we
could have perhaps been saved from your idiotic further replies.

/Flibble

[Ike Shaffer]

Mr Flibble wrote:

>> Then you contradict yourself, making the "Commercial Licence" invalid,
>> asshat.
>
> There is no contradiction, idiot. The commercial licence is totally
> separate to and what it offers is different to the LGPL license, idiot.
> You can choose one or the other, idiot. The LGPL licensed Qt has no
> charge, idiot; but you can charge for *your* software, idiot.

Then I guess you can skip reading that LGPL manifest and just send an e-
mail to them, telling that you intend to use their crap, and make big
money.

Let them call you an imbecile! LOL

You are a wise man flib :)

[Mr Flibble]

I've decided that as well as being an idiot you are also a troll so
welcome to my killfile.

/Flibble

[Ike Shaffer]

Mr Flibble wrote:

>> Then I guess you can skip reading that LGPL manifest and just send an
>> e-
>> mail to them, telling that you intend to use their crap, and make big
>> money.
>>
>> Let them call you an imbecile! LOL
>>
>> You are a wise man flib
>

> I've decided that as well as being an idiot you are also a troll so
> welcome to my killfile.

Ohh yes, you lost the debate, proved as imbecile.

Just send that email, flib, tell them you won't register nor pay a shit.

Let them conclude this discussion. No need need for their LGPL reading.

[Alf P. Steinbach]

On 05.01.2014 01:36, Ike Shaffer wrote his umpteenth noise article:
>
> Ohh yes, you lost the debate, proved as imbecile.

plink

[Öö Tiib]

It is perfectly legal to use dynamically linked Qt in commercially
(or how ever you want to license it) distributed application. There are
only such limitations:
1. Your application must be dynamically linked to the Qt components that
came with your downloaded LGPL Qt distribution. No static linking allowed.
2. You can’t make changes to the Qt source code itself and sell your
application based on the changed version of Qt.
3. You must inform users of your application that Qt is used in the
application in some licence text or in a readme somewhere within your
distributed application files.
4. You must provide a copy of the Qt LGPL licence file together with your
distributed application files.

These things above can't be show stopper problems.

The biggest annoyance with Qt is that it tends to create large binaries.
Lesser annoyance is that it uses custom preprocessors that do not
understand too well C++ (particularily templates and preprocessor) and
other tools tend also not to understand Qt crap (underlining it red
and reporting errors).

[David FLEURY]

Le 04/01/2014 11:51, Francois Guillet a ï¿œcrit :

You can give a chance to FTLK. It has not a very up-to-date look, and
can be though to learn but it is small, free, and "easy" to enhance.

There is an GUI editor (FLuid) which use drag & drop and generate code
for an window.

Regards

[Francois Guillet]

David Brown avait ￜnoncￜ :

I will have a look at your solution after testing FTKL which seems
simpler.
Thanks.

[Francois Guillet]

Le 05/01/2014, David FLEURY a supposￜ :

The first solution I will try is yours. From what I read on fltk.org,
FTKL seems to be simple and fits the requirements.
Thanks for the reply!

[Rupert Miscavige]

Francois Guillet wrote:

> Le 05/01/2014, David FLEURY a supposé :

Bullshit. If they are so good, why aren't they compile a Windows binary
distributable? That they require YOU to compile their crap is the first
sign that their crap IS crap.

[Paavo Helde]

Rupert Miscavige <ru...@btasco.com> wrote in news:lacm3d$osi$1
@speranza.aioe.org:

> Francois Guillet wrote:

>> The first solution I will try is yours. From what I read on fltk.org,
>> FTKL seems to be simple and fits the requirements.
>> Thanks for the reply!
>
> Bullshit. If they are so good, why aren't they compile a Windows binary
> distributable? That they require YOU to compile their crap is the first
> sign that their crap IS crap.

Source-only distributions are not crap (many portable projects are
distributed like that) and even if this were not true, there is no
connection to the quality of the project itself. Bring up some facts
instead of biased opinions!

Disclaimer: I have never heard of FTKL before and I have no idea how good
it is.

Cheers
Paavo

[Rupert Miscavige]

Paavo Helde wrote:

> Rupert Miscavige <ru...@btasco.com> wrote in news:lacm3d$osi$1
> @speranza.aioe.org:
>
>> Francois Guillet wrote:
>
>>> The first solution I will try is yours. From what I read on fltk.org,
>>> FTKL seems to be simple and fits the requirements.
>>> Thanks for the reply!
>>
>> Bullshit. If they are so good, why aren't they compile a Windows binary
>> distributable? That they require YOU to compile their crap is the first
>> sign that their crap IS crap.
>
> Source-only distributions are not crap (many portable projects are
> distributed like that) and even if this were not true, there is no
> connection to the quality of the project itself. Bring up some facts
> instead of biased opinions!

Sure it is. Crap. The proof for this is that they are unable to compile a
windows binary, for whatever reasons, then let the user using it.
Directly, as they are supposed to do.

You are an ignorant. You don't know crap and are unable to handle it.

[woodb...@gmail.com]

Rupert Miscavige. Please don't swear here.

[Geoff]

Where's the beef?

Out of curiosity I downloaded the stable archive and they don't
provided ANY binaries, not for Windows, OSX or Linux. You have to
build them yourself regardless of the platform.

I opened the fltk.sln for VS2010 and built the entire framework
error-free in about 10 minutes.

A source distribution allows you to take any portion of it you may
like without having to drag all of the framework into your
application. It also allows you to build debug and release versions of
the framework. This seems entirely logical to me.

Shipping a DLL, a collection of libs, the headers and instructions
seems more cumbersome to use than a source distro.

[Scott Lurndal]

David FLEURY <dfle...@free.fr> writes:
>Le 04/01/2014 11:51, Francois Guillet a �crit :

>> Hi
>>
>> Creating many windows and controls is very tedious when the parameters
>> of the CreateWindowEx function have to be set manually.
>>
>> I'm looking for a tool able to build code automatically from drag and
>> drop of objects (buttons, check boxes, edit controls...) onto a first
>> empty window, and allowing repositionning, sizing, property settings...
>>
>> This was provided in environments like C++ builder, but I'm searching
>> for a more light tool that would generate simple cpp and h files to
>> include in my project and that wouldn't need an obscure and heavy
>> library (I'm using codeblock/gcc/mingw).
>>
>> Some advises?
>>
>> Thanks
>
>You can give a chance to FTLK. It has not a very up-to-date look, and
>can be though to learn but it is small, free, and "easy" to enhance.

I believe that should be FLTK.

http://en.wikipedia.org/wiki/FLTK

I'm comfortable with Athena Widgets, myself :-)

[woodb...@gmail.com]

On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
>
> A source distribution allows you to take any portion of it you may
> like without having to drag all of the framework into your
> application. It also allows you to build debug and release versions of
> the framework. This seems entirely logical to me.
>

I agree, but think it's hard to get investors interested
in a 100% open source project.


Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net

[Öö Tiib]

On Tuesday, 7 January 2014 00:42:58 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
> >
> > A source distribution allows you to take any portion of it you may
> > like without having to drag all of the framework into your
> > application. It also allows you to build debug and release versions of
> > the framework. This seems entirely logical to me.
>
> I agree, but think it's hard to get investors interested
> in a 100% open source project.

It is hard if they do not want to buy fame, or the project under
question is unlikely to provide fame. Fame is not cheap commodity.

[Ian Collins]

woodb...@gmail.com wrote:
> On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
>>
>> A source distribution allows you to take any portion of it you may
>> like without having to drag all of the framework into your
>> application. It also allows you to build debug and release versions of
>> the framework. This seems entirely logical to me.
>>
>
> I agree, but think it's hard to get investors interested
> in a 100% open source project.

Um, Linux, MySQL, PostgreSQL, Illumos, the BSDs...?

There are plenty of investors will to invest in companies who add value
(usually support or other, often also open source, add-ons) to open
source projects.

--
Ian Collins

[Francois Guillet]

Rupert Miscavige a prￜsentￜ l'ￜnoncￜ suivant :
...

> Sure it is. Crap. The proof for this is that they are unable to compile a
> windows binary, for whatever reasons, then let the user using it.
> Directly, as they are supposed to do.

And what do you suggest instead which would be better ?

[Cristiano Araujo]

you can use QtCreator.

[Dombo]

Op 06-Jan-14 23:42, woodb...@gmail.com schreef:

> On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
>>
>> A source distribution allows you to take any portion of it you may
>> like without having to drag all of the framework into your
>> application. It also allows you to build debug and release versions of
>> the framework. This seems entirely logical to me.
>
> I agree, but think it's hard to get investors interested
> in a 100% open source project.

Open source software is not only written by unpaid idealistic nerds when
they are not jerking off. Most successful open source projects have
commercial backing, and many contributions to those projects are done by
paid developers.

Money is not only being made by providing support, but also quite often
by a dual licensing policy, counting on that GPL is not acceptable for
many companies.

[Jorgen Grahn]

On Sat, 2014-01-11, Dombo wrote:
...

> Most successful open source projects have
> commercial backing, and many contributions to those projects are done by
> paid developers.

For the /big/ projects that's probably true, but not for the thousands
of normal-sized ones.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[David Brown]

On 05/01/14 05:06, �� Tiib wrote:
> On Sunday, 5 January 2014 02:36:34 UTC+2, Ike Shaffer wrote:
>> Mr Flibble wrote:
>>
>>>> Then I guess you can skip reading that LGPL manifest and just send an
>>>> e-
>>>> mail to them, telling that you intend to use their crap, and make big
>>>> money.
>>>>
>>>> Let them call you an imbecile! LOL
>>>>
>>>> You are a wise man flib
>>>
>>> I've decided that as well as being an idiot you are also a troll so
>>> welcome to my killfile.
>>
>> Ohh yes, you lost the debate, proved as imbecile.
>>
>> Just send that email, flib, tell them you won't register nor pay a shit.
>>
>> Let them conclude this discussion. No need need for their LGPL reading.
>

(I know this is replying to a week-old post - I've been on holiday.)
And of course, IANAL - this is just my understanding of the LGPL in
general, and not Qt in particular.

> It is perfectly legal to use dynamically linked Qt in commercially
> (or how ever you want to license it) distributed application. There are
> only such limitations:
> 1. Your application must be dynamically linked to the Qt components that
> came with your downloaded LGPL Qt distribution. No static linking allowed.

That's not quite true (assuming Qt uses the standard LGPL). You can
also make your application available in a linkable object form. The
point is that the user (anyone legally obtaining the application source
or binary) should be able to take the source for the LGPL library (Qt in
this case), modify it if they want, re-compile it, and link it with your
application code. The linking can be static or dynamic.

Of course, having the LGPL code as a dynamic library is by far the most
common solution - but linkable object code for static linking is allowed.

> 2. You can�t make changes to the Qt source code itself and sell your

> application based on the changed version of Qt.

The LGPL does not allow Qt to make that kind of restriction. I suppose
it is possible that Qt are using a modified LGPL with additional
restrictions like this, but I did not see that on their website (though
I only had a very quick look). The whole point of LGPL is that you -
either the developer or the end user - can take the code and change it
as you want. But any changes you make must be made available to anyone
else to whom you give or sell the binary code, so that they too can
modify the LGPL'ed code (and re-compile and re-link it). But you can't
make changes to the Qt stuff and keep these changes secret from your
customers (as you can when using the commercial Qt license).

> 3. You must inform users of your application that Qt is used in the
> application in some licence text or in a readme somewhere within your
> distributed application files.

I don't know that you need mention Qt explicitly like this, but you /do/
have to provide the user with the source code for the LGPL code (i.e.,
the Qt library), with any modifications you have made. You can include
the source directly, or a written offer valid for 3 years (etc., etc.).

In practice, at least in the *nix world, you provide the application
without any Qt library and dynamically link to the shared libraries on
the end-user's system. As you are not distributing any LGPL code (using
headers is allowed), you don't have to say much - but of course you
would list the Qt dll/so files needed as part of your system requirements.

> 4. You must provide a copy of the Qt LGPL licence file together with your
> distributed application files.
>
> These things above can't be show stopper problems.

They are not - a lot of systems are made using the LGPL versions of Qt.

>
> The biggest annoyance with Qt is that it tends to create large binaries.
> Lesser annoyance is that it uses custom preprocessors that do not
> understand too well C++ (particularily templates and preprocessor) and
> other tools tend also not to understand Qt crap (underlining it red
> and reporting errors).
>

It is this second point that puts /me/ off using Qt - I can live with
big binaries for my PC software.

Another annoyance is that until relatively recently, the Python bindings
(PyQt) were under the GPL (or a commercial licence), rather than the
LGPL (or Python licence), meaning you couldn't use Python and Qt without
making the whole application as GPL or paying for the commercial
license. Now that Nokia's PySide bindings are complete for Python LGPL
Qt development, I might look again at it for future software.

[David Brown]

He said it was /hard/, not /impossible/. There are many ways to make
money from open source software, and therefore many reasons for
investors to back open source projects - but it can be a hard sell to
persuade the investors.

[Öö Tiib]

On Monday, 13 January 2014 15:58:37 UTC+2, David Brown wrote:
> On 05/01/14 05:06, �� Tiib wrote:
> > On Sunday, 5 January 2014 02:36:34 UTC+2, Ike Shaffer wrote:
> >> Mr Flibble wrote:
> >>
> >>>> Then I guess you can skip reading that LGPL manifest and just send an
> >>>> e-
> >>>> mail to them, telling that you intend to use their crap, and make big
> >>>> money.
> >>>>
> >>>> Let them call you an imbecile! LOL
> >>>>
> >>>> You are a wise man flib
> >>>
> >>> I've decided that as well as being an idiot you are also a troll so
> >>> welcome to my killfile.
> >>
> >> Ohh yes, you lost the debate, proved as imbecile.
> >>
> >> Just send that email, flib, tell them you won't register nor pay a shit.
> >>
> >> Let them conclude this discussion. No need need for their LGPL reading.
> >
>
> (I know this is replying to a week-old post - I've been on holiday.)
> And of course, IANAL - this is just my understanding of the LGPL in
> general, and not Qt in particular.

I just posted it to conclude the back and forth trollish name-calling
with some useful guidance how to do it. I did use words *must* and
*can't* may be too strongly, sorry. Indeed there are (too painful even
for my enemies) ways how to not follow that guidance.

> > It is perfectly legal to use dynamically linked Qt in commercially
> > (or how ever you want to license it) distributed application. There are
> > only such limitations:
> > 1. Your application must be dynamically linked to the Qt components that
> > came with your downloaded LGPL Qt distribution. No static linking allowed.
>
> That's not quite true (assuming Qt uses the standard LGPL). You can
> also make your application available in a linkable object form. The
> point is that the user (anyone legally obtaining the application source
> or binary) should be able to take the source for the LGPL library (Qt in
> this case), modify it if they want, re-compile it, and link it with your
> application code. The linking can be static or dynamic.

However ... we don't want to sell half-built binaries with removed
link-time optimisations as LGPL 2.1 6.a) ... or do we?

> Of course, having the LGPL code as a dynamic library is by far the most
> common solution - but linkable object code for static linking is allowed.

The idea of static linking is to distribute less binaries that are better
optimised. "Allowed" is distribution of more binaries that are worse
optimised. I am in difficulties to imagine why we want that.

> > 2. You can�t make changes to the Qt source code itself and sell your
> > application based on the changed version of Qt.
>
> The LGPL does not allow Qt to make that kind of restriction. I suppose
> it is possible that Qt are using a modified LGPL with additional
> restrictions like this, but I did not see that on their website (though
> I only had a very quick look). The whole point of LGPL is that you -
> either the developer or the end user - can take the code and change it
> as you want. But any changes you make must be made available to anyone
> else to whom you give or sell the binary code, so that they too can
> modify the LGPL'ed code (and re-compile and re-link it). But you can't
> make changes to the Qt stuff and keep these changes secret from your
> customers (as you can when using the commercial Qt license).

Yes, that was what I meant, we can not make unpublished changes to
LGPL library. If we do whatever changes to Qt we have to publish that
modded Qt too and that means again some pain we don't desire.

> > 3. You must inform users of your application that Qt is used in the
> > application in some licence text or in a readme somewhere within your
> > distributed application files.
>
> I don't know that you need mention Qt explicitly like this, but you /do/
> have to provide the user with the source code for the LGPL code (i.e.,
> the Qt library), with any modifications you have made. You can include
> the source directly, or a written offer valid for 3 years (etc., etc.).

If we followed "1." and "2." then we did not make any changes and so
we do not need to publish the Qt library. Then we just mention it as
dependency.

> In practice, at least in the *nix world, you provide the application
> without any Qt library and dynamically link to the shared libraries on
> the end-user's system. As you are not distributing any LGPL code (using
> headers is allowed), you don't have to say much - but of course you
> would list the Qt dll/so files needed as part of your system requirements.

However if we modified Qt and our application needs that Qt then there
must be some ways to acquire the modded Qt in source code form
for all users and ways to check that it is the correctly modded Qt for
application.

> > 4. You must provide a copy of the Qt LGPL licence file together with your
> > distributed application files.
> >
> > These things above can't be show stopper problems.
>
> They are not - a lot of systems are made using the LGPL versions of Qt.
>
> > The biggest annoyance with Qt is that it tends to create large binaries.
> > Lesser annoyance is that it uses custom preprocessors that do not
> > understand too well C++ (particularily templates and preprocessor) and
> > other tools tend also not to understand Qt crap (underlining it red
> > and reporting errors).
> >
>
> It is this second point that puts /me/ off using Qt - I can live with
> big binaries for my PC software.

If to use Qt only as GUI layer and to develop that with Qt tools (drag
and drop like OP asked) then it is easy. If to use it as framework for
whole application then eventually there will be desire to use other
tools (that may need to read/write code) and that it is difficult.

> Another annoyance is that until relatively recently, the Python bindings
> (PyQt) were under the GPL (or a commercial licence), rather than the
> LGPL (or Python licence), meaning you couldn't use Python and Qt without
> making the whole application as GPL or paying for the commercial
> license. Now that Nokia's PySide bindings are complete for Python LGPL
> Qt development, I might look again at it for future software.

That PyQt is AFAIK separate (not C++; Python) plugin by separate
corporation. There are other ways how to bind Python to C++ project.

[David Brown]

On 13/01/14 19:34, �� Tiib wrote:
> On Monday, 13 January 2014 15:58:37 UTC+2, David Brown wrote:

>> On 05/01/14 05:06, �� Tiib wrote:
>>> On Sunday, 5 January 2014 02:36:34 UTC+2, Ike Shaffer wrote:
>>>> Mr Flibble wrote:
>>>>
>>>>>> Then I guess you can skip reading that LGPL manifest and just send an
>>>>>> e-
>>>>>> mail to them, telling that you intend to use their crap, and make big
>>>>>> money.
>>>>>>
>>>>>> Let them call you an imbecile! LOL
>>>>>>
>>>>>> You are a wise man flib
>>>>>
>>>>> I've decided that as well as being an idiot you are also a troll so
>>>>> welcome to my killfile.
>>>>
>>>> Ohh yes, you lost the debate, proved as imbecile.
>>>>
>>>> Just send that email, flib, tell them you won't register nor pay a shit.
>>>>
>>>> Let them conclude this discussion. No need need for their LGPL reading.
>>>
>>
>> (I know this is replying to a week-old post - I've been on holiday.)
>> And of course, IANAL - this is just my understanding of the LGPL in
>> general, and not Qt in particular.
>
> I just posted it to conclude the back and forth trollish name-calling
> with some useful guidance how to do it. I did use words *must* and
> *can't* may be too strongly, sorry. Indeed there are (too painful even
> for my enemies) ways how to not follow that guidance.

Fair enough - I don't think that argument was getting anywhere! But I
like to try to be accurate in such posts, because you never know when
someone will take it out of context and /assume/ it is accurate. And of
course, there is always plenty to learn by getting corrected in Usenet :-)

>
>>> It is perfectly legal to use dynamically linked Qt in commercially
>>> (or how ever you want to license it) distributed application. There are
>>> only such limitations:
>>> 1. Your application must be dynamically linked to the Qt components that
>>> came with your downloaded LGPL Qt distribution. No static linking allowed.
>>
>> That's not quite true (assuming Qt uses the standard LGPL). You can
>> also make your application available in a linkable object form. The
>> point is that the user (anyone legally obtaining the application source
>> or binary) should be able to take the source for the LGPL library (Qt in
>> this case), modify it if they want, re-compile it, and link it with your
>> application code. The linking can be static or dynamic.
>
> However ... we don't want to sell half-built binaries with removed
> link-time optimisations as LGPL 2.1 6.a) ... or do we?

It is unusual, but I have heard of it being done. For code running on
an OS like Windows or Linux, it would be much more practical to put the
secret sauce in a dll/so file if you can't simply use the dynamic
library directly. But for embedded systems, dynamic linking is often
hard or inefficient, and so linkable object files is one way to get a
reasonably efficient, license-compliant and secret solution.

>
>> Of course, having the LGPL code as a dynamic library is by far the most
>> common solution - but linkable object code for static linking is allowed.
>
> The idea of static linking is to distribute less binaries that are better
> optimised. "Allowed" is distribution of more binaries that are worse
> optimised. I am in difficulties to imagine why we want that.

Static linking is also vital for systems that don't support dynamic
linking (such as small embedded systems). And it should be pretty much
equally optimised if I take my secret code, compile it, and link it to a
static version of the LGPL library as if I compile my code and give you
the object files so that you can link in the static LGPL library
yourself. (LTO would change that, but I think using LTO with the LGPL
library could violate the license.)

As I said, it is unusual - but it /is/ a license compliant solution.

>
>>> 2. You can�t make changes to the Qt source code itself and sell your

>>> application based on the changed version of Qt.
>>
>> The LGPL does not allow Qt to make that kind of restriction. I suppose
>> it is possible that Qt are using a modified LGPL with additional
>> restrictions like this, but I did not see that on their website (though
>> I only had a very quick look). The whole point of LGPL is that you -
>> either the developer or the end user - can take the code and change it
>> as you want. But any changes you make must be made available to anyone
>> else to whom you give or sell the binary code, so that they too can
>> modify the LGPL'ed code (and re-compile and re-link it). But you can't
>> make changes to the Qt stuff and keep these changes secret from your
>> customers (as you can when using the commercial Qt license).
>
> Yes, that was what I meant, we can not make unpublished changes to
> LGPL library. If we do whatever changes to Qt we have to publish that
> modded Qt too and that means again some pain we don't desire.

OK. You /said/ that you can't make changes - but it is precisely the
ability to make changes that a major motivation for the GPL/LGPL. So it
is good to get this clarified. (And if anyone is in any doubt as to
what "publishing the modifications" means here, they can look it up in
the GPL/LGPL faq pages, because it is too complicated to explain here...)

>
>>> 3. You must inform users of your application that Qt is used in the
>>> application in some licence text or in a readme somewhere within your
>>> distributed application files.
>>
>> I don't know that you need mention Qt explicitly like this, but you /do/
>> have to provide the user with the source code for the LGPL code (i.e.,
>> the Qt library), with any modifications you have made. You can include
>> the source directly, or a written offer valid for 3 years (etc., etc.).
>
> If we followed "1." and "2." then we did not make any changes and so
> we do not need to publish the Qt library. Then we just mention it as
> dependency.
>
>> In practice, at least in the *nix world, you provide the application
>> without any Qt library and dynamically link to the shared libraries on
>> the end-user's system. As you are not distributing any LGPL code (using
>> headers is allowed), you don't have to say much - but of course you
>> would list the Qt dll/so files needed as part of your system requirements.
>
> However if we modified Qt and our application needs that Qt then there
> must be some ways to acquire the modded Qt in source code form
> for all users and ways to check that it is the correctly modded Qt for
> application.

Yes - although "all users" means everyone to whom you have legally given
or sold the code. You don't have to make it publicly available (but you
can't stop people who have legal access to the code from taking the
modified LGPL code and passing it on to anyone else).

I don't think you have to provide any way to /check/ that the Qt part of
your binaries is generated from the modified Qt code you distribute -
but if it is not the same, then you are breaking the LGPL license. And
users must be able to compile the modified Qt code and link it in
themselves - in that way they can be sure what code is running.

>
>>> 4. You must provide a copy of the Qt LGPL licence file together with your
>>> distributed application files.
>>>
>>> These things above can't be show stopper problems.
>>
>> They are not - a lot of systems are made using the LGPL versions of Qt.
>>
>>> The biggest annoyance with Qt is that it tends to create large binaries.
>>> Lesser annoyance is that it uses custom preprocessors that do not
>>> understand too well C++ (particularily templates and preprocessor) and
>>> other tools tend also not to understand Qt crap (underlining it red
>>> and reporting errors).
>>>
>>
>> It is this second point that puts /me/ off using Qt - I can live with
>> big binaries for my PC software.
>
> If to use Qt only as GUI layer and to develop that with Qt tools (drag
> and drop like OP asked) then it is easy. If to use it as framework for
> whole application then eventually there will be desire to use other
> tools (that may need to read/write code) and that it is difficult.
>
>> Another annoyance is that until relatively recently, the Python bindings
>> (PyQt) were under the GPL (or a commercial licence), rather than the
>> LGPL (or Python licence), meaning you couldn't use Python and Qt without
>> making the whole application as GPL or paying for the commercial
>> license. Now that Nokia's PySide bindings are complete for Python LGPL
>> Qt development, I might look again at it for future software.
>
> That PyQt is AFAIK separate (not C++; Python) plugin by separate
> corporation. There are other ways how to bind Python to C++ project.
>

That is correct - PyQt is from a third-party commercial company. The
"official" Python Qt bindings (from Nokia, I believe, and now handled by
the new Qt folk) are PySide, which will make Python Qt development a lot
easier (as well as having the LGPL license rather than just commercial
or GPL). Of course, there were always other ways to get Python code to
work with Qt - but not as easily, and not with as current Qt support.