Rosegarden

2008/9/20 D. Michael McIntyre <rosegarden.trumpeter@...>:
> I found some QTable -> QTableWidget in several places, and started to switch
> them over to Q3Table instead.
>
No !
Please stop reverting Michael.
Q3 Classes ARE Qt3 ! You are moving backwards !
If you understand the Qt4 API, these should not be to hard to fix.

> What's the logic behind it?
>
The logic behind is to move to Qt4.
Without creating API inconsistencies,
being shure those would bite us
at the end and needed to be fixed anyway.
At the latest when qt3 support will be dropped.
It is much better to do it now, where
we are in the process of conversion.

As I mentioned on the wiki, I'm going to tackle the
errors related to QTableWidget, QListWidget.


some examples:
---------------------------------------------------------------------------------------------------------
QTableWidget->setSelectionBehaviour( QAbstractItemView::SelectRows )

QTableWidgetItem->data( Qt::DisplayRole )->toBool()
or
QTableWidgetItem->data( Qt::DisplayRole )->toString()

> src/gui/studio/DeviceEditorDialog.cpp:72: error:   initializing argument 2
> of 'void QTableWidget::setHorizontalHeaderItem(int, QTableWidgetItem*)'

use
  new QTableWidgetItem( "text" )
instead of
 "text"

---------------------------------------------------------------------------------------------------------

On Saturday 20 September 2008, Emanuel Rumpf wrote:
> No !
> Please stop reverting Michael.
> Q3 Classes ARE Qt3 ! You are moving backwards !
> If you understand the Qt4 API, these should not be to hard to fix.

We decided back at the beginning of August to use Q3Table to keep the old code 
working for now, because QTableWidget required a top down rewrite that would 
be hard to debug and test blindfolded.  I've made some QTableWidget -> 
Q3Table changes to fix errors and get code to build, and I made them under 
the assumption that something had gone wrong back during the mechanized 
conversion phase.

I didn't realize someone was switching things back on purpose.  I've seen no 
discussion of that plan.  Then most recently I noticed someone (presumably 
you) had gone so far as to switch old KListView uses to new QTableWidget 
uses, which is completely baffling to me.  Not only does this require a 
tricky rewrite we were supposed to be avoiding until we had an interactive 
framework in which to operate, but it's a change from an old list view widget 
to a new table widget, which is quite strange on the surface.

If you can make all of that work, then more power to you, but I am in no way 
being unreasonable in asking for an explanation of just what you're up to.

You are totally out of line wagging your finger at me and giving me a lecture 
as though I had no idea what any of this work was about.  I find this deeply 
insulting and offensive, and I'm so pissed off right now I've had to struggle 
through three iterations of this message to maintain a civil tone.
-- 
D. Michael McIntyre

I'm not pointing on anyone. If I sounded offending, I'm sorry for that.
Obviously, we were driving in different directions here, whatever the reason is.
My understanding was, that we were moving to qt4 as far as
possible, keeping qt3 classes only where strongly necessary (q3canvas).
I have not had the impression, that changing to QTableWidget would be
a to difficult conversion.
Converting to QTableWidget didn't seem to produce much more errors,
than I've had before, so I felt encouraged.
I've already submited working fixes for QTableWidget and have been
successfull with a lot of transformation work to qt4.


> I didn't realize someone was switching things back on purpose.
>
Yes, with purpose, but what means "back" here?
The conversions are a step forward to qt4 support,
that's how I see it.

> ..... but it's a change from an old list view widget
> to a new table widget, which is quite strange on the surface.
>
It's the name that changed, not the overall functionality.
Although the the new class makes necessary wraping list- (or table-) entries
in a QTableWidgetItem or QListWidgetItem instance.

> ... I am in no way
> being unreasonable in asking for an explanation of just what you're up to.
>
Right.


So how to move on?
I can't find any good reason to keep the Q3 classes, but
I'd like to here a third person here.
Maybe Chris could state his opinion.

Michael, you are a good writer, but I'm not so much.
Please keep it in mind, when reading my posts.
I might miss the feeling for the appropriate expression,
but I don't want to work against anyone here!
It's just been my intention to push RG forward to qt4.

Best regards
Emanuel

On Saturday 20 September 2008, Emanuel Rumpf wrote:

> I'm not pointing on anyone. If I sounded offending, I'm sorry for that.

I'm sorry I couldn't avoid getting angry.  I know this is all a communications 
problem, but it is very frustrating to deal with.

Our communications are terrible, and our communications with you in particular 
seem to be the worst of all, because you came late to the game, and we have 
done a poor job of putting all our previous discussion together so it is easy 
for new people to read through.

> > I didn't realize someone was switching things back on purpose.
>
> Yes, with purpose, but what means "back" here?
> The conversions are a step forward to qt4 support,
> that's how I see it.

Someone started using QTableWidget, and when I saw QTableWidget errors, I 
switched some things to use Q3Table and related classes, as we discussed in 
early August, to make the errors go away and get code building.  I thought 
this was from the mechanized port going wrong until I noticed that some of 
the QTableWidget used to be KListBox, and that's when I posted the start of 
this thread.

We've been working in conflicting directions for some time, apparently, and 
it's because I did a poor job of communicating all the past discussion, and 
you did a poor job of communicating what you were doing and why.

> I can't find any good reason to keep the Q3 classes, but
> I'd like to here a third person here.

If you can make changes to Qt4 classes you are VERY sure will work without 
introducing strange new problems, then go ahead.  I didn't see a way to do 
that with QTableWidget, but you are a better (or at least far more patient 
and dedicated) programmer than I am.

What sets Q3Table and Q3Canvas and some others apart from the other Q3 classes 
is that they are whole, self-contained Qt3 classes whose methods work only on 
other Q3 relatives, rather than convenience classes that merely call the new 
API of classes similar to their Qt3 ancestors.  This code has to be rewritten 
from top to bottom using new classes and new methods, new ways of solving old 
problems with brand new tools, and this can involve a lot of blind guesswork 
that might lead to mysterious problems.

We already have to do a lot of blind guesswork that absolutely can't be 
avoided, but we wanted to keep the guesswork to a minimum at first, and get 
something to run so that we would have a working framework in which to 
experiment with the more difficult rewriting efforts.  That's why we're using 
Q3Canvas (the absolute worst case) and that's why we decided to use Q3Table 
and a small handful of other Q3 classes.

Now you know why.  What do you think about QTableWidget now that you've been 
looking at it?  Are you REALLY sure you can do this rewrite without 
introducing mysterious problems? 

If so, go ahead.  You're right that pure Qt4 is the final goal, and using Q3 
classes only moves work to the future.  I'm not opposed to this rewrite if it 
can be done with a high degree of certainty.

It *did* irritate me that you yelled at me over this when my reasoning was 
quite sound and conservative.  It's better to put off some jobs for a time 
when we can actually see this thing work than to introduce a lot of strange 
new problems to have to debug.  It is a gray area and it is hard to make 
decisions on anything but a case by case basis.  Q3Table is where we came 
down on that particular case, but that decision is not chiseled in stone.
-- 
D. Michael McIntyre

On Saturday 20 September 2008, you wrote:

> using Q3Canvas (the absolute worst case) and that's why we decided to use
> Q3Table and a small handful of other Q3 classes.

Q3PtrDict was another one.  I looked at rewriting this to use whatever the 
suggested alternative was (I think I tried QHash) and I really didn't have 
any luck at all.

There's another one for you to tackle IF you can get it to work without 
introducing weird errors.  Otherwise, another one to leave alone until we get 
this thing running, and then tackle after.
-- 
D. Michael McIntyre

2008/9/21 D. Michael McIntyre <rosegarden.trumpeter@...>:
>

> This code has to be rewritten
> from top to bottom using new classes and new methods, new ways of solving old
> problems with brand new tools, and this can involve a lot of blind guesswork
> that might lead to mysterious problems.
>
I fear, that using Q3 Classes might lead to mysterious problems too.
I do not really trust the mixed api approach and the Q3 classes.

Somehow I think, that it would be better to end with something
partly broken but consistent, where we at least know
we can fix it with qt4, than end with something broken,
that is anything between qt3 and qt4, we don't really know....


> Now you know why.  What do you think about QTableWidget now that you've been
> looking at it?  Are you REALLY sure you can do this rewrite without
> introducing mysterious problems?
>
To me the introduced problems do not look more mysterious, than
the one we already have.
Some names changed, a few functions dissapeared (and may thus be of
minor importance),
some things are treated a little different.
That's about it.
If I know, I'm using qt4, I can look at the documentation, find out
how things work
and do the job. With q3 in between, I'm not so sure...
I won't promise to work out every detail in the current phase,
but I'm sure to get most of the pile compile.
In general, I mark/document well the places where I'm uncertain in the
source code.
A list-box is a list-box at the end, isn't it...

> If so, go ahead.  You're right that pure Qt4 is the final goal, and using Q3
> classes only moves work to the future.  I'm not opposed to this rewrite if it
> can be done with a high degree of certainty.
>
I hope it is ok for you, if I continue work on QTableWidget.
It's partly done, so reverting would likely cause more trouble.

Please mention the Q3 Classes, you would prefere to better not touch
or you are uncertain about.

I will look at Q3PtrDict, when I stumble over it.
Yes, it looks like QHash is the appropriate replacement.

Thank you for pointing out your point of view

On Sunday 21 September 2008, Emanuel Rumpf wrote:

> I fear, that using Q3 Classes might lead to mysterious problems too.
> I do not really trust the mixed api approach and the Q3 classes.

I think it will be OK for the classes we've selected, because they're 
self-contained.  These don't involve using the old API with new classes, but 
using the old API with old classes that have been renamed.

> Somehow I think, that it would be better to end with something
> partly broken but consistent, where we at least know
> we can fix it with qt4, than end with something broken,
> that is anything between qt3 and qt4, we don't really know....

That rather depends on whether the Qt3 classes like Q3Table work as 
advertised.  The theory is that we're less likely to have anything broken, 
because we're still using the old classes to do the same jobs they always 
did, rather than writing an entirely new implementation at this point.

All of these arguments are minor except for Q3Canvas though, and if you 
thoroughly understand what the old Qt3 code did, and thoroughly understand 
how to do exactly the same job in Qt4, then I have no problem doing that 
rewriting sooner rather than later.

We're just trying to avoid having the thing explode the first time it runs.  
It might already, because there are so many cases where we have *no choice* 
but to rewrite things.  Less rewriting is better until after we actually get 
the thing up and running.  We haven't even seen it take its first couple of 
halting chugs yet.  It's anyone's guess whether it will fire up and run, or 
just explode in a cloud of blue smoke as soon as we turn the key.

> I hope it is ok for you, if I continue work on QTableWidget.
> It's partly done, so reverting would likely cause more trouble.

You might as well change all the Q3Table I did while you're at it.  In for a 
penny, in for a pound.

> Please mention the Q3 Classes, you would prefere to better not touch
> or you are uncertain about.

The only one I'm absolutely certain we're keeping for now is Q3Canvas.

> I will look at Q3PtrDict, when I stumble over it.
> Yes, it looks like QHash is the appropriate replacement.

It's supposed to be, but I couldn't figure out how to get it to work, and 
decided to leave well enough alone for now.

Anyway, I'm out of easy projects, and officially retiring from the port for 
the foreseeable future.  I'll be back when there are docs to write. That's 
the job I do best.  The last 28% of this thing is for real programmers, or 
aspiring real programmers.  I'm out of my depth, and have nothing left to 
offer.
-- 
D. Michael McIntyre

On Sat, Sep 20, 2008 at 9:29 PM, Emanuel Rumpf <xbran@...> wrote:
> Maybe Chris could state his opinion.

Well, like the demons of compromise, I think you're both right -- just
about different things.

We had agreed (more or less as a default work-saving position) to
stick with Qt3 compatibility classes for some things, obviously most
notably the QCanvas but also including the classes that had been
rewritten to use explicit model/view versions in Qt4, such as list and
table views.

That was before you came along, Emanuel, and of course there's no very
good reason why you would have known that unless you'd been
particularly keen to read closely through the mailing list history.

But it's entirely reasonable that Michael should see a change from
e.g. KListView to QTableWidget as most likely being a mistake, and
he's right to ask for a good explanation.

I would agree that it is better to switch straight to the Qt4 classes,
if you actually has the energy and are prepared to put in the work.
If you get it to work, that's fantastic and you will have everyone's
thanks.  The message is simply: discuss it first!  Or at the very
least, mention what you're doing and why.

Speaking of which -- why switch KListView to QTableWidget, and not to
QListWidget?


Chris

I did casually mention the changes in the bug log and in the wiki, but
not explicitly. I should have been more verbose there.
I didn't knew QListView had been denoted as a special case class.
Sorry for causing confusion.

Regarding the changes:
I've been wrong here at the begining:
I converted QListView to QListWidget, but then found it to be wrong in
most places.

The new qt4 classes work like this:

++  QListView : base class, that uses qt4 model-view style (I think we
don't need to use it now. It makes sence, where one has different
views of the same data.)

++ QListWidget : A simple list, that does not require model-view style.

++ QTableWidget : A table/spreadsheet widget, that does not require
model-view style.

++ QTreeWidget : A table widget with possible sub-items, or tree-like
structure, that does not require model-view style.


Almost all QListView or QListWidget classes will thus become either
QTableWidget (more flexible) or QTreeWidget (sub-items).
Qt people did a humble interface here:
Although the classes behavior (QTableWidget / QTreeWidget) is quite
similar, the api is quite different.

I hope this brought a little clarity.

Emanuel