Nice tutorial for the theme. http://www.sepcot.com/blog/2007/04/SVN-Merge-Branch-Trunk
2010-01-31
2010-01-29
Useful Qmake Variables
The reference of qmake variable can be found http://doc.trolltech.com/4.6/qmake-variable-reference.html. Two of useful variables
OBJECTS_DIR = .obj
MOC_DIR = .moc
specifiy the location of temporary files. In above example, they are located at the .obj and .moc.
OBJECTS_DIR = .obj
MOC_DIR = .moc
specifiy the location of temporary files. In above example, they are located at the .obj and .moc.
2010-01-28
Z Value of GraphicsItem
Z value of each QGraphicsItem determines its stacking order of visibility in parent items.
It can be explicitly specified by setZValue( qrea z ) . Otherwise, it is decided by the order of being assigned to its parent through these two functions:
It can be explicitly specified by setZValue( qrea z ) . Otherwise, it is decided by the order of being assigned to its parent through these two functions:
- QGraphicsItem::setParentItem ( QGraphicsItem * parent )
- QGraphicsItemGroup::addToGroup ( QGraphicsItem * item )
Use qmake include file pri
Qmake use pro file to define the project, while pri file is the include file for pro file. For example, the Qt state machine modual has a "qtstatemachine.pri" for external inclusion, you need to simply add
include(../../externals/qtstatemachine/src/qtstatemachine.pri)
into pro file to compily your code together with Qt state machine framework.
You can also optimise the modulise your code for external usage. Take an example, I have implemented a clock object by several classes. The classical pro file may looks like:
######## clock.pro #########################
TEMPLATE = app
TARGET =
DEPENDPATH += .
INCLUDEPATH += .
# Input
HEADERS += clStateMachine.h \
clThread.h
SOURCES += clStateMachine.cpp \
clThread.cpp \
main.cpp
include(../../externals/qtstatemachine/src/qtstatemachine.pri)
#######################################
Clearly, main.cpp is for the purpose of testing the object, the clock object is implemented in the other file. If you want to reuse this object in the other project, which may be located at the different path, you'd better to use pri file to modulize your object implmentation. Create a clock.pri at the same directory like:
######## clock.pri #########################
INCLUDEPATH += $$PWD
HEADERS += $$PWD/clStateMachine.h \
$$PWD/clThread.h
SOURCES += $$PWD/clStateMachine.cpp \
$$PWD/clThread.cpp
include($$PWD/../../externals/qtstatemachine/src/qtstatemachine.pri)
########################################
The old clock.pro is adapted like:
######### clock.pro (new) ###################
TEMPLATE = app
TARGET =
DEPENDPATH += .
# Input
SOURCES += main.cpp
include(./clock.pri)
########################################
Now you include your clock.pri in any other project by adding the following line into the pro of your project
include({relative or absolute path of clock.pri})
include(../../externals/qtstatemachine/src/qtstatemachine.pri)
into pro file to compily your code together with Qt state machine framework.
You can also optimise the modulise your code for external usage. Take an example, I have implemented a clock object by several classes. The classical pro file may looks like:
######## clock.pro #########################
TEMPLATE = app
TARGET =
DEPENDPATH += .
INCLUDEPATH += .
# Input
HEADERS += clStateMachine.h \
clThread.h
SOURCES += clStateMachine.cpp \
clThread.cpp \
main.cpp
include(../../externals/qtstatemachine/src/qtstatemachine.pri)
#######################################
Clearly, main.cpp is for the purpose of testing the object, the clock object is implemented in the other file. If you want to reuse this object in the other project, which may be located at the different path, you'd better to use pri file to modulize your object implmentation. Create a clock.pri at the same directory like:
######## clock.pri #########################
INCLUDEPATH += $$PWD
HEADERS += $$PWD/clStateMachine.h \
$$PWD/clThread.h
SOURCES += $$PWD/clStateMachine.cpp \
$$PWD/clThread.cpp
include($$PWD/../../externals/qtstatemachine/src/qtstatemachine.pri)
########################################
The old clock.pro is adapted like:
######### clock.pro (new) ###################
TEMPLATE = app
TARGET =
DEPENDPATH += .
# Input
SOURCES += main.cpp
include(./clock.pri)
########################################
Now you include your clock.pri in any other project by adding the following line into the pro of your project
include({relative or absolute path of clock.pri})
2010-01-27
Set SVN Global Ignore Pattern
Edit the file
reference:
~/.subversion/config
and uncomment global-ignores = *.*
list. Add any file pattern you want to be ignored. thats all.reference:
Q_PROPERTY example
class CLLcd : public QLCDNumber
{
Q_OBJECT
Q_PROPERTY( bool editable READ editable WRITE setEditable )
public:
bool editable(){return editable_; }
void setEditable(bool editable_in){editable_=editable_in;}
private:
bool editable_;
}
{
Q_OBJECT
Q_PROPERTY( bool editable READ editable WRITE setEditable )
public:
bool editable(){return editable_; }
void setEditable(bool editable_in){editable_=editable_in;}
private:
bool editable_;
}
2010-01-22
Make LCDNumber Transparent
2010-01-21
Java-style Iterator vs. STL-style Iterator
The best comparison of Java-style and STL-style iterator is given in this article: http://doc.trolltech.com/4.5/containers.html#the-foreach-keyword. Some citations for summary:
- Java-style iterator. "..Unlike STL-style iterators (covered below), Java-style iterators point between items rather than directly at items. For this reason, they are either pointing to the very beginning of the container (before the first item), at the very end of the container (after the last item), or between two items..."
- STL-style iterator: "...The API of the STL iterators is modelled on pointers in an array. For example, the ++ operator advances the iterator to the next item, and the * operator returns the item that the iterator points to..."
Foreach in Qt Container
Great! Qt container supports foreach iteration, which simplies largely the code. See the example for comparison:
========= java-like iterator===============
QLinkedList<> list;
...
QLinkedListIterator<> i(list);
while (i.hasNext())
qDebug()<< i.next()
========== STL-like iterator=============
QLinkedList<> list;
...
QListedList<>::const_iterator it = list.begin();
while( it!= list.end())
{
qDebug()<< (*it); ++it; }
=========foreach iteration===============
QLinkedList<>> list;
...
foreach (QString str, list)
qDebug() << str
===================================
Reference:
========= java-like iterator===============
QLinkedList<> list;
...
QLinkedListIterator<> i(list);
while (i.hasNext())
qDebug()<< i.next()
========== STL-like iterator=============
QLinkedList<> list;
...
QListedList<>::const_iterator it = list.begin();
while( it!= list.end())
{
qDebug()<< (*it); ++it; }
=========foreach iteration===============
QLinkedList<>> list;
...
foreach (QString str, list)
qDebug() << str
===================================
Reference:
2010-01-20
Debug Qt Application with gdb
If the Qt application is built in Linux system (Max uses Debian Lenny), you need to just run
However, you need to add debug option into makefile by add line into *.pro file
- > gdb app
However, you need to add debug option into makefile by add line into *.pro file
- CONFIG += config qt
tracert
Ping shows whether the server is online, while tracert checks the way to reach the server.
See the comparison at http://www.werle.com/intagent/k11_4.htm
See the comparison at http://www.werle.com/intagent/k11_4.htm
2010-01-19
Useful gdb commands
- gdb main //start debug
- run //run target
- backtrace //show the calling stack at the point of fault
- x 0xbff972e0 // examine the value in memory
- break 52 or break LinkedList
::remov e //set break - condition 1 item_to_remove==1 //set conditional break
- s //step
- c //continue
- quit //quit
>CONFIG = qt opengl debug
iostream vs. iostream.h
A frequent piece of advice is often given to new C++ programmers is to use instead of or instead of . This is often given with only the explanation that the .h forms are deprecated without explaining what the difference is and why, in fact, using the extensionless version is superior. See the reference:
Two Ways to create QGraphicsProxyWidget
The QGraphicsProxyWidget class provides a proxy layer for embedding a QWidget in a QGraphicsScene. There are two ways to create QGraphicsProxyWidget:
QGraphicsProxyWidget *proxy = scene.addWidget(groupBox);
proxy->setWidget(groupBox);
- use QGraphicsScene::addWidget. Obviously, you need available QGraphicsScene object by hand. See bellow
QGraphicsProxyWidget *proxy = scene.addWidget(groupBox);
- Use QGraphicsProxyWidge::setWidget. And you can add this QGraphicsProxyWidget to scene afterwards
proxy->setWidget(groupBox);
Let Children of QGraphicsItemGroup handle their own event
QGraphicsItem can have its own child QGraphicsItem objects. However, QGraphicsItem has no API (like setItems) to add its child. It is only possible allow the child attach to the parent, like
If "enabled=false", QGraphicsItem Group will not block the child item's event and let child item handle it own event.
- void setParentItem ( QGraphicsItem * parent )
- void addToGroup ( QGraphicsItem * item )
- void removeFromGroup ( QGraphicsItem * item )
- void setHandlesChildEvents ( bool enabled )
If "enabled=false", QGraphicsItem Group will not block the child item's event and let child item handle it own event.
Subscribe to:
Posts (Atom)