Jason Lucas | 4 Dec 17:00 2009

KTechlab website

Lawrence, Have you been able to make any progress with the Ktechlab
website?

Jason.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
Julian Bäume | 7 Dec 13:35 2009
Picon

a matter of style

hi again,
I want to have short input on which iterators to use. Qt provides both, STL- 
and JAVA-style iterators. Here an example:
java-style:
    QStringListIterator it(route);
    QPointF p;
    p.setX(it.next().toDouble()*8);
    p.setY(it.next().toDouble()*8);
    moveTo( p );
    while (it.hasNext())
    {
        p.setX(it.next().toDouble());
        p.setY(it.next().toDouble());
        p*=8;
        lineTo( p );
    }

same code with STL-style:
    QStringListI::const_iterator it = route.constBegin();
    QPointF p;
    p.setX((*it++).toDouble()*8);
    p.setY((*it++).toDouble()*8);
    moveTo( p );
    while ( it != route.constEnd() )
    {
        p.setX((*it++).toDouble());
        p.setY((*it++).toDouble());
        p*=8;
        lineTo( p );
    }
(Continue reading)

Julian Bäume | 7 Dec 13:14 2009
Picon

some progress

hi,
I just wanted to show some progress, I made with the kde4 port. I implemented 
basic functionality of drawing connectors (graphical representation of a 
wire), tonight. The nights before, I refactored the work I did on drawing 
components. It's now based on QGraphicsView system. I noticed some conflicts 
between the old QCanvas implementation and the new one, regarding coordinate 
systems and reference points. Therefore I'd like to slightly change the 
circuit-file format, to make it fit better to the needs of the new graphics-
system. I'm not sure, how exactly I want to change it, but I don't like it, as 
it is done, at the moment. One example I don't like is the use of different 
reference points and scales. A route in a connector is stored relatively to an 
8x8 grid, item's coordinates are stored in absolute pixel-values. I still 
don't want to break old files, so I want to provide some legacy code, to load 
old style circuit files and save them as the new version. But as I said, I 
need to clarify some things, before proceeding (i.e. implement write support).

I got some screen-shots:
First one is very old.. it shows my first tests with plasma.. but there is the 
KDE3 version of ktechlab, showing a circuit file, I use for testing:
http://nbprogs.dyndns.info/~jb/screen/ktechlab-circuit.png

Then, the same file loaded with the version from "circuit_rewrite" branch:
http://nbprogs.dyndns.info/~jb/screen/ktechlab-circuit1.png
Note, the connectors are exactly the same, the components still have got some 
scaling and minor positioning issues (due to problems, I explained earlier in 
this mail).

And the same, but with Theme::defaultTheme() set to "us" instead of "din": 
http://nbprogs.dyndns.info/~jb/screen/ktechlab-circuit2.png
Again, there's some issues with the scale of the components, but this can be 
(Continue reading)

Alan Grimes | 7 Dec 17:14 2009
Picon

Re: a matter of style

Yeah, my vote is for the shortest code whenever possible. This has a
number of advantages. However I also prefer STL wherever possible
because it won't be changing in QT5... That said, some of my conversions
to STL were ill advised. =(

--

-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
Alan Grimes | 7 Dec 17:20 2009
Picon

Re: some progress

Julian Bäume wrote:
> hi,
> I just wanted to show some progress, I made with the kde4 port. I implemented 
> basic functionality of drawing connectors (graphical representation of a 
> wire), tonight. The nights before, I refactored the work I did on drawing 
> components. It's now based on QGraphicsView system. I noticed some conflicts 
> between the old QCanvas implementation and the new one, regarding coordinate 
> systems and reference points. Therefore I'd like to slightly change the 
> circuit-file format, to make it fit better to the needs of the new graphics-
> system. I'm not sure, how exactly I want to change it, but I don't like it, as 
> it is done, at the moment. One example I don't like is the use of different 
> reference points and scales. A route in a connector is stored relatively to an 
> 8x8 grid, item's coordinates are stored in absolute pixel-values. I still 
> don't want to break old files, so I want to provide some legacy code, to load 
> old style circuit files and save them as the new version. But as I said, I 
> need to clarify some things, before proceeding (i.e. implement write support).

I did a cleanup pass of the connector code about a month ago. I hope you
are basing your changes to connectors off the current SVN, it is
considerably less buggy and more readable...

--

-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
(Continue reading)

P Zoltan | 7 Dec 21:49 2009
Picon

Re: a matter of style

On Mon, 07 Dec 2009 13:35:03 +0100, Julian Bäume <julian <at> svg4all.de> wrote:

> hi again,
> I want to have short input on which iterators to use. Qt provides both,  
> STL-
> and JAVA-style iterators. Here an example:
> java-style:
>     QStringListIterator it(route);
>     QPointF p;
>     p.setX(it.next().toDouble()*8);
>     p.setY(it.next().toDouble()*8);
>     moveTo( p );
>     while (it.hasNext())
>     {
>         p.setX(it.next().toDouble());
>         p.setY(it.next().toDouble());
>         p*=8;
>         lineTo( p );
>     }
>
> same code with STL-style:
>     QStringListI::const_iterator it = route.constBegin();
>     QPointF p;
>     p.setX((*it++).toDouble()*8);
>     p.setY((*it++).toDouble()*8);
>     moveTo( p );
>     while ( it != route.constEnd() )
>     {
>         p.setX((*it++).toDouble());
>         p.setY((*it++).toDouble());
(Continue reading)

Julian Bäume | 8 Dec 00:45 2009
Picon

Re: a matter of style

On Monday 07 December 2009 21:49:11 P Zoltan wrote:
> > My votes for the record:
> > java-style iterators and foreach-macro, when possible
> 
>   +1, the STL style is not my favorite
So I guess, it's 2 vs 1 in favour of STL style, for now ;)

>   foreach is something new for me, so I don't have a string opinion about
> that. Note that instead of that while(), a for() could be also used in
> java style code:
> 
>    for(QStringListIterator it(route); it.hasNext(); ??? ) { ... }
> 
>   Where do you increment that iterator? It's strange.
it.next() will increase the position and return the object. If you don't want 
to increase the pointer, use it.peekNext(). It will just return the object. 
During the first cycle of the loop, it.peekNext() will return the first 
element, until it.next() is called. This is slightly more code, than with STL 
iterators, of course. But IMHO this is much more readable.

So your example would read like:
    for(QStringListIterator it(route); it.hasNext(); it.next() ) { //use 
it.peekNext() to point to the object... }

Also note, QStringListIterator is a const iterator. You can only access the 
objects in the list read-only. If you want to alter the objects, you need to 
use QMutableStringListIterator, instead. (Same applies for STL-style. there is 
QStringList::iterator and QStringList::const_iterator)

Concerning the foreach-macro, well. It's just useful in the special case, when 
(Continue reading)

Julian Bäume | 8 Dec 01:02 2009
Picon

Re: a matter of style

On Monday 07 December 2009 17:14:40 Alan Grimes wrote:
> Yeah, my vote is for the shortest code whenever possible. This has a
> number of advantages. However I also prefer STL wherever possible
> because it won't be changing in QT5...
:) Okay, the container-classes changed their api, slightly in Qt4, but 
(there's always a but ;)) with good reasons. The work needed to go to the new 
API is quite minimal. The classes are changed to be more compatible with java 
container classes, as well as STL ones. Believe me, changes in the container 
API are not our problem ;) And I believe, the API will be the same in Qt5, 
also. I have not heard of any objections against this API ;)

> That said, some of my conversions to STL were ill advised. =(
Well, I think, this is because the STL container classes expose you more to 
the complexity of C++. The Qt API encourages you to use pointers, only when 
really necessary (many things can be expressed equally using references). This 
should result in more stable code. And it also encourages you to use the const 
keyword, whenever possible. This also helps reducing common mistakes, like 
doing stuff like "if ( myObj1 = myObj2 ). (This won't compile, when myObj1 is 
declared as const ;))

That's why I think, the Qt API helps to write better code. I saw a construct 
in the code, reading: "Cell **m_cell;" or something like that. WTF? ;) This is 
not C, it's C++. Such expressions should really be avoided and I can't think 
of any example, where there is no other way of expressing this.

Okay, just my 2ct.

bye then
julian
(Continue reading)

Alan Grimes | 8 Dec 02:55 2009
Picon

Re: a matter of style

Julian Bäume wrote:
> That's why I think, the Qt API helps to write better code. I saw a construct 
> in the code, reading: "Cell **m_cell;" or something like that. WTF? ;) This is 
> not C, it's C++. Such expressions should really be avoided and I can't think 
> of any example, where there is no other way of expressing this.

I'm a C programmer. =\

Sure, C++ is great for organizing stuff but it's HORRIBLE for
algorithms. For algorithms, I require a language that executes directly
instead of vertically (try debugging a STL call). I need to be able to
think in terms of register moves, pushes and pops, and of the memory be
it stack, heap, or data, and understand exactly what the hell is slowing
shit down. =\  The connector routing code is inherently a slow problem,
and therefore to get acceptable performance I reverted to the style
which I prefer to get the damn thing to work. -- that said, you can
compare my revisions to the archival code and make your judgment about
what I've done with it.

--

-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
(Continue reading)

Julian Bäume | 8 Dec 08:17 2009
Picon

Re: a matter of style

On Tuesday 08 December 2009 02:55:56 Alan Grimes wrote:
> Julian Bäume wrote:
> > That's why I think, the Qt API helps to write better code. I saw a
> > construct in the code, reading: "Cell **m_cell;" or something like that.
> > WTF? ;) This is not C, it's C++. Such expressions should really be
> > avoided and I can't think of any example, where there is no other way of
> > expressing this.
> 
> I'm a C programmer. =\
I didn't mean to offend you, here :)

> Sure, C++ is great for organizing stuff but it's HORRIBLE for
> algorithms. For algorithms, I require a language that executes directly
> instead of vertically (try debugging a STL call). I need to be able to
> think in terms of register moves, pushes and pops, and of the memory be
> it stack, heap, or data, and understand exactly what the hell is slowing
> shit down. =\ 
I disagree, here. You can write nearly as fast code with C++ and Qt, as you do 
with plain C++ or plain C. If an algorithm is slow, it can be because of many 
things. One thing is bad implementation. If you copy around stuff a lot, 
especially when it is not needed, you waste a lot of time (memory operations 
are damn slow). Bad implementation can be avoided. Another thing is 
algorithmic complexity. You won't be able to implement (perfect) routing in a 
fast way. So you need to implement heuristics, that solve the problem fast, 
but not with optimal results. These problems can't be avoided. (Not yet ;)) 
All these problems have a real impact on the speed of programs like KTechLab. 
The overhead Qt or any other library might bring here shouldn't count much.

> The connector routing code is inherently a slow problem,
> and therefore to get acceptable performance I reverted to the style
(Continue reading)


Gmane