Qt 4.0 Beta 2 Released

Tuesday, 12 April 2005  |  Binner

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:

What exactly has changed since version 3.3.X? - Anonymous John - 2005-04-12

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?

Re: What exactly has changed since version 3.3.X? - am - 2005-04-12

Here ya go. http://doc.trolltech.com/4.0/qt4-intro.html

Re: What exactly has changed since version 3.3.X? - Hisham - 2005-04-13

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.

Re: What exactly has changed since version 3.3.X? - ac - 2005-04-13

How did you get that "scissors-effect" in your post??? That's neat!

Re: What exactly has changed since version 3.3.X? - Christopher Smith - 2005-04-13

Hmmm... seems to me that doing: template <typename Iterator> 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?

Re: What exactly has changed since version 3.3.X? - Cornelius Schumacher - 2005-04-13

> 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.

Re: What exactly has changed since version 3.3.X? - anon - 2005-04-12

>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.

Re: What exactly has changed since version 3.3.X? - Anonymous - 2005-04-12

> 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. :-)

Re: What exactly has changed since version 3.3.X? - ac - 2005-04-12

Please note it's correctly spelled Qt ("cute"), not QT ("QuickTime").

Re: What exactly has changed since version 3.3.X? - Paul Koshevoy - 2005-04-12

I've always spelled it Qt ("cutie") Paul.

Re: What exactly has changed since version 3.3.X? - Jim Paquette - 2005-04-13

Don't be so picky. Get a life.

KDE preparation - Frank Dux - 2005-04-12

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?

Re: KDE preparation - Anonymous - 2005-04-12

Is there a need to add something above the Qt documentation? I think it's very good.

Re: KDE preparation - Boudewijn - 2005-04-12

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...

Re: KDE preparation - Tim Beaulen - 2005-04-12

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

Re: KDE preparation - Frank Dux - 2005-04-12

"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.

Re: KDE preparation - Anon - 2005-04-12

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.

Re: KDE preparation - Boudewijn Rempt - 2005-04-12

Exactly.

Re: KDE preparation - Aaron J. Seigo - 2005-04-12

i agree. let's chase away all the managers. we don't want them.</sarcasm> ;-P

Re: KDE preparation - Boudewijn Rempt - 2005-04-13

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.

Re: KDE preparation - Aaron J. Seigo - 2005-04-13

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.

Re: KDE preparation - Boudewijn Rempt - 2005-04-13

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.

Re: KDE preparation - Anonymous Custard - 2005-04-13

"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. >;-)

Re: KDE preparation - Derek Kite - 2005-04-13

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

Re: KDE preparation - JohnFlux - 2005-04-15

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.

Re: KDE preparation - MaXe - 2005-04-16

What a fool. (The 'Get out. I've got work to do'-guy).

Re: KDE preparation - Dan Ostrowski - 2005-04-13

/agreed

Re: KDE preparation - Richard Moore - 2005-04-12

Well, there's already some stuff going on: http://www.kdedevelopers.org/node/view/936 for example. Rich.

So... - Anonymous - 2005-04-12

...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?

Re: So... - Ryan - 2005-04-12

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.

Re: So... - Anonymous - 2005-04-12

> 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. :-)

Re: So... - hannes gütel - 2005-04-12

At least there is a 3.5 feature plan.

Re: So... - Capit Igloo - 2005-04-13

>«At least there is a 3.5 feature plan.» Where ? (nothing here for the moment: http://developer.kde.org/development-versions/)

Re: So... - Aaron Krill - 2005-04-13

Here: http://developer.kde.org/development-versions/kde-3.5-features.html

Re: So... - James Richard Tyrer - 2005-04-14

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

Re: So... - Anonymous - 2005-04-14

Assuming that you have a CVS account, change developer.kde.org/development-versions/kde-features.xml

Re: So... - Anonymous - 2005-04-13

There is also a 4.0 feature plan - both contain mostly randomly spread delayed entries from 3.4 feature plan currently.

Faster? Numbers? - Anynomous - 2005-04-12

So opposed to beta1, beta2 is actually supposed to be faster than Qt3? I'd like to see some numbers that prove this.

Re: Faster? Numbers? - Anonymous - 2005-04-12

And I want to see your numbers that beta1 was not faster than Qt3 too. :-)

Eye-candy? - mOrPhie - 2005-04-12

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. :)

Re: Eye-candy? - anon - 2005-04-12

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!

Re: Eye-candy? - MORB - 2005-04-12

"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.

Re: Eye-candy? - Roberto Alsina - 2005-04-13

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).

Re: Eye-candy? - SadEagle - 2005-04-12

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.

Re: Eye-candy? - LMCBoy - 2005-04-12

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

Re: Eye-candy? - LMCBoy - 2005-04-12

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!

Re: Eye-candy? - cniehaus - 2005-04-13

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?

Re: Eye-candy? - Jason Harris - 2005-04-13

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.

Re: Eye-candy? - Matt - 2005-04-13

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

Re: Eye-candy? - SadEagle - 2005-04-14

The AA code in Qt's OpenGL painter uses multisampling, not line and point antialiasing

Re: Eye-candy? - MORB - 2005-04-12

Actually, arthur is a vector-based rendering engine. The page that describe arthur only describe what changed since qt3, but in qt3 it was already possible to apply transformations (rotation, scaling, etc.) to subsequent drawing operations. Since arthur, in addition to qt3, supports alpha and transformation of line width and brushes, as well as double-buffering, it has everything that should be needed to achieve those trendy animated eye-candy.

Re: Eye-candy? - Ian Monroe - 2005-04-12

The immediate advantage of Arthur is a cleaner API and faster response.

Re: Eye-candy? - Bryan Feeney - 2005-04-12

Arthur supports several different types of backend. At the moment does not support Cairo (as I understand it, Cairo is still in a developer preview stage), however it does support OpenGL, which should allow for some powerful rendering. As other comments have mentioned, Qt has supported vector drawing for quite some time.

Re: Eye-candy? - uddw - 2005-04-13

Why is cairo "Vector graphics" and Arthur isn't? If you can draw a line (circle, spline etc.) between Point A and B, then you have vector based description. Given today's technology, these vectors have to be converted into a pixel-based representation, no matter if it's Cairo or Arthur. At least as long as you don't use an ancient vector display. To be honest, I don't know cairo at all. It doesn't use a scene graph, or does it? This would make it conceptually different from Arthur, but then I would be happy that Trolltech didn't follow that path. Otherwise, what's the big difference? What - except for good taste - stops us from drawing our buttons with an animated and vectorized leopard fur look?

Re: Eye-candy? - jeremy - 2005-11-18

Hi. On Windows, there are a lot of good Qt 4.0 graphics demos in Start -> Programs -> [Qt] -> Examples and Demos Select "Demonstrations" See Vector Deformation, Affine Transformations, Path Stroking, etc. Looks like vector graphics to me. And looks really nice. (I don't know where these are on other platforms.) To me, supporting "vector graphics" is an abstract concept. Do you want to view SWF or EMF files? Do you want to view PDF files? Do you want to print to PS/PDF? Here is my quick (uneducated) take on choices of various vector graphics formats in Qt: SVG -> use ksvg libs PDF -> use kpdf libs PS -> use PDF engine? EMF -> no idea; MS file formats are a pain SWF -> no existing Qt app (?) DXF (CAD) -> Open Cascade (Qt3-based) If you need to do "heavy duty" vector graphics, maybe you can use something like Open Cascade, which an open source CAD toolkit. [http://www.opencascade.org/] Unfortunately, this is Qt 3, but it is a fantastic example of how powerful Qt can be for graphics. It will do BREP solids, meshes, irregular grids, etc. (basically anything a CAD system can do). Then you can dump to a lot of different file formats. I imagine PDF, SVG, etc. would not be incredibly difficult to support if it isn't there already. There is also the Qt bindings for Coin3d for heavy-duty 3d graphics display. Maybe you can poke around for other 3rd party Qt graphics libraries. There are a lot of others out there and GL support is really good. Qt is pretty amazing for graphics work if you know where to look. I don't know nuthin about the GTK stuff. :) Good luck.

WOW - Look at that changes! - canny - 2005-04-12

It's unbelievable how beta2 has changed from beta1. I'm not talking about improvements here and there, but new cool stuff. Look at the Arthur Paint System for instance: > QImage has become a paint device. Great! Kolourpaint, KPDF, <any other nae here> will have nicer graphics and lots of speedups due to this. > We extend our gradient support. It is now possible to specify multiple colors at various positions in a gradient and different spread methods. We have also added support for radial and conical gradients That's juicy! > It is now possible specify a QBrush as the fill method for a pen. This makes it possible to for instance, have textured text quite easily. Any other words to add? Yes, thanks TT! :-)

Re: WOW - Look at that changes! - Clarence Dang - 2005-04-14

> It's unbelievable how beta2 has changed from beta1. I'm not talking about > improvements here and there, but new cool stuff. Look at the Arthur Paint > System for instance: > > > QImage has become a paint device. > > Great! Kolourpaint, KPDF, <any other nae here> will have nicer graphics and > lots of speedups due to this. This is great but has QImage -> QPixmap conversion been sped up?

Re: WOW - Look at that changes! - JohnFlux - 2005-04-15

You should always assume the QImage->QPixmap conversion is very slow, as it will be over a network. QImage is local, QPixmap is on the server.

Re: WOW - Look at that changes! - ac - 2005-04-15

What network are you talking about?

Re: WOW - Look at that changes! - Clarence Dang - 2005-04-16

> You should always assume the QImage->QPixmap conversion is very slow, as it will > be over a network. QImage is local, QPixmap is on the server. I'm optimising for the more common local case. In Qt3, it was very slow - I'm wondering if it has improved.

Developing - dikatlon - 2005-04-12

Heh...actually a dude and I have started to code an economy program with the Qt 4 libs. It's called tribok. And what I have seen Qt 4 is much more better.

Re: Developing - jumpy - 2005-04-12

Are you creating the program using the model/view abstracts and other new concept or porting qt3-style programming/ideas? Looking forward to see your creation! have fun, guys :-)

Re: Developing - dikatlon - 2005-04-13

For the moment, we are just porting the qt3 code to qt4...but we don't use these tools like qt3to4 to port. We will see what happends, at this base of code dev we have done there isn't really much to talk about yet. Thanks for the encouraging reply :)

is Qt becomming his own programming language? - eagle - 2005-04-13

Hi, i have used Qt3 already for some programs and have now read a article about Qt4 on a german linux magazine. I'm a little bit upset. Qt has developed there own containers and so on for good reasons. But now Qt also develop his own "language", as i have seen there will be a foreach statement to iterate through Qt containers. I'm not sure if i should like this development. It seems like Qt becomes more and more not only a toolkit or framework but even design his own programming language based on C++.

Re: is Qt becomming his own programming language? - Anonymous - 2005-04-13

if it means easier coding and less boring/weird stuff for the programmer, why not?

Re: is Qt becomming his own programming language? - uddw - 2005-04-13

It's just another way to iterate over the elements of a container. There are different ways to do this already, so I don't see what harm it could do add another method if it is much more clear than the others. Of course we can do everything in a pure STL compatible way, which is often even most efficient. But sometimes readability matters more.

Re: is Qt becomming his own programming language? - eagle - 2005-04-13

yes, it's "just another way" but the question is if it is the right way to extend the language C++ with "just another way"? As long as we talk about the toolkit/framework i have nothing against it if Trolltech needs a special container, data-type or keyword (e.g. emit,..). But i'm not sure if it is the right way to introduce own statements like foreach. If i develop a lot of GUI things with Qt for about one year and than someone ask me for a console-program i will start with C++ and will try to use things like foreach because i'm used to use this things. But it want work because this statement is not a C++ statement. I think basically we can think about it, if a statement like foreach is usefull in C++. But we should think about it in the C++ standard and not in our own way and ower own lib. Because i'm fear that this will "pull C++ to pieces" and C++ code will have more and more differences to C++/Qt code. I think this is a bad development because it weakens the C++ Standard in the long run.

Re: is Qt becomming his own programming language? - Corbin - 2005-04-13

What if you try to use Qt functions? How is that any different?

Re: is Qt becomming his own programming language? - Dolio - 2005-04-14

What if I program in Haskell, Ruby, or any other good language for a year, and then someone requires me to write a C++ program? I'll have to get back in the swing of things. If the bigwigs on the C++ standards committee see a foreach statement, and decide it's good, and put it in the C++ standard, and compilers finally support it, then great, everyone can use it. But that would probably take years, if it happens at all. In the mean time, people can use Qt, and allow themselves a nugget of elegance in the overall pain that is C++ programming. :) Some people like to do: #define unless(a) if(!(a)) Is that also a capital sin? Why does C++ have macros, and why is the template language Turing complete if you're not supposed to do things like this?

Re: is Qt becomming his own programming language? - eagle - 2005-04-14

> What if I program in Haskell, Ruby, or any other good language for a year, > and then someone requires me to write a C++ program? so you consider Qt/C++ as a own language if you compare my scenario with the scenario were someone programs in "Haskell, Ruby, or any other good language and than go back to C++"? Thank you for confirm my statement.

Re: is Qt becomming his own programming language? - Richard Dale - 2005-04-14

"What if I program in Haskell, Ruby, or any other good language for a year, and then someone requires me to write a C++ program? I'll have to get back in the swing of things." In the case of ruby, you can write ruby Qt or KDE programs with QtRuby and the Korundum/KDevelop RAD environment. So you might not have to get back to C++ programming anyway. Turing Complete vs. Language usability? I'm sure that both C++ template language and ruby were designed by very clever people. The difference is that ruby was designed from the ground up to 'be usable', and indeed it is. C++ templates were not designed with usability in mind and are one of the hardest features of any programming language to understand properly.

Re: is Qt becomming his own programming language? - LuckySandal - 2005-04-13

#define foreach(c,i) for (i = c.start(); i != c.end; i++) this is not a new language!

D ?? - hannes gütel - 2005-04-13

"own programming language based on C++." Why not take D? D is like Java and C# but lacks a class library.

KDE project for D - André - 2005-04-13

http://users.tpg.com.au/smackoz/

can we do this with Qt4 ? :) - Pat - 2005-04-13

I'm not a big fan of gnome but these one look really cool. http://www.gnome.org/~seth/blog-images/monkey-hoot/TransparentWindows.ogg http://www.gnome.org/~seth/blog-images/monkey-hoot/WorkspaceSwitching.ogg http://www.gnome.org/~seth/blog-images/monkey-hoot/WobblyWindows.ogg http://www.gnome.org/~seth/blog-images/monkey-hoot/WobblyWindowsIntro.ogg http://www.gnome.org/~seth/blog/xshots

Re: can we do this with Qt4 ? :) - jumpy - 2005-04-13

The real question is: can we do this with today's XOrg? We were on that front with Impresario, Zack's WM, but the project stopped after finding arch problems in that implementation. Luminocity will stop too.. they don't have realized the problem yet. Btw having Zack, with his experience on the field, hired at Trolltech and working on that stuff really gives us a gear more than our competitors.

Re: can we do this with Qt4 ? :) - cniehaus - 2005-04-13

>Luminocity will stop too.. they don't have realized the problem yet. Can you explain this? What problem?

Re: can we do this with Qt4 ? :) - Illissius - 2005-04-13

http://www.kdedevelopers.org/node/view/814

Re: can we do this with Qt4 ? :) - ac - 2005-04-13

Unfortunately Zack does have a tendency to abandon projects when the going gets tough viz. Qt Mozilla.

Re: can we do this with Qt4 ? :) - konqi - 2005-04-13

>> Luminocity will stop too.. they don't have realized the problem yet. You don't seem to realize that Lumonicity is just a concept. The real thing (when it's integrated in Metacity) will be different and use the XGL server (thus fixing a number of issues), afaik.

Re: can we do this with Qt4 ? :) - kundor - 2005-04-16

What I found most impressive about those was the "live" pager, with constant updates not only for the windows on the current desktop but for those on the other desktops as well. Very impressive. The rest of the features I don't care about so much ;-)

Are the SERIOUS font related bugs in Qt-3 fixed?? - James Richard Tyrer - 2005-04-13

My only interest is whether the bugs related to font will be fixed. Will the PostScript driver be fixed to work as well as the PS driver in OpenOffice does? Specifically, (a) will it be able to make scalable Type42 fonts from TrueType fonts and (b) will is support PS font metrics and printer resolution hinted font metrics. Note that currently Qt supports only screen resolution hinted font metrics. Will the PostScript driver be fixed so that it gets the PostScript font names correct? My patch fixes this, but it is really just a kludge. Will the font system be fixed so that it can properly deal with Type1 font names (Family, Weight, & Width)? NOTE that this is a general bug that perhaps needs to be addressed elsewhere. TrueType and Type1 font names are not the same when they contain a Width (and possibly some issues with some Weights other than Regular and Bold). Will the font system be fixed so that it can properly deal with font faces other than the 4 mode paradigm: Regular, Bold, Italic, Bold Italic? IMO, these are serious bugs and I am at a loss to see how Qt got to version 3.0 without their being fixed. And, I think that part of this is a regression (I used to use Helvetica Narrow, but now it doesn't even show up in the KDE font selector). -- JRT

Re: Are the SERIOUS font related bugs in Qt-3 fixed?? - ac - 2005-04-13

I'm pretty sure that Trolltech would be more than delighted, if you would try out Qt4 Beta2 and test if those font bugs still exists.

Re: Are the SERIOUS font related bugs in Qt-3 fixed?? - James Richard Tyrer - 2005-04-14

I am going to try a build of KDE-3.4 BRANCH against Qt-4. But ... (TM). Some of these issues are going to require changes in application code -- the font metrics issue is going to require application changes. Currently some of the font faces work correctly and some don't. Testing this is confounded by the fact that we don't know how much of the problem is in KDE and how much is in Qt. I have been told that these are Qt problems, but I have no way of knowing for sure. Perhaps some assistance from the maintainer of the KDE code would help. I have found that the problem with Oblique being listed (INCORRECTLY) as Italic is a KDE problem. This hack appears to have fixed it: diff -Naur kdelibs.old/kdeui/kfontdialog.cpp kdelibs/kdeui/kfontdialog.cpp --- kdelibs.old/kdeui/kfontdialog.cpp 2004-11-03 09:15:17.000000000 -0700 +++ kdelibs/kdeui/kfontdialog.cpp 2005-04-13 17:45:33.000000000 -0700 @@ -476,8 +476,6 @@ if(pos >=0) style = style.replace(pos,5,i18n("Regular")); pos = style.find("Normal"); if(pos >=0) style = style.replace(pos,6,i18n("Regular")); - pos = style.find("Oblique"); - if(pos >=0) style = style.replace(pos,7,i18n("Italic")); if(!styleListBox->findItem(style)) { styleListBox->insertItem(i18n(style.utf8())); currentStyles.insert(i18n(style.utf8()), *it); News Flash: Italic and Oblique are not the same. Also please note that some fonts have a face called: "Normal" so substituting for that is also questionable. And, where does: "Medium" get replaced? IAC, I have over a thousand font so it will take a while. :-) But, because I do have that many fonts, I can help with testing if someone is interested in fixing the problems. Clearly, we do need to get these font name issues fixed. It is not a usability improvement to have fonts displayed with the WRONG face names. -- JRT

Re: Are the SERIOUS font related bugs in Qt-3 fixed?? - ac - 2005-04-14

> I have found that the problem with Oblique being listed (INCORRECTLY) as Italic is a KDE problem. This hack appears to have fixed it: Yeah, those replacements look strange. Unfortunately the commit message for the change doesn't really give a detail reason for this. (https://svn.kde.org/viewcvs/trunk/kdelibs/kdeui/kfontdialog.cpp?rev=128434&view=markup)

Re: Are the SERIOUS font related bugs in Qt-3 fixed?? - James Richard Tyrer - 2005-04-15

Is it possible, then, that my missing Helvetica faces are a KDE problem rather than a Qt problem as I was told? For example, I have Helvetica Narrow installed (Type1). This used to work in KDE 2.<something>, but now it doesn't show up in the KDE Font Selector dialog box. -- JRT

Re: Are the SERIOUS font related bugs in Qt-3 fixed?? - James Richard Tyrer - 2005-04-16

I now beleive that part of the font problem is in KDE -- rather than Qt -- code so I filed a bug report: http://bugs.kde.org/show_bug.cgi?id=103852 It was immediatly marked with Priority: VLO, which I presume is one small step above WON'T FIX. -- JRT

Qt4 based Qtopia/Opie? - ac - 2005-04-13

Any word on when we might be seeing Qtopia/Opie releases based on Qt4? I'd love to see an HP iPAQ h3600 PDA/phone running Qt4 based Opie on Linux <drool>.

Re: Qt4 based Qtopia/Opie? - Lorn Potter - 2005-04-13

Work is being done on porting Qtopia to Qt Embedded 4. Opie has not yet begun, but will soon enough. There is a lot of work to be done jumping from version 2 to 4!

Re: Qt4 based Qtopia/Opie? - cniehaus - 2005-04-13

I hope you will be successful. Qt2 was a main reason for me to no longer develop stuff for Opie.

build failed - katakombi - 2005-04-13

Hi, my build progress failed, is there a possibility to get a binary package for Linux/Win?

Re: build failed - Aaron Krill - 2005-04-13

What was the error?

Re: build failed - katakombi - 2005-04-14

... ... ... In file included from ../../include/QtGui/private/qpaintengine_x11_p.h:1, from kernel/qapplication_x11.cpp:67: ../../src/gui/painting/qpaintengine_x11_p.h: In member function `virtual QPaintEngine::Type QX11PaintEngine::type() const': ../../src/gui/painting/qpaintengine_x11_p.h:107: error: `qt_x11Data' is not a member of type `QPaintEngine' make[3]: *** [.obj/release-shared/qapplication_x11.o] Error 1 make[3]: Leaving directory `/usr/src/app/qt-x11-opensource-4.0.0-b2/src/gui' make[2]: *** [release] Error 2 make[2]: Leaving directory `/usr/src/app/qt-x11-opensource-4.0.0-b2/src/gui' make[1]: *** [sub-gui-make_first-ordered] Error 2 make[1]: Leaving directory `/usr/src/app/qt-x11-opensource-4.0.0-b2/src' make: *** [sub-src-make_first-ordered] Error 2 katakombi@1[qt]$

Qt Good! Designer Bad! - brockers - 2005-04-15

Qt 4 is looking totally amazing, but I have to say that I am getting more and more disappointed by Qt Designer. The drag'n drop signal/slot connector is totally worthless for any application with more than a dozen objects, the new SDI mode is a hack, and drag'n drop of objects is a cute feature but a total pain in the arse if you have a fairly sizeable project. Designer is a huge part of Qt and its is not yet even close to being ready for release. Isn't this the last beta before we start RC releases? Bobby

Re: Qt Good! Designer Bad! - Anonymous - 2005-04-19

You will have to wait until Qt 4.1 for a mature Qt4 designer and the missing classes of Qt3 (QCanvas, ...) being ported.