On Thursday 31 July 2008, Chris Cannam wrote:
> Qt3's QCanvas in the matrix and notation views (the other possibility
> is a dedicated widget of our own devising, which I think would almost
> certainly be a better idea for the matrix at least).
Long-term, I think a dedicated widget of our own à la Guillaume's segment
canvas rewrite would be the best idea, but I can't help but remember what an
ordeal that segment canvas rewrite was. It took a long time to get the kinks
worked out of it, and it ate up almost all of our resources for that release
cycle to provide an improvement that was almost transparent to users.
Was it really worth it? The main obvious userland benefit of that work was
the elimination of the brick wall at the end of the rollercoaster. For those
who don't remember, it used to be that you had to anticipate how long your
recording was going to be before you began it. You could get into a groove
doing improv to a repeated accompaniment, and be right in the middle of
expressing some brilliant musical thought when WHAM! Please deposit more
quarters. The ride is over. I used to HATE that, and I was glad to see it
gone, and if spending what felt like six months going through all of that was
the only way to arrive at that conclusion, then it was worth it. However, if
we could have gotten to that particular end some other way, I don't think any
of the other supposed benefits of the new canvas justify all that work. I
still have no idea what the other benefits even are, even though I am, sadly,
the #2 programmer on staff now.
I think all of this speaks to choosing simplicity if possible. Users won't
appreciate subtle improvements that require months to bring about, so if we
can get there some other way first and save the wholesale rewrites for 2.1 or
something, then that's most likely the way to go. That assumes there's an
option on the table that doesn't already involve substantial rewrites. If we
have to redo more than let's say 1/3 of the QCanvas-related code to make
anything work at all, then perhaps it would be best to take the hit up front
I don't have any really strong opinions either way on this one, and am just
musing out loud. This is ultimately Chris's call to make. Not mine.
> - if we were writing the code from scratch, I would see no reason to
> prefer KConfig over QSettings (which works perfectly well for me in
> other apps), and so I think we should aim to go to QSettings if it's
> not vastly more difficult
I've looked at this a few times, and it does seem we have to do substantial
work either way (ie. neither option is scriptable,) so I'm all for switching
to QSettings. That would have the added benefit of eliminating any
possibility of carrying old settings forward from previous versions.
Since she said something favorable about it twice, I hearby nominate, second,
and confirm Julie for the position of KConfig to QSettings Conversion
Supervision Specialist III.
The KConfig to QSettings Conversion Supervision Specialist III will wait until
the mechanized bit of the conversion has gone as far as it can (we're
approaching that wall soon now, I think) and then endeavor to rewrite all
uses of KConfig to employ QSettings instead. The compensation for this
position is to be remembered and appreciated forever by the twelve people
worldwide who really love Rosegarden.
Oh, and a T-shirt. I'm seriously thinking of having some T-shirts printed up
that say something to the effect of "I Survived the Rosegarden QT4 Port."
Sure to be a conversation starter!
> - bundling the icons via qrc I think is a very good idea -- we could
> even aim to have only a single executable to deploy with all the
> icons, default files etc in it, instead of installing hundreds of
> separate files. There's probably something to be said for providing
> our own IconLoader class which we load everything through, then we can
> control the policy in one place (see e.g. the Sonic Visualiser
The quickest way to get this done is probably to put it on your plate, since
you're already familiar with the mechanism, and the code we would borrow.
However, if you're too wrapped up in the huge and mind bending jobs, such as
the elimination of DCOP in particular, then I could probably field this one
with some direction, ie. hand-holding.
> - KDE3 had a lot of useful base classes for things like dialogs which
> are now easier to do directly in Qt4 than they were in Qt3, and many
> of the KDE enhancements for things like combo box accessibility are
> now part of Qt4, so there are fewer reasons to prefer KDE alternatives
> for classes that exist in both
I agree with a QT bias, but if it's easier to keep something like
KDockableMainWindow, then by all means let's just do that. I don't think we
can eliminate the dependency on KDE entirely, and I personally don't care if
we do. I definitely prefer using i18n over tr() for example.
But then that begs further questions about what's going to happen when we have
some of our bits in .qrc files and some other bits using the normal KDE
mechanisms. Is it all or nothing? Wouldn't we want to bundle our
translations in the .qrc file too? And if so, how do we reconcile that with
If we want to bundle our sample files in .qrc files, then how do we reconcile
that with our stated desire to continue to use KDE file dialogs (which I
strongly prefer, and you have seemed to at least somewhat agree with) which I
don't imagine will have any idea how to extract things from .qrc files and
present them as though they were files in /usr/share/wherever/examples/.
> - KDE4's default widget theme is ugly (in current releases, in my opinion)
Hideous and horrible IMHO. I especially hate how they've eliminated the
distinction between active windows and passive windows. (OK, that's a color
scheme thing, but the last time I played with this, I could never manage to
diddle the color scheme to get it to behave like I wanted.)
As far as questions of widgetry and look and feel...
First, as much as I hate to even raise this spectre, the fact remains that our
notation editor icons look like shit. I know we've had this fight before,
and I know I gave up in frustration after you busted my balls over one
percentage of opacity on one pixel in one icon out of the hundreds we have to
redo, but it seems a shame to go to all this trouble only to come back to the
table with our tired, shitty looking icons that started life as XPM files in
a different age of computing.
This whole thing is actually a good thing to offer the people who don't want
to program, but want to help. It's a horrible, horrible, HORRIBLE job
fighting with Chris over every single pixel, which must be absolutely perfect
according to his idealized vision, but it really should be done. If we go to
this much trouble to bake a new cake and then put the same old icing on it,
it will be an underwhelming experience for the users for sure.
Now having said that, and having come back to the question of how bad the
default KDE theme looks, etc., I think it's time once more to think about
Hydrogen-izing our UI. It's one way to deal with the issue of how we look in
environments we can't control, and if we could pull it off as well as
Hydrogen does, it would look très chic too. I don't meant to copy Hydrogen's
look, but to copy their practice of controlling every aspect of their own
look, and leaving nothing to chance. (Although Hydrogen's look does blend in
really well with Ubuntu Studio's factory theme, and a lot of our users run
Ubuntu Studio now. Although, too, I still officially don't give a rat's ass
about doing anything to benefit those ingrates either, so I'm pretty
ambivalent on that whole score.)
Well, let's get developer reaction to these thoughts (please) and then we'll
see about trying to hire some people to do the icing work. Vlada might still
be good for some icon work, and maybe some of these other people who
said "can't you find something for me to do that isn't programming?" will
answer this call. I realize it's premature to worry about the icing this
early in the game, but in the end, the icing is going to matter more to
anyone than the millions of hours of dirty shoveling. I'd really like to see
Rosegarden 2.0 have a dramatically fresh look, and do it without breaking the
(The only thing there, I'm still really in love with our current splash screen
and black-white-dark orange color scheme on the website. I think we should
change that up for the sake of freshness, but it's hard to top. I'm inclined
to leave it well enough alone.)
(And speaking of which, all of this is going to take at least a year to get
out of beta, so we really should put 1.7.1 together and ship it out. In
fact, I'll see about going to do that right now, and while I'm thinking about
it, I'll go start a new timetable thread.)
D. Michael McIntyre