[En-Nut-Discussion] NutCOnf/Qt (was: RFC: Using CMake)

[Thiago A. Corrêa]

Hi Harald,

On Tue, Sep 8, 2009 at 8:40 AM, Harald Kipp<harald.kipp at egnite.de> wrote:
> Hi Thiago,
>
> As this might become a discussion of its own, I changed the subject.
>
> Thiago A. Corrêa wrote:
>
>> On Tue, Sep 8, 2009 at 7:47 AM, Harald Kipp<harald.kipp at egnite.de> wrote:
>>> Actually I'm not sure about wxWidgets anymore, since Nokia changed the
>>> Qt license. Remember, that we are waiting about 2 years for wxWidgets 3
>>> and there is not even an announcement of its release.
>>>
>>
>> Interesting you mention it *smile*. I've used Qt for years.
>
> GUI programming is not trivial and the more libs you use, the more
> confusing it may become. Most people involved in open source also do
> closed projects. Saving the royalties for commercial projects was a plus
> of wxWidgets.

Now that Qt is released under the LGPL, it's possible to do both open
and closed source development with it without paying.
I have a full Qt license for Windows, therefore I am not bound to any
license in this code I've wrote. I could release it in any license you
like, and even double license it.

What I don't like about the GPL is exactly that, say, I start working
in a project with someone GPL'ed. Fine, years after, I want to take
some snippets for the closed source project I'm working on, which will
bring me food to the table. I might be violating someone's rights if
I'm not 100% sure that this snipped was mine ( and therefore I have
the right to relicense it the way I choose).

There is nothing I'm getting from the old Nut Configurator except for
the common C code that handles Lua and as far as I can tell, that is
not GPL (doesn't have a header) and I haven't distributed either
source or binary yet, so not licensed :D

> From what I know so far, Qt has a native look. But does it feel native?
> Another advantage of wxWidgets is, that it uses native controls, while
> Qt uses generic ones. One example is the file select dialog. Unless you
> use the optionally available generic wxWidgets dialog, the user will
> recognize no difference, whatever platform the application runs on.

Yes, fells completely native. If I build a binary statically, you
can't tell it's Qt just by looking at it. Unlike Delphi, C++ Builder,
VB and many other stuff that I can usually spot :P
The "Open File Dialog" does use the native API. Most widgets are
abstracted at the draw level, not using native widget API from
Windows, but they do feel like native controls.
That's the major difference with wxWidgets, they are a thin wrapper
around native widget calls. I hear that they were changing with
wxUniversal or something like that to follow the way Qt does it, that
is, to abstract at the draw level.

You could download from QtSoftware a copy and check the examples,
there are tons of it.

> There are drawbacks as well. Controls like the nutconf module tree,
> which are not available on all targets, never worked flawlessly with all
> GUI libs. I saw, that Qt provides such a control.
>

Yes, Qt has QTreeView. The only problem with my implementation right
now regarding the tree visualization is the checkboxes inside the
tree. Qt doesn't have checkboxes as the tree items natively. What I
have to do is actually create delegate class that will show up the
checkboxes. Shouldn't be hard to do, but I left this cosmetic stuff
for later. I wanted to get it building first so I would show it to you
guys :)

>> I've been working on a substitute to the configurator using Qt. I can
>> already load config files, and show the configuration tree like the
>> current configurator. Right now I'm missing some of the registry
>> settings loading/saving and the build. I would say that I'm 65% done.
>> I work on it from time to time, but right now it's on hold for a
>> little while.
>
> Really interesting. I planned to spend a weekend to give it a first try.
> Looks like you saved me from the basic work.
>

You could check the Qt examples anyway. It comes with the library, and
they are very nice.

>> Right now I'm keeping it private until I get it fully working (ie,
>> building Nut/OS) but I could share the code. I could even make it BSD,
>> since it has no link with the GPL'ed one anymore, and I don't like the
>> GPL so much, even if write GPL code from time to time.
>
> Nut/OS tools are typically GPL, because they don't need to be included
> into the final product. My last experience with GPL was OpenOCD and FTDI
> drivers...a nightmare. On the other hand, GNU really helps in cases,
> where others try to ignore licenses at all.
>
> Anyway, the original author dictates the license. As far as code has
> been taken over from the wxWidgets version, I officially agree here to
> use the same code under BSDL as well. However, I stole a lot of things
> from the eCos configtool, that was released under GPL. If you like, I
> can try to sort this out before we officially release the code.
>

I think there is no need.
Firstly because I'm not reusing any of the eCos code as far as I know.
Also, I'm fine with it being GPL. I consider BSDL to be more free than
GPL but I'm not that worried about it.
If it comes to that, we could rewrite the Lua C code interface,
perhaps using C++ could make it more efficient without all the
strdups.

Kind Regards,
    Thiago A. Correa