Website

[Christian Dähn]

Hi,

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. :-)

Proposal:
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.

Demo:  http://www.hosted-projects.com/trac/TracDemo/Demo/wiki
Homepage:  http://trac.edgewall.org

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?

ciao,
Chris

[Jose Maria Garcia-Valdecasas]

Hi,

I really like Trac system, although as Chris says, we need a more dedicated webserver. Anyways, as i will be offline due to holidays (i will spend the next 9 days windsurfing the whole day) anything you decide will be ok.

Cheers, Jose

2008/7/9 Christian Dähn <da...@asinteg.de>:

[jeremy....@gmail.com]

Hi Chris, I agree with everything you are saying. Personally, I use HaiQ every day, so I have great desire for the project to move forward from the standpoint of a user, and I know there are many performance issues that need to be addressed.

Chris, if you could take the lead on finding/setting up a new hosting location that would be great (we can split the costs if there is some expense, but of course free is preferred :))  I think I like Trak system, although I'm not too familiar.

Jeremy

[Christian Dähn]

Hi Jeremy,

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 ;-)

ciao,
Chris

[Christian Dähn]

Hi,

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.

ciao,
Chris

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

[jeremy....@gmail.com]

Hi Chris, Yes I agree that build message handling is a big problem. I think the build module should be redone. To answer your question about output of qmake being sent as signals: yes I think this is the case.
Jeremy