Qt 4.1 Now Available

Tuesday, 20 December 2005  |  Jriddell

Trolltech has released Qt 4.1. The first feature release since Qt 4.0 includes new features which will make it into KDE 4 such as integrated support for rendering scalable vector graphics (SVG) drawings and animations, a PDF backend to the Qt printing system and a lightweight unit testing framework. Qt Designer has been updated, OpenGL support has been improved and SOCKS5 support has been added. Their 4.1.0 changes file has the full details. Get your copy from the X11 download page or from qt-copy in KDE's SVN.

Comments:

Hope KDE 4 will require Qt 4.1 - Shyru - 2005-12-20

Given the SVG and PDF capabilities of Qt 4.1 and all other improvements I hope that KDE 4 will require Qt 4.1 as minimum version. Will that happen?

Re: Hope KDE 4 will require Qt 4.1 - superstoned - 2005-12-20

most likely, yes. :D

Re: Hope KDE 4 will require Qt 4.1 - Benjamin Meyer - 2005-12-21

Yes, KDE4 will require 4.1, parts of trunk already do :) -Benjamin Meyer

Re: Hope KDE 4 will require Qt 4.1 - AC - 2005-12-22

I hope so because 4.0 is buggy as hell! I hope they plan for 4.1.1 because even 4.1 isn't ready.

Re: Hope KDE 4 will require Qt 4.1 - ac - 2005-12-22

the difference between a troll and a user is that the user actually gives details when he says that something is buggy, crappy or whatever. try again.

KSVG - Thomas - 2005-12-20

http://svg.kde.org/ Did ksvg had any influence on the svg implementation of Qt? Do we now have two different svg renderers? Ksvg supports javascript, afaik. Which one will be used? SVG wallpapers and svg icons are rendered with ksvg atm.

Re: KSVG - Michael - 2005-12-20

They suplement each other. qsvg only implements the tiny svg specification. So there is no duplication of efforts. ksvg tries to implement full svg support.

Re: KSVG - Carsten Niehaus - 2005-12-20

Furthermore, KSvg supports DOM which the Qt-svn does not (not needed for tinysvg-usecases)

Re: KSVG - ch - 2005-12-20

ksvg provides manipulation of svg @ runtime with DOM , qt svg does not

Re: KSVG - Patcito - 2005-12-20

So if I get it right, KDE4 will use QtSVG for things like icons rendering and it will use KSVG for rendering svg embeded in webpages and more complex tasks like that. By the way is KSVG2 able to render that kind of stuff http://www.croczilla.com/svg/samples/svgtetris ?

Re: KSVG - eol - 2005-12-21

http://www.croczilla.com/svg/samples/svgtetris click on svg , konqui goes boom. and no, i did not report it to bugs.kde

Re: KSVG - Patcito - 2005-12-22

that's because you're not using the yet to be released KSVG2. I was asking to people in the know.

Re: KSVG - AngryMike - 2005-12-21

If QT does not support the DOM interface then they can't be considered 1.2 compliant. (Since 1.2, is in last call it seems no one can be 1.2 compliant right now, but I degress... :) ) SVGT does have a microdom that can be used for dynamic updates and scripting. Any word on when this will be done? So there will be overlap if QT wants to be 1.2 compliant.

Xara Xtreme (http://www.xaraxtreme.org) - Vlad C. - 2005-12-20

I've got a feeling that once Xara Xtreme (http://www.xaraxtreme.org/) is released under the GPL, it will be way faster (http://www.xaraxtreme.org/about/#performance) than any existing free software SVG implementation such as Inkscape, QT SVG, KSVG, Cairo, etc. I would suggest QT or KDE devs working on SVG to try to incorporate as much of Xara Xtreme's code as possible, because they're likely to be the best in the field. Here's the original announcement giving the reasons why they are releasing their product as open source: http://www.xaraxtreme.org/news/11-10-05.html

Re: Xara Xtreme (http://www.xaraxtreme.org) - James Richard Tyrer - 2005-12-20

> it will be way faster Is that really what is most important? IMHO, it is more important that SVGs be rendered correctly. With that as the goal, then Batik (Apache) would be the best choice. Yes, I know it is Java, but isn't GCJ 4.1 supposed to be able to compile Java classes to be used with C++? IAC, what we could really use is Gaussian Blur filters -- icons look stupid without drop shadows.

Great! - Iuri Fiedoruk - 2005-12-20

I've started using qt4 this year, and I belive it's the best open-source toolkit out there, I can't even imagine why some people still use things as wxwindows and gtk.. well maybe because they don't wnat to create GPL apps, shame on them.

Re: Great! - Ben - 2005-12-20

because wxWidgets (as it's called now) is truly cross-platform, making use of true native widgets, as opposed to just painting fake ones that look like the real ones. If your app is supposed to run on other platforms than linux, then you'll see a big difference in performance.

Re: Great! - muesli - 2005-12-20

we're talking about qt4, so that's bollocks. cheers, muesli

Re: Great! - 2rpi - 2005-12-20

I am a big QT fan, but I think you hit on something here,as far as QT4 needing native widget support. Correct me if I am wrong but doesn't QT4 now do all of its own rendering. If so isn't this at least responsible for part of the slowness of it. Java did this with Swing which made it very slow and even more unusable. IS there a choise in rendering engines for QT4 - native widgets or QT4 ? And if QT offers its own rendering engine why not use openGL and take advantage of the GPU found in almost every mother board. This would allow for really beautiful shading and lighting with virtually no rendering penalities.

Re: Great! - Patcito - 2005-12-20

It's Qt not QT! QT is a dirty codec used by a company that likes to calls it self an apple. Instead please use http://www.theora.org :)

Re: Great! - mikeyd - 2005-12-20

<I>Java did this with Swing which made it very slow and even more unusable.</I><P>It made Java slow and unusable because Java is interpreted. (Yeah, I know, JIT, fast as native performance, you have benchmarks, yada yada. Bollocks.) C++ is natively compiled, so there's no reason at all for the speed of Qt rendering to be any different from native - provided your C++ compiler is up to scratch, that is.

Re: Great! - Marc Collin - 2005-12-20

if you created java program who's slow is your fault, bad programmer bad programmer often do long action in an event... that block the gui, the solution is thread and the gui will be responsive any good programmer know that

Re: Great! - ac - 2005-12-20

if your program slow is now, in future faster will it be. computer faster get all the time, any bad programmer will know.

Re: Great! - Leo - 2005-12-20

that could almost be a poem ;)

Re: Great! - Bardok - 2005-12-21

I think it's not a poem... it's Master Yoda ;-)

Re: Great! - mikeyd - 2005-12-20

Every java program I have used has been horribly slow. Every one. The gui isn't blocked, it's still there if you obscure and reveal it, it's just taking ages to respond to anything because it's flipping slow.

Re: Great! - rqosa - 2005-12-21

In my experience, even "hello world" in Java takes a few seconds to start up, even when compiled to native code with GCJ.

Re: Great! - Michael Pyne - 2005-12-20

> Correct me if I am wrong but doesn't QT4 now do all of its own rendering? Qt has always done its own rendering. > If so isn't this at least responsible for part of the slowness of it? Huh? Qt is hardly slow at drawing. Perhaps you're using a poorly programmed theme? > Is there a choise in rendering engines for QT4 - native widgets or QT4 As muesli just pointed out, Qt uses native rendering on every platform. On Linux, Qt itself is "native" :)

Re: Great! - Bryan Feeney - 2005-12-21

Actually, from what I've heard, the native-looking Qt themes defer to the native implementation where possible, and only render widgets themselves when necessary due to their configuration. This was necessary to get a decent look and feel for Mac OS X (added in 3.2) and in Windows XP. Qt is certainly not slow, and in fact, neither is Swing (it's faster than SWT on a lot of benchmarks). The problem with Java apps is the high memory usage and slow start-up time caused by the JVM loading. Assuming it's coded correctly (a big assumption) Java applications are very responsive. Try the ThinkFree Office demo, of the DbVisualizer demo, for examples of how good Java can be. Qt also supports rendering using OpenGL as of version 4: this is the "Arthur" rendering engine. If offers all you want, people just need to write a theme to take advantage of it.

Re: Great! - Leo - 2005-12-21

Just tried ThinkFree office. It's very snappy indeed. So the question is, is every other Java developer retarded? If it is possible to make snappy user interfaces, what's up with every other high-profile java app on the planet? Eclipse, Azureus, both laggy on my system. So are they programmed by idiots or what's the difference here?

Re: Great! - Bryan Feeney - 2005-12-21

Eclipse is laggy because it has so much to do. I use Delphi 2005 at work, and if I didn't have 1GB of memory it would crumble. As for Azeurus, I've never actually tried it, so I don't know, but I've tried RSSOwl (a Java/SWT app) and it was perfectly responsive. As for the skills of Java developers, Sun never explained in its documentation the necessity of multi-threading when developing Java GUIs. The SwingWorker class (which made it easier to multi-thread the response to GUI events) was never bundled with the JDK, even though it's been around since 1.1. So the answer is, Sun just never advertised the fact that it was necessary. It has started to do that now, though; there's a lot of momentum building behind Java on the Desktop again, and there are lots of little things like Foxtrot, SwixML and SwingML to make desktop development easier (not to mention the excellent GUI designer in Netbeans 5, the beta of which is available now). The fact is Java still requires huge amounts of RAM: if you can manage that, Java will run beautifully. Sun realises this, however, and Java 6 should improve startup time and memory-use significantly.

Re: Great! - anonymous - 2005-12-21

I feel that Qt4 is not faster as Qt3. If you turn on the fancy stuff, Qt4 is A LOT SLOWER than any other toolkit. brought to you as an user feeling, not as a programmer with benchmarks...

Re: Great! - ac - 2005-12-21

>>brought to you as an user feeling Since when do you users compile (and have feelings *evil grin*)? Are you saying the developers are lying? Because if some developers say it is faster and you say it is not, their lying promotion would be my simple conclusion. You honestly believe they are lying to you?

Re: Great! - anonymous - 2005-12-21

> Since when do you users compile compiled it for myself (not that hard) and tried the demos. I think the developer lying if they say it's faster. It's maybe faster to compile Qt4 apps. But that's useless for the "Suse" customers... A faster GUI response from Qt4 based apps is A LOT more important than compile times. Don't ever hope that KDE4 runs faster on my 500Mhz Laptop than KDE 3.4.x/3.5.x

Re: Great! - Aaron J. Seigo - 2005-12-22

what aspects of "GUI response" are you talking about exactly? are you talking about painting N widgets of various types? or model/view based interfaces? or alpha blending and transparency (and if so, client side or hardware accelerated)? or ...?

Re: Great! - Flavio - 2005-12-20

Qt on Windows and Mac acts as a wrapper around the native APIs. Shame on you!

Re: Great! - MORB - 2005-12-20

Not using the native controls, and rendering/managing your own controls that looks like the original one is not a sin. On windows, even microsoft does this because the native widget toolkit is crap, as this blog entry by Raymond Chen explains: http://blogs.msdn.com/oldnewthing/archive/2005/02/11/371042.aspx

Re: Great! - blacksheep - 2005-12-20

Qt supports Windows and MacOSX native widgets when running on those operating systems. In X11, it draws their own widgets because there is no real native toolkit. Only version 1 would try to fake Windows theme (that theme is still available today), but those days are over. Qt is truly cross-platform and performs very well (KDE is kinda slow to startup and stuff, but that has to do with all the technology behind it). Keep the FUD for yourself please.

Re: Great! - ac - 2005-12-20

> KDE is kinda slow to startup Not anymore :p http://osnews.com/comment.php?news_id=13039

Re: Great! - Leo - 2005-12-20

Not in my experience.. And I use Qt mostly on Windows at the moment and can't see any difference to native apps (slightly longer start up times for trivial programs). Dunno about Mac.

Re: Great! - a - 2005-12-20

How true is that :) I was always annoyed by the different menus(they have some offests) and Qt never used cleartype for font rendering so all the Qt apps on windows look alien.

how about qcanvas? - Patcito - 2005-12-20

I thought it was going to be released with 4.1 :( I suppose it'll come out with 4.2 right guys?, :)

Re: how about qcanvas? - Shyru - 2005-12-20

QCanvas ported to Qt4-Style API will be available as a QtSolution. QCanvas as in Qt3 is in Qt3Support and is somewhat buggy and slow. Something new and equivalent to QCanvas will be available in Qt 4.2

Re: how about qcanvas? - Patcito - 2005-12-20

>>QCanvas ported to Qt4-Style API will be available as a QtSolution will it be open source? >>Something new and equivalent to QCanvas will be available in Qt 4.2 sounds cool :)

Re: how about qcanvas? - Ian Monroe - 2005-12-20

http://doc.trolltech.com/4.1/porting4.html#qcanvas wasn't updated. :P

Re: how about qcanvas? - Anonymous Coward - 2005-12-20

From the release to commercial customers ********************* QtCanvas Now Available ---------------------- The Qt 3 Canvas class has been ported to Qt 4.x, and does not depend on any Qt3Support classes. The renamed QtCanvas is ideally suited for customers who wish to port their QCanvas-based applications from Qt 3 to Qt 4 without relying on Qt3Support. QtCanvas is now available to all Qt Desktop license holders. ********************* I wonder if they'll opensource that one

Re: how about qcanvas? - Ian Monroe - 2005-12-20

It is open source already then. But its confusing: http://doc.trolltech.com/4.1/qtcanvas.html appears to have it named Q3Canvas.

Re: how about qcanvas? - M_abs - 2005-12-22

What Trolltech mean by "commercial" is that it is for paying customors only, eg. not open source.

Native SSH Support - Steve - 2005-12-20

Since FTP and HTTP are supported natively within QT, I'd love to see a native SSH client available. Trolltech if you're listening, please implement it! :D

Re: Native SSH Support - M_abs - 2005-12-22

I would also like an built-in opensource SSL Socket, currently it is only in "Solutions" which is for their commercial customers only.

Re: Native SSH Support - Steve - 2005-12-28

Thanks for the heads up on this page! Now I'm even more interested in buying a commerical license. Stephen

Cairo Support - Russel-Athletic - 2005-12-20

What is up with Cairo support in qt4? Wasn't ther a rumour it will happen in qt 4.1? I would just love to see everything rendered in Cairo/Glitz.

Re: Cairo Support - amadeo - 2005-12-20

What is the advantage? Isn't arthur faster?

Re: Cairo Support - ac - 2005-12-20

> Wasn't ther a rumour it will happen in qt 4.1? AFAIK it was said that you could use Cairo as backend for Arthur. That's all. I don't think that TrollTech will provide such a plugin.

Re: Cairo Support - Anonymous Coward - 2005-12-21

Well, a Cairo backend could certainly be implemented: it's 'just' a matter of subclassing QPaintEngine. Wouldn't it be a step back in terms of speed and functionalities though?

Re: Cairo Support - SiberianHotDog - 2005-12-21

that would make any sense. cairo and the qt paint engine do the same thing, so using cairo as a backend only would make it slow, nothing more. didn't qt4 have a (buggy?) opengl backend for rendering in the betas? was that removed for the final release? than it would be a good idea to write a glitz backend for arthur.

Re: Cairo Support - Segedunum - 2005-12-22

Qt has Arthur, it works today and there is simply no reason to use Cairo. Despite much hype Cairo and Glitz will take some time before they are usable. As needs arise Arthur might use Cairo as a backend at some point, but that really depends on whether there's any point at all.

Re: Cairo Support - ac - 2005-12-22

> As needs arise Arthur might use Cairo as a backend at some point Better arthur should use glitz as backend... no?

Re: Cairo Support - Brandybuck - 2005-12-22

Why? Is there something magical in the name "glitz" that it demands it be used? What is wrong with wrong with Arthur?

comparison - Hotbird - 2005-12-20

i would like to see some performance/features comparison between qt4.1 / cairo-glitz / amanith OpenGL based renderers. Anyone know if XaraExtreme has accelerated or software renderer ?

Re: comparison - Matteo - 2006-01-15

Amanith rendering layer is the best in term of features and speed (and it's 100% crossplatform). The incoming version will be the first library that will support in hw all 24 Porter-Duff compositing modes, 15 of them will be available also on hw that hasn't got pixel shaders.

performance of Qt4.1 - ac - 2005-12-20

In a kde mailinglist I read a comment from a kde dev saying that Qt4.0 is painting *much* slower than Qt3... :-( Has this situation improved with Qt 4.1? Is it on pair, slower or faster than 3.3.5? And what about the backingstore technology...? Does that mean konqueror's tabwidget (and kde apps in general) will not flicker anymore when opening a new tab? Many questions... I know, but I guess it's of a broad interest ;-)

Re: performance of Qt4.1 - anonymous - 2005-12-20

> In a kde mailinglist I read a comment from a kde dev saying that Qt4.0 > is painting *much* slower than Qt3... :-( This is wrong. Most operations are faster in Qt 4, some - like anti-aliased drawing - are even infinitely faster. Just run a Qt 4 program and compare its performance with a counterpart using Qt 3, and judge for yourself. > And what about the backingstore technology...? It's in 4.1. > Does that mean konqueror's tabwidget (and kde apps in general) will not > flicker anymore when opening a new tab? No, this has nothing to do with backingstore. Switching tabs is flicker free since Qt 4.0, thanks to an improved recursive setUpdatesEnabled() that implicitely sets the system background to None (so that your X-Server doesn't fill the newly created widgets prior to Qt being able to draw something). Hopefully 4.2 will abandon native widgets (read: X Windows) completely, then even resizing and moving widgets around will be completely solid.

Re: performance of Qt4.1 - ac - 2005-12-21

>> In a kde mailinglist I read a comment from a kde dev saying that Qt4.0 >> is painting *much* slower than Qt3... :-( > This is wrong. Most operations are faster in Qt 4, some I just refered to this message: http://lists.kde.org/?l=kde-devel&m=113210386019716&w=2 The rest sounds good though, even for a user! ;-)

Re: performance of Qt4.1 - Segedunum - 2005-12-22

"Hopefully 4.2 will abandon native widgets (read: X Windows) completely, then even resizing and moving widgets around will be completely solid." Hmmm. That's pretty interesting.

Re: performance of Qt4.1 - aac - 2005-12-22

> This is wrong. Most operations are faster in Qt 4, some - like anti-aliased > drawing - are even infinitely faster. Just run a Qt 4 program and compare its > performance with a counterpart using Qt 3, and judge for yourself. Okay, I just tried. It's true, Qt 4(.1) is a LOT slower than Qt3 on my hardware. System specs: AMD Athlon 1.2GHz, NVidia Geforce FX 5200. Software specs: NVidia 8174 drivers, xorg 6.8.2, Fedora Core 4. The Arthur demo's in particular make my system crawl, but even resizing normal windows lags considerably. Hell, Qt4 makes GTK+ feel fast. :/

Re: performance of Qt4.1 - ac - 2005-12-22

> Okay, I just tried. It's true, Qt 4(.1) is a LOT slower than Qt3 on my hardware. :-( IIRC the contrary was supposed to be the case. Can anybody give a deeper look and explanations into this?

Re: performance of Qt4.1 - Aaron J. Seigo - 2005-12-22

you are talking about something completely different than the person you are replying to. you're talking about things like scrolling text being alphablended with a translucent overlay that is performing transformations on the text. they were talking about painting things to screen, and in particular widgets. very different things. the former is always expensive and slow. the trick is to move it to graphics hardware that has nothing better to do than throw cycles at such things and is optimized for those processes, and then it's nice and fast. you can blame the state of X.org for the current annoyances. we're only now starting to get proper drivers for a few cards, powerful (and stable) X extensions and the client-side software that uses them to make the more complex tricks like antialiasing and compositing feel fast.

Re: performance of Qt4.1 - aleXXX - 2005-12-23

> they were talking about painting things to screen, and in particular > widgets. I don't think so. The last time I tried Qt 4 was something like Qt 4.0 beta. Yesterday I compiled Qt 4.1. Demo apps start really fast :-) And painting has become much faster than in the pre-4 days :-) But still, it's significantly slower than Qt 3. Example: start Qt 4 designer in "Docked Window" user interface mode. Create a new "mainwindow". Resize this mainwindow inside designer. Awfully slow. It seems to block X refreshing for all other apps while it is being resized. Xosview "freezes" while resizing this mainwindow inside designer. Now resize the designer mainwindow. On both my boxes, AMD XP 2000+ and Intel P3/450 there is a visible delay. If I release the mouse button, then for a short moment the window background color is visible, and after maybe 0.1 .. 0.5 s the designer window is repainted. This is *really* slow and it flickers. And I really consider my box fast enough to repaint a window with a lot of widgets fast enough (XP 2000+, 512 MB, Geforce). Alex P.S. the arthur "effect" demos run slow and take 100% CPU. This is not what I'm talking about above. (while I still that it should be possible to do these things much faster)

Re: performance of Qt4.1 - aac - 2005-12-23

I noticed the same thing with Qt blocking 'X' occasionally. For example, scrolling or resizing a window will freeze all other applications for a while. But this is probably an X problem, not Qt.

Re: performance of Qt4.1 - Matthias Ettrich - 2005-12-24

This is not painting speed, this is the cost of indirect painting (painting to an offscreen buffer and then blitting the result on the screen). Some X-Servers are awfully slow doing this. Just blitting a pixmap on the screen without any painting whatsoever will give you a frame rate that windows users or game programmers only laugh at. X currently sucks in that respect. Your CPU speed doesn't mean much here, it's your graphics card, and how it is supported by the X-Server. Or rather how it's not supported. Maybe Qt should come with a little test program that blits two pixmaps on the screen, in fastest possible speed using render composite. That would show you the maximum theoretical framerate that a toolkit can achieve on your setup if its drawing speed was infinite. The result would likely be shocking to you. Comparing Qt4's designer with Qt3 is also missleading wrt "painting" speed, because Qt4 makes quite a bit of use of alpha effects (like the tinting effect when container widgets are highlighted), and child widgets are composed. Plus there was really suboptimal code in designer that painted the little dots. In Qt 4.0.0 most of the time was spent drawing those dots, don't remember to what degree that was fixed in the final 4.1.0 packages. Please don't spread rumours about "painting being slow" when you basically mean "resizing a form in designer exposes some background". That background is painted by the X-Server when an X Window is reszied, before the very same X-Server finally blits the ready-made contents on it. Qt's painting is fast, the problem is to get the painted pixels on the actual screen. And that's out of the control of the GUI toolkit. The same applies to the demos. One big step forward that we can do is ditching the concept of native widgets (read: one X Window per QWidget) altogether. This would allow us to do one blit only when a window is resized, as opposed to many blits. This would also fix the problem of exposing some background when resizing child widgets. FYI: Qt3 painted directly on the screen, like one had to do in the eighties and early ninetees. The costs of doing that are: no child widget composition (required for modern and cool styles), and flicker. Nobody wants that anymore in 2005. Until the X-Servers finally catch up with modern hardware, we will have to live with slower resizing of windows. Good news: users never do that anyway, at most they hit the maximize button.

Re: performance of Qt4.1 - aleXXX - 2005-12-28

Hi Matthias, I recompiled Qt 4.1 with -no-xrender, and now it behaves noticeable better. X isn't "blocked" anymore, I can resize the mainwindow in designer as I'm used to. > Please don't spread rumours about "painting being slow" when you basically > mean "resizing a form in designer exposes some background". That background > is painted by the X-Server when an X Window is reszied, before the very same > X-Server finally blits the ready-made contents on it. Qt's painting is fast, > the problem is to get the painted pixels on the actual screen. Well, I'm not sure I agree completely here. I mean, X is one of the main targets of Qt, maybe *the* main target. So when designing a toolkit for X, the characteristics of X should be taken into account. As a user I don't care why something feels slow, it doesn't matter whether Qt draws blazingly fast and X is too slow or whether Qt is slow and X is fast enough. In the end I only notice that there is something slow. > And that's out of the control of the GUI toolkit. Well, not completely. The toolkit can't control the speed of X, but it can use X in different ways. It can use X in a way so that the end result is slow, and it can use X in a way optimized for X, so that the (eventual) performance problems of X are not that much visible. How is the performance actually with X over network ? Alex

Re: performance of Qt4.1 - Mike - 2006-01-25

I was activated RENDER extension in XOrg with Section "Extensions" Option "RENDER" "Enable" EndSection And also added Option "RenderAccel" "1" to my nvidia board options After that QT 4.1 and it's Designer almost flying!

Re: performance of Qt4.1 - ac - 2005-12-26

> And what about the backingstore technology...? I compiled Qt 4.1 yesterday, and all I can say is that flicker is greatly reduced in this release. For comparing, I fired up the qt-assistant from Qt 3.3.5 and from Qt 4.1. Then I created some tabs, each holding documentation of different classes. Now, by switching from tab to tab you can see no more flicker with the 4.1 version, whereas with the 3.3 you can. Good job trolls!

WYSIWYG: Is this hopeless - James Richard Tyrer - 2005-12-20

Having skimmed through the new documentation: http://doc.trolltech.com/4.1/qfontmetrics.html http://doc.trolltech.com/4.1/qprinter.htm http://doc.trolltech.com/4.1/qpaintdevice.htm I find two interesting points: QList<int> QPrinter::supportedResolutions () const For X11 where all printing is directly to postscript, this function will always return a one item list containing only the postscript resolution, i.e., 72 (72 dpi ... ). int QFontMetrics::width ( QChar ch ) const Returns the logical width of character ch in pixels. I have to wonder, is it possible that the Trolls just don't get it? If you compute the font metrics at 72 DPI and then print it at 600 DPI, no wonder it looks BAD. On Windows, the printer resolution list will contain numbers like 300, 600 that it gets from the printer driver. In that context, the resolution of PostScript is INFINITY. [Another small problem is that not all printers have square resolution.] OTOH, if we are just using the DPI as logical units it would work with 72 DPI except for the type of "QFontMetrics::width". "int" will not work, it needs to be "float" for X11. But, that won't work cross platform -- or will it? How does Redmond work? The place to start appears to be with: "enum QPrinter::PrinterMode". This is where we should have the three modes: ScreenResolution PrinterResolution PostScript But, this has already been hacked so what appears to be needed is that: "HighResolution" should always refer to the resolution of the printer (we need this for Windows compatability and to make PDFs), and PostScript should be added as "3". The problem is that using this will break every function which returns the size of any font metric in pixels. I don't have any good answers -- I can only note that they appear to have used the DOS/Windows paradigm of knowing the printer resolution and painted themselves into a corner. An interim solution would be for X11 to also use the Windows paradigm of using the printer resolution for WYSIWYG layout. But, this would require changes in KPrint so that it would use a PPD file for all printing. This would not be an ideal solution since the printing would still be a little off, but it would be a great improvement -- at 1200 DPI, you probably wouldn't be able to tell the difference.

Re: WYSIWYG: Is this hopeless - Anonymous - 2005-12-21

James, > I have to wonder, is it possible that the Trolls just don't get it? They do get it. If you take a closer look at Qt 4 you'll discover that a) there is also a QFontMetricsF class that gives you (as a developer) floating point precision for simple self-made text layouting. b) /all/ the internal text layouting in Qt is using floating point precision. Actually internally 26.6 fixed point is used, just like Freetype, but that's good enough and in the API of QFontMetricsF, QTextLayout and in the higher level Scribe classes you (as a developer) see qreal. c) when laying out text you can disable the screen hinting and use linear scaled design font metrics for a nice preview on the screen that matches (line/page break wise) exactly what you also get on a high resolution printer. The last point actually still needs tuning for nicer screen output, but it does not fall into your "Trolls don't get it" category.

Re: WYSIWYG: Is this hopeless - James Richard Tyrer - 2005-12-21

By WYSIWYG, I mean true WYSIWYG. Not Windows style which is just font metrics hinted at the printer resolution. Yes, there is also a QFontMetricsF class (should have read more but ... ), but using that in place of the "int" typed class will require large changes in code. After thinking about this, it would appear that you could use the "float" type for all layout in KDE and this would solve part of the problem. It still has cross platform issues since X11 code could be used on Windows but Windows code might not work on X11 if it used the "int" class. Yes, according to the documentation: http://freetype.sourceforge.net/freetype2/docs/tutorial/step2.html Freetype expresses the size of the glyphs in 64ths of a pixel -- that is 26,6 fixed point binary. But, that is for _hinted_ font metrics. However, I have not been able to find where in Qt that you would choose unhinted font metrics. If you choose "QPrinter::HighResolution" you have not selected unhinted; it appears that on X11 that you have selected 600 DPI with hinting at that resolution -- at least it appears to me that "QPrinter::PrinterMode" would be what you would use to choose unhinted, and there is no PostScript option. True WYSIWYG requires "metrics in design font units", and without further information, I don't see how you can do that. And if you are just doing 600 DPI then the "float" class is not needed. Even if you were using 7200 DPI, integer arithmetic would be faster than float unless you had to use if for scaled font design units. Perhaps there is a Qt tutorial somewhere that might explain this in more detail.

Re: WYSIWYG: Is this hopeless - Anonymous - 2005-12-21

-- snip >Yes, there is also a QFontMetricsF class (should have read more but ... ), but using that in place of the "int" typed class will require large changes in code. After thinking about this, it would appear that you could use the "float" type for all layout in KDE and this would solve part of the problem. It still has cross platform issues since X11 code could be used on Windows but Windows code might not work on X11 if it used the "int" class. -- snip There is no portability issue using floating point precision instead of integer precision for text layouting. Not if you also do the glyph positioning in the toolkit, so the same precision is used across all platforms, which is what Qt does. -- snip >Freetype expresses the size of the glyphs in 64ths of a pixel -- that is 26,6 fixed point binary. But, that is for _hinted_ font metrics. -- snip Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. But that should be by far precise enough for decent glyph positioning on your 600 dpi printer. -- snip >However, I have not been able to find where in Qt that you would choose unhinted font metrics. -- snip People doing their own high-level text layouting (such as for example KWord might want to do when ported to Qt 4) should use QTextLayout. With QTextLayout it is possible to enable the use of design font metrics by setting the 'useDesignMetrics' property in the associated QTextOption object. Everyone else is free to use the high-level Scribe classes and enable the use of font design metrics there using QTextDocument's useDesignMetrics property.

Re: WYSIWYG: Is this hopeless - Anonymous - 2005-12-21

-- snip > Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. But that should be by far precise enough for decent glyph positioning on your 600 dpi printer. -- snip Maybe that part should be clarified. I meant it should be good enough for doing text layout in low screen resolution (~96 DPI) but with subpixel positioning for decent output on a higher resolution device then. With a factor 64 of added precision you get an effective resolution of ~6000 DPI.

Re: WYSIWYG: Is this hopeless - James Richard Tyrer - 2005-12-22

> There is no portability issue The portability issue does exist between *NIX and Windows. If a large OO Writer document is moved from Windows to *NIX and the compatibility mode in OO isn't used, the document will become noticeably shorter because hinting isn't used to compute the line lengths in *NIX. I think that the same thing might happen with Qt based wordprocessors, but only if the QFontMetricsF class functions returned non-integer values for unhinted glyphs. > Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. Actually, IIUC, FreeType2 supplies these more precise figures but it doesn't actually use them to render the _hinted_ glyphs. They are supplied so that the application can more precisely compute the layout. This could be used to support a mode where the screen image was hinted but the printed metrics were correctly based on unhinted glyph dimension. WordPerfect can do something like this and it isn't really what I would call a feature. Real WYSIWYG is much better. > But that should be by far precise enough for decent glyph positioning on your > 600 dpi printer. Perhaps although most office level lasers now start at 1200 DPI and inkjets are 1440 DPI. But, this isn't WYSIWYG, it is 600 DPI hinted fonts. As I said elsewhere, perhaps 7200 DPI hinted fonts would be sufficient in all cases, but I don't see 600 DPI as sufficient. So, I take issue with the choice of 600 DPI as the ONLY value for "HighResolution" with X11. This is OK as a default but it should be settable. > People doing their own high-level text layouting (such as for example KWord > might want to do when ported to Qt 4) should use QTextLayout. So, this is what I am taking issue with. You shouldn't have to do this (use completely different code) just to get true WYSIWYG. This should be possible using the "QFontMetricsF class" and setting the "PrinterMode" to "PostScript" (i.e. unhinted fonts).

Re: WYSIWYG: Is this hopeless - Anonymous - 2005-12-22

-- snip > > But that should be by far precise enough for decent glyph positioning on your > > 600 dpi printer. > Perhaps although most office level lasers now start at 1200 DPI and inkjets are 1440 DPI. But, this isn't WYSIWYG, it is 600 DPI hinted fonts. As I said elsewhere, perhaps 7200 DPI hinted fonts would be sufficient in all cases, but I don't see 600 DPI as sufficient. -- snip Actually QPrinter::HighResolution gives you 1200 DPI. -- snip > So, this is what I am taking issue with. You shouldn't have to do this (use completely different code) just to get true WYSIWYG. This should be possible using the "QFontMetricsF class" and setting the "PrinterMode" to "PostScript" (i.e. unhinted fonts). -- snip We are almost in agreement James :). We agree that it should be transparent to the programmer. However I argue that it is easier to default to screen dimensions when printing, because that's exactly what you also see when you debug/develop on the screen. For printing a higher resolution should of course be used, transparently to the programmer by simply scaling the QPainter. And for WYSIWYG the text should be layouted and positioned only /once/, in screen dimension but with a precision high enough to give nice output on a higher resolution printer. Default to a 7200 DPI resolution for everything would be an insane waste of resources and it is harder to understand for developers because it significantly differs from what you see on the screen (ever debugged with xmag? :). Plus 99% of the time you do want your text hinted to low-resolution screen output, because 99% of the time text is displayed solely for screen output: Text in menus, text in web pages, text in tooltips, text in labels, etc. That is the common case and that is why text is hinted by default. Those few applications that need WYSIWYG can easily set the one or other property on an object :) Anyway, I have to run now to catch my plane to my hometown for christmas vacation. Merry christmas everyone on the dot and in the KDE community :)

Re: WYSIWYG: Is this hopeless - James Richard Tyrer - 2005-12-22

> Actually QPrinter::HighResolution gives you 1200 DPI. That is good, but I did read 600 DPI in the dox. I note that as I have said before that you need to be able to choose between: "Screen", "DPI", and "FontMetrics" resolution depending on what you are doing. Obviously "Screen" is best for viewing on the screen. To emulate Windows or to make a PDF, you would normally use "DPI" but for true WYSIWYG (e.g. something to be sent out to be printed) you need to be able to choose "FontMetrics". It would be a great feature if you could choose these three modes and not have to change any code to do it. This would require using "float" for the layout and would (therefore) be a little slower -- but most machines have many times as much power as they need for wordprocessing. I don't see how 7200 DPI for layout would be a problem. It shouldn't add overhead since it could all still be done with 32 bit integers and integer arithmetic. And Merry Christmas to everyone. I got the Flu for Christmas, hope everyone else is doing better.

Re: WYSIWYG: Is this hopeless - ac - 2005-12-21

I have to admit that I don't understand a word you said. But does this mean that the printing problems in KWord will not be fixed even when based on this version of Qt?

Re: WYSIWYG: Is this hopeless - James Richard Tyrer - 2005-12-21

No, what it does mean is that so far in reading the documentation, I have not yet figured out how to do true WYSIWYG using font design units transformed into actual floating point dimensions (rather than DPI) for glyph dimensions. However, if we could work in 7200 DPI resolution, it would be so close to correct that nobody would know the difference and that appears to require only small changes in Qt to do. 7200 DPI is a good value to simulate WYSIWYG because it is 5*1440 and 6*1200 so it would work for both common printer resolution moduli.

Re: WYSIWYG: Is this hopeless - cm - 2005-12-22

Hello James, please take a look at this: http://blogs.qtdeveloper.net/archives/2005/12/22/printing-and-wysiwyg/

Now what about KDE 4 itself?... - SMC - 2005-12-21

Just curious if there are any estimates as to how soon KDE4 will hit the "usable alpha" stage at this point. Just wondering how soon I, as a compulsive KDE-svn recompiler, can switch to the new KDE4 branch and expect to be able to reasonably use the resulting KDE system productively with "not too many" problems. Recompiling updates to KDE 3.5 just doesn't have the same thrill it used to... (Is it possible and feasible to have QT4.x and QT3.x coexisting on the same system at the same time?)

Re: Now what about KDE 4 itself?... - Chakie - 2005-12-21

Yes, it's perfectly possible to have both Qt3 and Qt4. I use KDE 3.5 and develop a Qt4 app. Kubuntu at least has ready packages for Qt4 that work nicely.

Re: Now what about KDE 4 itself?... - Iuri Fiedoruk - 2005-12-21

Same happens in Suse 10.0

3d - pinky - 2005-12-22

does there are plans to extende arthur to do 3d graphic too? I have heard about the upcomming windows-api which will offer a all in one solution (2d/3d) through WPF. I think it would be a real improvement if the Qt api would also offer 2d/3d functionality in a integrative qt-way. Are there any plans for the future?

Kubuntu Breezy packages? - Sean Kelley - 2005-12-22

I hope we will see some Kubuntu Breezy packages for this soon. Sean

runner up prizes? - Luke Parry - 2005-12-23

I know that there will be one big prize but what about people who come in like second or third, i feel it is unfair for them to waste their time without having some sort of prize. This would only have to be small in conisderation such as a certificate or whatever... that is signed

Missing features in Qt4 Designer - Manuel Fdez - 2005-12-30

Where is the C++ editor inside Qt Designer? Where is Project Settings Window? Where is the Signal Handlers Tab? I like to have the Properties Tab and Signal Handlers Tab in the same panel. I think new concepts like Edit Signals/Slots Mode and choose Designer User Interface Mode (Docked Window and Multiple Top-Level Windows) are good. I think the new Qt4 Designer is too simple , I like Qt3 Designer features.

Re: Missing features in Qt4 Designer - Anonymous - 2006-01-01

Did you read the http://doc.trolltech.com/4.1/qt4-designer.html reasoning?