Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Mike Johnson <mrjohnson@mi...> - 2008-01-09 00:04:05
okay, i committed my big patch. the vast majority of it is a simple find
and replace of Q3ListView with toTreeWidget.
the problem i encountered is that qt _really_ doesn't want you to use
what they call "item based" widgets. where you create an item and add it
to a widget. they want you to use a mvc model.
porting q3listview is not easy because were tora used one widget for
practically everything, whether it was a simple table or a tree, qt4 has
two widgets for things like that. you'll notice as you use tora with
this patch there's a drop down indicator on the first column that i
can't get rid of... this is why.
after tearing my hair out for a while, i gave in and created
toresultmodel and toresulttableview. the tableview is derived from
toresult so it can be used just like other resultview classes. and i
have to concede, it was quite a bit nicer. the old, nasty, evil
toresultview has all sorts of hacks for tool tips, column widths,
painting, etc. horrid code. using the model and tableview classes, much
of that was really easy.
and -- really cool -- data storage doesn't have to be all strings. so i
can store my toQValues and sort with them instead of the old way:
db -> number -> text -> widget -> text -> number -> compare -> text
the best way forward that i see is to move everything that displays data
from a sql query to toresulttableview. this should be pretty easy. i may
have to add a signal here or there, but it's currently in place on the
worksheet and working well.
next, for the widgets left over that actually use a tree hierarchy, we
make them children of toTreeWidget and remove toresultview and
tolistview altogether (yay!). this shouldn't too terrible since most of
it is in place already.
i can already hear somebody asking: why use totreewidget at all and
simply convert everything to QTreeWidget? because it's a _lot_ of code
that depends on that. not saying that's a bad way to go, but i think
we're still going to need a subclass of QTreeWidget that does formatting
things we want even if it no longer supports the old apis.
i've done what i can, but if some enterprising fellow wanted to know
what still needed done, here's what i can think of to start with:
- the list formatters (tolistviewformatter*cpp) need to be converted to
use / accept models for their data. it can be defined as toresultmodel
and drop tolistview altogether because i don't expect exporting those to
be very handy for long.
- nextSibling in totreewidget is pretty broken (heck, i couldn't even
find a good description of what it's supposed to do) and there's some
really awful code that's been copy and pasted all over the place. in
most cases, all the tool needs to do is loop through all the items. the
proper way to do that would be to use toTreeWidgetItemIterator.
- anything that is using addColumn() can be changed to use QStringList
and setHeaderLabels(). my addColumn is a dirty hack. :-)
anyway, sorry for keeping this local for so long. it was horribly broken
for quite a while...
oh... on a personal note, i'm out of the Marine Corps now. i'm starting
my civilian job on the 14th, which is why i've been pushing so hard to
get stuff done on tora. i won't have as much time to hack starting next
week but i'll be around to finish porting and to support tora.