currently the domain www.hiqt.org is offline and the google groups
page is IMHO just an interim solution - but not really satisfying.
What do I expect?
- screenshots and features page (advertisment is indispensable)
- download area for latest releases (ready-to-use packages for win32 + linux)
- developer area with pages for docu, tools, todo, wishlist, current state
- ...maybe a ticket system? would be a nice tool to control and trace the dev. work
- the new page must be editable by multiple users in a simple way (to be up to date)
- integration of subversion would be cool - e.g. for making fancy colored diffs etc. :-)
Trac - a very flexible and simple to use ticket and wiki system with a huge
amount of available plugins. I use it in my company as developer corner and
company intranet for more than a year now.
The problem with Trac is: We need a webserver which can run this a little
bit more complex environment (Python, Subversion etc.). I'll ask my
colleagues from our partner company next floor (an ISP) for a server...
Other alternatives (blogs etc.) are possible, too... because the google groups
site is not sooo well suited to work as a development project headquarter.
Next: the domain
www.hiqt.org is currently offline and doesn't match the current project name -
so we could try to get www.haiq.org - it's currently registered but not used
by an armenian person - so I could try to get (buy) the domain from him/her.
What do you think?
currently I'm already looking for a new root server for some
other projects - so maybe this server could be used for our
trac + website, too.
Backup and reliability should be no problem - the ISP uses the
same servers for running critical application of financial institutes.
For the moment I've no info about costs - but I'll try to get
it as free as possible ;-)
today I started using HaiQ with WinXP Pro SP2 and VisualStudio 2005 SP1
and Qt 4.4.0 for the first time.
Running "qmake & nmake" on a big project causes HaiQ to crash with
"stack overflow" in QtCore4.dll in the handler for the message queue.
I tried setting the stack size to 8 MB for the HaiqBuilder thread,
but nothing helps.
Further I encountered a big design issue in the builder thread:
The QProcesses for running make & co are childs of the builder thread -
but all of their messages/signals are processed by the gui thread
and calling process->waitForFinished() blocks the gui thread.
Reason: There is no separate event loop - only the main gui thread
has one. Solution: the builder thread must call "exec()" inside it's
"run()" method and all the existing stuff inside run must be rewritten
as a slot, which is called in an async way (e.g. by emitting a signal
in first line of "run()" and then call "exec()").
As far as I got some time to test it, I'll rewrite the builder thread to
work completely in parallel of the gui event loop - this should prevent
the gui to slow down.
But: I didn't figure out the stack problem till now - could it be that the
output of the qmake process is sent via signals/events? If so, this could
explain the overflow, because of the huge messages my make call
produces for the big project.
PS: Here some other win32-only issues:
- closing HaiQ causes the output window (when docked off) to close after
a waiting time of ca. 30s later than the mainwindow
- the position of docked off windows isn't correctly restored - especially
on multimonitor systems, when the docked off win is on left and mainwin
on the right screen/monitor