[En-Nut-Discussion] qnutconf

[Thiago A. Corrêa]

Hi,

    I've checked in some new code, I finally did the delegate thing.
Now radio buttons are drawed, and it's now possible to edit combo box
options such as GPIO settings.

On Tue, Dec 1, 2009 at 8:19 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Thiago A. Corrêa wrote:
>>> use initially, it always fails with "Erro: There was a problem opening
>>> the file, please check the log message." and and
>>
>> Hmmm hard to say. It´s easier to place a break point at the loading of
>> the file and follow the calls to see where it goes wrong. It shouldn´t
>
> Tried that and found, that it is a little bit hard to debug with almost
> no knowledge about how Qt works. Not to mention modifying the code after
> discovering a bug. In the meantime I became more familiar with it and
> started to write a few sample apps. I also started to port the Nut
> Discoverer.
>

Most important thing is to figure out how signals and slots works.
That's the core concept of "message passing" in Qt. All gui "events"
are handled that way. The GUI class emit a signal, that is caught and
handled by the slot connected to it.

Btw, I have a "Nut Discovery" model. I use it within my own simple nut
discovery program and some other tools that need to enumerate nuts on
the network. I could send it to you.

>> Can´t remember what might be wrong. As I said to Ole, I only tried
>> with avr32 .conf files, which one did you load?
>
> Tried the EVK1100 as well. It works fine with Ole's Linux build but
> fails on Windows, while Ole experiences the same problem on Linux. Quite
> funny.
>

Can't imagine what might be wrong. Perhaps the folder where it's run
from. But the strange thing is, if you build it from a clean svn
checkout, an run it at the folder where it's sources are, it should
work.
It also should work on the same folder where nutconf works.

>> install. Then place the Qt\version\bin to path. You could also use Qt
>> Creator, an IDE from Trolltech (Nokia now).
>
> Yeah, well... I'm used to MSVC and flinch to from using a new IDE for
> each project. Anyway, the VC integration works well and I don't think
> anymore, that the tools are the problem. Note, that Ole experiences the
> same problem on Linux.
>

By the way, 4.6.0 was released today, and looks like there is a new
integration plugin released as well. I tried with 4.6.0 under windows
and it works good as well (previously using 4.5.2)

>> Outch, I wasnt aware of that. I got an EVK1104, but didn´t have the
>> time to play with it yet :(
>
> Btw. did you also remove the plastic foil placed on the touch sonsors?
> ;-) I did and than read that I spoiled the board. Well, not really. It
> later turned out, that they are not working well at all.

Plastic foil? What plastic foil? Damn...
My mistake, this one is EVK1105 not 1104. It does have touch sensors,
but no plastic in it.

> Anyway, after modifying the RS-232 initialization locally, Nut/OS seems
> to run fine on this board. I recently added an Ethernet Null Driver to
> get rid of linker problems when trying to compile _all_ Nut/OS samples.
>

What kind of modification was required? Perhaps it's something
specific to that chip or revision?

>> Then, I use the build system to build this or that arch code (much
>> like Trolltech did with Qt). This reduces a lot the #ifdefs.
>> I could commit it, but then as I said, it's very primordial support
>> and doesn't even build fully. I guess we could extend for tha AP7xx
>> later if someone wishes to use it for standalone code.
>
> Right now I'm quite satisfied with your work for the UC3 and won't have
> time to try the AP7, but in long term I'm most interested, of course.

I'm using the AP7 for linux embedded projects. So far I don't think I
will use it for Nut/OS projects, but I would like to support as many
AVR32 silicons as possible.

> Btw. Michael Fischer is looking into USB support for the UC3 under Nut/OS.
>

USB is quite complex beast. It would be very interesting to see it in Nut/OS.

Kind Regards,
    Thiago A. Correa