Trolltech has released the second and final beta version of Qt 4. You can download it from ftp.trolltech.com or from one of its mirrors. The online Qt Reference Documentation has been updated. Qt 4 is currently scheduled for final release in late Q2, 2005, with an intermediate Release Candidate planned for May.
In addition to improvements to the five key technologies presented in
beta 1 - Arthur, Scribe, Interview, Tulip and Mainwindow - the second
beta version incorporates nearly all new features, tools and resources
that will appear in the Qt 4 final release. Features now available
in Qt 4 beta 2 include:
- Improvements to the Qt 3 to 4 porting tool and supporting documentation
- Feature additions to Qt Designer, including support for MDI and
SDI modes, and support for custom widgets - A new painting subsystem which allows device-independent rendering of pixel-exact images
- An improved input method framework
- Addition of XP (available under Windows only) and Motif styles
Additional improvements have also been made to the Qt3Support
Library. Trolltech aims to maintain the Qt3Support Library for the
lifetime of the Qt 4 series, and will also support the Qt 3 series for
a minimum of two years beyond the release of Qt 4.
Comments
Now I know that QT4 has been making news occasionally for the past few months, but I am still curious as to what exactly is and will be new and improved with it. I have only found a few websites that discuss some base technologies but do not go into any depth as to what this will mean for the end user.
Are there performance improvements, rendering improvements, accessibility improvements or anything else of the sort that one should expect? Are there any before and after screenshots that might illustrate such a thing?
Here ya go.
http://doc.trolltech.com/4.0/qt4-intro.html
Quoting the link:
----8<------
The Tulip containers support the foreach keyword, a Qt-specific addition to the C++ language that is implemented using the standard C++ preprocessor. The syntax is:
foreach (variable, container)
statement;
---->8------
Whoa, I know they extended the language before with 'emit' and stuff, but this change now, even if minor in practice, has quite an impact in the "feel" of the language. Trolltech seems to be really determined to put an end to the remaining suckiness in C++. Expect garbage collection in Qt 5.
How did you get that "scissors-effect" in your post??? That's neat!
Hmmm... seems to me that doing:
template
void foo(Iterator iter) { statement }
std::for_each(container.begin(), container.end(), foo);
really isn't that much harder, let alone the stuff you can do with boost::lambda.
Is it really worth it to screw with C++ for these fairly minor cosmetic changes?
> Is it really worth it to screw with C++ for these fairly minor cosmetic changes?
It is. Try it and you will love it. The foreach is highly addictive.
>Are there performance improvements, rendering improvements, accessibility >improvements or anything else of the sort that one should expect?
Yes to all of them. Example: Text-To-Speech (KTS) is now also working for a menustructure (was not possible in Qt3). For a developer a lot things changed for the enduser not to much. But of course: If you can code better apps with Qt4 compared with Qt3 this will be an "effect" for the enduser.
Qt is a lib which is used by developers. It's up the the developers to make use of it.
> Are there performance improvements, rendering improvements, accessibility improvements or anything else of the sort that one should expect?
Yes, yes, yes, all of that and more. :-)
Please note it's correctly spelled Qt ("cute"), not QT ("QuickTime").
I've always spelled it Qt ("cutie")
Paul.
Don't be so picky. Get a life.
As the final release date for Qt 4 approaches, how is the KDE organization preparing to set up its developers for success?
Any groups (APPEAL-like) that will promote the relase and educate above the Qt documentation?
A clear message at aKademy (if not already planned) on coding/porting/migrating would be good.
Where can people, like myself, go to help?
Is there a need to add something above the Qt documentation? I think it's very good.
Frankly, I can do without being "set up" for success by any organization. It sounds like a painful experience, if not something that belongs to the corporate world.
The most helpful thing would be to offer to help one project (and I don't object to it being Krita) remove all Qt 3'isms from the code. The change away from QValuePtr (if I remember that correctly) alone is going to take a few days...
For the people who do want to help out with this, the following url might be very helpful too:
http://www.trolltech.com/products/qt/readyforqt4.html
"Frankly, I can do without being "set up" for success by any organization."
So, is your implication that if you don't need it, no one else does? That might be the case if you're the worst programmer.
How self-deprecating of you.
But if that's not your message, then accept that some may find Qt's documentation insufficient as it applies to KDE, some may have trouble developing a task list of changes, and some may have trouble recruiting help over the next 12 months if they can't direct new resources to said information.
This change is more about collaboration than about find/replace and method signatures. If it were otherwise, then this announcement wouldn't have even had the pertinence to be posted on the dot.
I think he just disliked your manager talk. Who on earth speaks like that in real life, other than a manager? 'set up for success'. Heh.
Exactly.
i agree. let's chase away all the managers. we don't want them. ;-P
I certainly don't want managers nor do I want to be managed. This is strictly an amateur performance for me, done for fun.
I'm not a college kid anymore. I don't have any need to play enterprise in my free time to feel grown-up. If I have to submit in my leisure time to the same inane wordwooze here as I have to in my job, I'll jolly well quit.
lol ... managers aren't contagious ... they can come near and you won't catch some horrid disease.
there's a fine line between not having "anti-open-source" structured project management and being hostile to anyone who comes from a management background who comes around to look at the project.
actually, no, there isn't a fine line. there's a big huge line that ought to be fairly obvious.
when someone asks a question and does so using managerese they may just be communicating in the way that is most comfortable to them. their goal may simply be to get some information, not manage you.
have you ever played with one of those "siamese fighting fish" that flare up whenever they see anything that might be coming into their territory? they are rather cute.
So, basically you say I'm a siamese fighting fish who is missing the obvious for poking fun at someone who's using language that would be right at home in a Dilbert cartoon?
Frankly, I'll do all I can to keep that nefarious contagious disease away from my leisure time. You never know... Before you realize it you start tagging "going forward" onto the natural ending of your sentences yourself, and then it's too late. Your hair will part in the middle, your beard will wither in your chin and your tie won't uninstall anymore. But don't tell me I didn't warn you.
"So, basically you say I'm a siamese fighting fish who is missing the obvious for poking fun at someone who's using language that would be right at home in a Dilbert cartoon?"
Either that, or he's trying to pick you up. >;-)
Reminds me of a story.
A co-worker has a relative who has worked for years for a firm. Competent, designed many of the systems that keep the place running.
He got to work one morning, found his desk against the wall and two or three chairs in his office. Some eager manager type walked in, explained that this was done to encourage team work, collaboration and open exchange of ideas. People are encouraged to walk in and discuss things. He moved his desk to where it was, put the chairs in the hallway, escorted the eager manager type out by his arm and said (I'm paraphrasing) 'Get out. I've got work to do'.
My kind of man.
Derek
While I'm the first person to laugh at managers, it's a shame that the programmer didn't give it a try. Of course it depends on the situation etc etc, but it doesn't sound to me to be that bad an idea.
What a fool. (The 'Get out. I've got work to do'-guy).
/agreed
Well, there's already some stuff going on: http://www.kdedevelopers.org/node/view/936 for example.
Rich.
...what is the plan now?
Reading the cvs mailing list seems that things are quite stagnant right now. No big changes are done, which is very strange after the long freeze for 3.4.
What is the consensus on the next kde release? Will it be a 3.5 Application Release? When will do core developers start using Qt 4?
Seeing that things are moving over to subversion, I wouldn't imagine too much traffic would be seen on the cvs mailing list for long anyway.
> Will it be a 3.5 Application Release?
Likely
> When will do core developers start using Qt 4?
Once there is a branch for it, be assured. :-)
At least there is a 3.5 feature plan.
>«At least there is a 3.5 feature plan.»
Where ? (nothing here for the moment: http://developer.kde.org/development-versions/)
Here: http://developer.kde.org/development-versions/kde-3.5-features.html
So, how does one contribute to this list?
The need to fix (sort out) the Crystal and HiColor icon themes has been more or less agreed to on the kde-artists@mail list, I have started working on it but don't seem to be able to get any further with it.
The mixed up icon themes are something of a mess and it is going to take considerable work to sort it back out.
--
JRT
Assuming that you have a CVS account, change developer.kde.org/development-versions/kde-features.xml
There is also a 4.0 feature plan - both contain mostly randomly spread delayed entries from 3.4 feature plan currently.
So opposed to beta1, beta2 is actually supposed to be faster than Qt3? I'd like to see some numbers that prove this.
And I want to see your numbers that beta1 was not faster than Qt3 too. :-)
I searched through the documentation of Arthur, but I cannot seem to find anything similar to what GTK is doing with Cairo. I've seen some screenshots of Cairo-rendered GTK-Widgets. They look -very- cool and the technique is very modern. Vector-based graphics are the future, but the only real noticable painting-improvement in Arthur is Anti-Aliasing (I know all backends, but what if I didn't, what is new that I can --see--). Imho Vector-graphics and a theming-engine which makes use of that is something I would really like to see in KDE 4. Vector-graphics are the future. But is it possible at all with Qt 4?
Am I missing something? Where are the noticable eye-candy-features, which make the average university-student go like: "Wow" as it works for Cairo and Avalon.
But, maybe I am missing something. Then I think trolltech should have created more and better examples of the eye-candy-possibilities. (Yes, I think the looks are very important if it comes to X-Clients.) :)
So, no direct flame or anything like that :), just (hopefully) a request for someone to clarify this a bit. :)
I though TT will have more than one painting backend, one of them being cairo...
Beside that I am very sure TT will provide more and more screenshots / updated documentation / tech-demos and so one once they are in release-mode. As of now they are still working on the code itself. There are some month ahead of them!
Qt4 will allow developers a lot nice things including eyecandy, be sure of that!
"I though TT will have more than one painting backend, one of them being cairo..."
It doesn't even matter whether they do... If you look at the docs, it seems that writing one shouldn't be hard.
Well, writing one for Qt3 is not terribly hard either. It's just weirdly underdocumented.
I wrote a Qt2 PDF backend but could never release it due to licensing issues (no good free PDF generating lib).
You are missing a lot of stuff. Such as, for example, sub-pixel positioning.
And vector-based graphics died in favor of raster displays ages ago.
I'm pretty excited to get sub-pixel positioning for KStars. But I don't see anything about it in the description of Arthur here:
http://doc.trolltech.com/4.0/qt4-arthur.html
Can you provide a link?
thanks,
Jason
Reply-to-self mode ON:
Well, if you had *bothered* to read the actual class documentation for QPainter:
http://doc.trolltech.com/4.0/qpainter.html
...it would have been immediately *obvious* that yes, QPainter draw methods will accept floating-point pixel positions!
Hooray!
Jason,
this means that you can position your stars at the correct position and Qt (aka Arthur) will take care of the best "real" position so that rounding-error are reduced to a minimum and you do no longer have to put a million lines like this in KStars:
p.drawStar( (int)x , (int)y);
Correct?
Hmm. Maybe it does just mean that Qt will automatically round to the nearest pixel, saving me the trouble of recasting as int. If so, this is less exciting. I was hoping it would actually allow for sub-pixel moves, which is possible with antialiasing (i.e., openGL allows this). This would eliminate the slight "jitter" as objects move across the sky, bouncing from pixel to pixel.
Well, since you can paint directly on an opengl surface with qt4's qpainter, you will automatically get opengl support just by porting to qt4. After grepping the code for glEnable( GL_POINT_SMOOTH ), i didn't find it, but since there is no glDisable( GL_POINT_SMOOTH ), i think you could just make that call yourself, paint, and then you'll get anti-aliased points.
Also i think a call to glHint( GL_POINT_SMOOTH, GL_NICEST ) and glEnable(GL_SMOOTH) is needed. Also blending needs to be enabled i believe.
This is mostly off the top of my head, so some of it could be inaccurate.
Matt
The AA code in Qt's OpenGL painter uses multisampling, not line and point antialiasing