From: Christian Kienle <christian-kienle@lo...> - 2004-02-07 22:41:35
know I have joined the mailinglist - oh the last days were really
a big stress ;)
Well - porting sqlitebrowser to Qt would be nice in my opinion.
Why porting it:
- using Qt classes would make the sqlite c api bootless .
- the code would be automatically well documented.
- the sourcecode would be better to read
- less bugs
- less code
Well. We could discuss the SQLite Classes offered by Qt 3.3 -
check here if everything is available what we need.
carpe diem - Qt
Christian Kienle wrote:
> Well - porting sqlitebrowser to Qt would be nice in my opinion.
> Why porting it:
> - using Qt classes would make the sqlite c api bootless .
> - the code would be automatically well documented.
> - the sourcecode would be better to read
> - less bugs
> - less code
> Well. We could discuss the SQLite Classes offered by Qt 3.3 -
> check here if everything is available what we need.
Just to clarify, Chris means using the Qt SQL classes instead of calling
SQLite functions directly and including its source in our tree. The
reason for this is because, starting with Qt3.3, the Qt SQL module
includes support for SQLite directly (previously only mySQL, PostgreSQL
and I believe Oracle were supported.)
Chris, when I started this code I tried to use the Qt SQL API (SQLite
support was in beta at that time.) I could not get it to go far. If I
remember correctly the implementation of cursors was not working with
SQLite, maybe this was a limitation that was corrected before release.
If anyone wants to experiment with the this investigation please feel
free to hack the code as you wish. My only suggestion is that we
maintain the possibility of using SQLite browser in "sql-less" mode if
the users want to do this, still hiding all SQL commands in the
background. Another suggestion could be to start a new branch or a new
module in the sqlitebrowser CVS tree for experimentation with the port,
and then merge it back to the main tree if the results are promising.