trenton
Qt
Posted by trenton
 in Qt
 on Monday, May 05, 2008 @ 14:24

Some time ago we announced an alpha version of the Cocoa port. It made a minor splash and I like to say thanks to all the people that have provided feedback so far and put up with our alpha-quality release.

It was always intended that we would have snapshots available for this port, but there were so many things going on that this kind of slipped through the cracks. However, they are available now through FTP.

More info on snapshots is available here.

The open source snapshots can be downloaded here.

There are no rsync snapshots for the Cocoa port at the moment.

So, if you like life on the edge, feel free to check them out. If you’d rather wait for something a bit more “blessed,” you should get your chance soon enough.

trenton
Qt
News
Posted by trenton
 in Qt, News
 on Monday, March 03, 2008 @ 09:50

You may have remembered that in the past I’ve talked about some of the development of 64-bit applications on Mac OS X. The gist of it is that Apple changed their position on supporting 64-bit Carbon, the library we depend on for running Qt GUI applications. It became obvious early on that Apple wasn’t going to change their position on this, so it left us with two choices:

  1. Keep Qt Carbon-only and forego 64-bit support.
  2. Create a port of Qt that used Cocoa as its backend.

Naturally, since we already support 64-bit on the other platforms and since the idea of using Qt is to help insulate you from changes such as this, we decided on the latter option. It did mean that we had a bit of work ahead of us, since we had to re-write some of the internals of Qt (particularly widgets and events), but most of the other modules were already there.

I’m happy to say after a bit of work, we’ve made progress and we’re proud to offer an alpha for curious people that want to try 64-bit applications on Mac OS X 10.5. It is based off a fairly recent snapshot of 4.4.0, so it will have all the bugs and features of 4.4. There still is a lot that doesn’t work and there’s a way to go (hence the term “alpha”). On the other hand, having more people try it out will help us find bugs and will make it much better (there’s only so much we can test locally).

Here are the links for the
open source package
and the commercial package.

The official press release is here (along with an ouroboros link back to this blog post).

The place to offer feedback is on the qt4-preview-feedback mailing list. Please consider putting something about Cocoa in the subject so that it gets to the right people.

By default, the package is built in 32-bit (in case you happen to not have a 64-bit machine). To build in 64-bit pass -arch ppc64 or -arch x86_64 (if you want to build 64-bit universal, pass both). I would also recommend passing -prefix $PWD so that it is not necessary to run make install. I’m not sure make install works in this package.

Since we aren’t putting up the documentation for the alpha up (it’s pretty much the same docs as 4.4), I’m reproducing the known issues for this package here:

This document explains the current list of features in the Qt/Mac Cocoa port that are currently not working. Most of the issues will be addressed in upcoming snapshots and beta releases. We hope that all the issues should be addressed by the time the of the final 4.5.0 release.

What Works

Here are the things that we can say about the current state of the Qt/Mac Cocoa port.

  • 64-bit Support: The Qt libraries currently do build and link as 64-bit frameworks and it is possible to build and run many of the Qt examples as 64-bit.
  • HIViews are now NSViews: Every QWidget is now backed by an NSView pointer instead of an HIViewRef. QWidget::winId() will return an NSView pointer that can be used in other Cocoa technologies (e.g., Core Animation).
  • Some Native Dialogs Work: QFileDialog and QColorDialog have been ported to use NSOpen-/NSSavePanel and NSColorPanel respectively. QPrintDialog and QPageSetupDialog are not in this release, but are on their way. Currently, none of these dialogs show up as sheets pending the creation of an asynchronous API.
  • Painting, Printing, and Styles: Since printing and painting used Quartz 2D and styling used HITheme, these sub-systems work without any changes.
  • OpenGL: OpenGL is fully supported,including pixel buffers and framebuffer objects.
  • Clipboard: Using QClipboard to copy and paste data works as expected.
  • Mouse, Keyboard, and Wheel events: Mouse, keyboard, and wheel events are dispatched to the proper widget. The Qt/Mac Cocoa port respects Cocoa’s idea of a "First Responder."

Current Known Issues

The following are items that don’t currently work, but that we plan to have resolved before the final release of the Qt/Mac Cocoa port. Please do not file bugs on these.

  • Carbon Support: The current source tree for the Qt/Mac Cocoa port contains source for building Qt/Mac with Cocoa. It contains some of the source code that is used for the Carbon port, but it is currently not set up to build the Carbon Qt/Mac libraries. Please use a normal release or snapshot if you want to use Carbon.
  • Drag and Drop Support: Drag and Drop is currently not implemented and needs to be ported to Cocoa, but using the clipboard does work at this time.
  • Accessibility: Accessibility support is not implemented and needs to be ported to Cocoa.
  • Text: Most text rendering works fine for Latin-1 characters. However, rendering non-Latin-1 characters has not been tested.
  • Input Methods: Input methods also need to be ported to Cocoa.
  • Shortcuts: Shortcuts that exist outside of the menu bar may not be dispatched.
  • Tablet Support: The tablet support has not been ported from Carbon yet. However, it should still be possible to use the tablet as a mouse.
  • Phonon: Phonon uses the QuickTime backend that is only available on 32-bit. Using Phonon in 64-bit requires a QTKit-based backend and has not been done.
  • Unified Toolbar: The QMainWindow::setUnifiedTitleAndToolBarOnMac() method currently does nothing.
  • Dialogs, Tool Windows, Sheets, and Drawers: At the moment, all windows are subclasses of NSWindow. This means that window types like drawers and sheets do not work and tool windows do not get the right decorations. Modal dialogs do show up at the correct window level, but are not yet considered "panels." Many window flags are not recognized.

Things We Don’t Expect to Support

The following items that we do not plan on spending any resources on unless there is monumental outcry for their inclusion.

  • Qt3Support: At this time we have no plans for making the Qt3Support module work with the Qt/Mac Cocoa port in 64-bit mode. Following in footsteps of Apple, we would like to encourage you to consider the time of going Cocoa and 64-bit as a chance to jettison Qt 3 constructs and classes.
  • Support for versions of Mac OS X below 10.5: We are using methods and classes that are only available in 10.5 and higher. Most of these functions don’t have any equivalent on earlier versions. We recommend using the Carbon version for earlier versions of Mac OS X. We anticipate keeping the Carbon port supported at least for the lifetime of 4.5.
  • Support for -no-framework or -static: Cocoa requires that we load a nib in order to properly access the global menu bar. This nib has to reside on disk somewhere. The most logical place for it to reside is inside the QtGui framework. For this reason, building Qt as standard "dylibs" or statically is no longer supported.
trenton
Qt
News
Posted by trenton
 in Qt, News
 on Friday, December 28, 2007 @ 11:05

In Norway (and I guess around the rest of the world) now is the time between Christmas and New Year’s. The Norwegians call the time romjul. Rom in Norwegian typically means rum, the distilled beverage. However, rom can also mean “room” or “space” and that’s what it means in this context, the time between Christmas and New Year’s Day. Therefore, I affectionately call this time, “Space Christmas” hoping to evoke a campy sci-fi feel for the time, usually to some Norwegians chagrin. It seems to have stuck though as I’ve heard Norwegian in the halls of Trolltech use this phrase as well.

Anyway, the point is that this is traditionally a down time when people are out doing other things. Sometimes people do check blogs during this time though, so I decided to spotlight on a couple of things in Qt/Mac that are in Qt 4.4.0. Both of these are little things that are no where near as earth-shattering as any of big features, but I think they are worth mentioning.

The first is something that I’ve sorely missed in Qt, and others have as well too I’m sure, proper support of proxy icons. A proxy icon is a nice feature of Mac OS X that allows you to put an icon in the title bar of a window to act as a “proxy” in drag operations. This turns out be extremely useful once you know about it. You can also do a Command+Click on it and it will show a pop-up menu with a path to where the item is on disk. This is very handy too when you want to make sure which file you happen to be editing. More information on proxy icons can be found at Apple’s Developer Website.

Astute readers of Qt Quarterly will remember this article where I talk about some of the events that were added in Qt 4. One was the Qt::IconDrag event, which allowed one to emulate the proxy icon. However, it was only emulation and it was a lot of work for something that I think most people wouldn’t bother doing unless they really were concerned about their Mac OS X application. I know of one person, besides me, that actually did this.

So, we needed an API that allowed you to get set the proxy icon, but also was worthwhile for people to use it in cross-platform code. It seems we found it with QWidget::windowFilePath property. This will associate a file path with a window, on all platforms it will do also set the window title of the window to the filename including the [*] token so that it behaves well with QWidget::windowModified property. If you still want control over the title bar, that’s OK, just set the QWidget::windowTitle property and it will use that. Oh yes, on Mac OS X you get the added benefit of a proxy icon if the path exists.

That means that you can take out old code like this:

QString shownName;
if (fileName.isEmpty())
shownName = "untitled.txt";
else
shownName = QFileInfo(fileName).fileName();

setWindowTitle(tr("%1[*] - %2").arg(shownName).arg(tr("Rich Text")));
setWindowModified(false);

With something like:

QString shownName = fileName;
if (fileName.isEmpty())
shownName = "untitled.txt";
setWindowFilePath(shownName);
setWindowModified(false);

Granted it may not seem like much, but if you’ve written a lot of application saving and loading code, it’s less to write and you get a real proxy icon for free (as shown below) with no code on your part.

Proxy Icon on Mac OS X

So, that’s the first thing and anyone writing Qt code can take advantage of it. The second is very Mac OS X specific and shouldn’t affect the vast majority of users out there, but co-workers have asked about the change, so I thought I would say a few words on it here. In the course of my bug fixing, I changed Qt applications to no longer make themselves the front application anymore on start-up. For most applications that you launch via Finder, the Dock, Xcode, or Launch Services (which implies QDesktopServices) you should see no difference. If you are launching an application by executing it directly, you may need to tell it to raise if you want that application to take precedence over the current application. This is to be more in line with all the other applications on Mac OS X (feel free to experiment). The main idea is not to grab focus away from the main application, which can be annoying. If you really want to people to turn their attention to your app you can use something like QApplication::alert which will bounce the icon on the dock on Mac OS X and do similar attention grabbing tricks on other platforms. This at least allows people to finish their current thought before switching to that application.

Anyway, there’s a spotlight on some things to expect in Qt 4.4. I hope your find use for them.

Happy Space Christmas!

trenton
Qt
Posted by trenton
 in Qt
 on Tuesday, August 21, 2007 @ 20:19

I must admit, I’m not the best blog writer out there. I always find it fun to read the new entries on labs.trolltech.com than write a new one myself. I enjoy writing articles for Qt Quarterly more, then I have something that is crunchy and I can put it on a shelf and collect space. I suppose I could invest in a printer for the blog, but that seems like more work. Anyway, I found a topic here that follows up on a previous Qt Quarterly article of mine and updates it to more modern Qt technologies, all in a short enough space for a blog entry (I hope).

A couple years ago, I quickly wrote the article, Fading Effects with Qt 4.1. It outlined a fader widget which you could drop on top of another widget (like a QTabWidget or a QStackedWidget) and have a fade transition. It was a quick job that showed off the neat effects you can do when you have a backing store. Since I wrote that article, there were some things added to Qt 4.2 that make the thing even easier to use. So, I thought I would point them out in case you missed them. Download the source code from the original article and you can make changes at home.

Here’s the header:
class FaderWidget : public QWidget
{
Q_OBJECT
Q_PROPERTY(QBrush fadeBrush READ fadeBrush WRITE setFadeBrush)
Q_PROPERTY(int fadeDuration READ fadeDuration WRITE setFadeDuration)
public:

FaderWidget(QWidget *parent);

QBrush fadeBrush() const { return startBrush; }
void setFadeBrush(const QBrush &newColor) { startBrush = newColor; }

int fadeDuration() const { return timeLine->duration(); }
void setFadeDuration(int milliseconds) { timeLine->setDuration(milliseconds); }

void start();

protected:
void paintEvent(QPaintEvent *event);

private:
QTimeLine *timeLine;
QBrush startBrush;
};

You’ll notice that we’ve eliminated some of the now needless variables and changed our QColor to a QBrush and our QTimer to a QTimeLine.

Now the changed parts of the source file, first the constructor:
FaderWidget::FaderWidget(QWidget *parent)
: QWidget(parent)
{
if (parent)
startBrush = parent->palette().window();
else
startBrush = Qt::white;

timeLine = new QTimeLine(333, this);
timeLine->setFrameRange(1000, 0);
connect(timeLine, SIGNAL(frameChanged(int)), this, SLOT(update()));

setAttribute(Qt::WA_DeleteOnClose);
resize(parent->size());
}

Here, we create our QTimeLine. QTimeLine is a class introduced in 4.2 that will take a time and a set number of frames and dish them out in regular intervals over that duration to make them appear animated. It helps keep animation constant, dropping frames if things end up getting behind and trying to ensure that an animation only lasts for the time alloted to it.
We set the time to be about a third of a second and give it a thousand frames to draw, starting at 1000 and ending at 0. Obviously, it won’t be drawing all of them in this time frame. We tell the timeline’s frameChanged() signal to trigger an update on the fader widget.

We also try to get the brush for the parent widget’s window role. This is a change from before where we only got the color and not the brush, since we couldn’t trivially alpha blend the an arbitrary pixmap in Qt 4.1.

void FaderWidget::start()
{
timeLine->start();
show();
}

Start remains similar to before, except it only needs to start the timeline.

void FaderWidget::paintEvent(QPaintEvent * /* event */)
{
QPainter painter(this);
qreal frame = timeLine->currentFrame();
painter.setOpacity(frame / 1000.);
painter.fillRect(rect(), startBrush);

if (frame < = 0.)
close();
}

Our paint event has probably changed the most (for the better). Instead of constantly calculating the new alpha color, we simply take the current frame of the timeline and divide it by our total frames, and use that as the opacity value for our QPainter. QPainter::setOpacity() was introduced in Qt 4.2 and sets the opacity for all drawing operations done with that painter. It’s easier than ever to get alpha blending effects with QPainter::setOpacity(). Then we simply fill the entire widget with the brush we got at the beginning.

That’s it! Feel free to make these changes to the code and see it in action. It will look much better than the previous version on platforms that have a pixmap for their window brush (like Mac OS X, XP, and Vista). I included a screen shot of a fade in action here below:

FaderWidget in action

Anyway, this is just an example with what you can do with Qt 4.2, not to mention 4.3. So, take a look at the classes like QTimeLine and new functions like QPainter::setOpacity(), see where you can use them in your existing apps to improve the user experience and make your maintenance easier.

Enjoy!

trenton
Qt
Posted by trenton
 in Qt
 on Thursday, June 21, 2007 @ 09:35

I had the privilege of attending Apple’s World Wide Developer Conference (WWDC) again this year. This is Apple’s annual developer get-together in San Francisco where you can find out about Apple’s future plans for Mac OS X, chat with fellow developers, and avail yourself of all the Apple engineers on-site. This was my fourth year there and I think I’ve gotten the hang of it. This year, however, I (and Trolltech) was in for a nasty surprise.

The previous year, Apple announced what its plans were for Mac OS X 10.5 (or Leopard). One of the new features was that Leopard was going to be 64-bit the entire way through. People keeping score at home should note that the C and C++ libraries were 64-bit in Tiger, but none of the GUI libraries like Carbon or Cocoa. Naturally, we knew that there were lots of people who use Qt to write scientific, visualization, and video applications so it seemed like a good idea to make sure that when Leopard was going to be released in “Spring 2007″ Qt was there to run in 64-bit. We were in pretty fair shape, having already been on the new Carbon technologies introduced in 10.2, but there were still some things that had to be fixed up, and we had to modify the build system, but that’s doable. There were also many bugs in the 64-bit Carbon that we filed bugs against the ones we could get reproducible test cases for. At the end, Qt 4.3.0 was released with the ability to build on Leopard in 32-bit and 64-bit. If you felt plucky enough you could build it all “universal” and have a truly fat binary with versions for PPC, i386, PPC64, and x86_64. This would have been even more impressive, if there was a Leopard that was publicly available so people could take advantage of it.

So, here it was June 2007, we had released Qt 4.3.0, but Apple had delayed Leopard to October. Then, at WWDC, Apple announced that they would not be including HIView and Carbon windows, and other GUI parts of Carbon in 64-bit in their final version of Leopard. This basically contradicts what they said the previous year and makes a fair bit of the work that we did for 64-bit in Qt useless—leaving Qt with a hole for 64-bit support on Mac OS X.

Now, getting news like this hurts on several levels. First, there’s the personal level where there’s the work you’ve put in, re-writing classes, adding all the version branches to make things work (writing an #ifdef 64-bit, 10.4, and 10.3 is a interesting exercise), and getting the build system to work. Then there’s the fact that there’s lots of people who use your library to write amazing applications (I got to see some at WWDC and they were impressive). What can you do for them? Needless to say, it wasn’t the most pleasant information to hear.

The rest of the conference, between attending sessions and talking to Apple engineers, I encountered a lot of Qt developers (either in person or via email). This was really positive. I knew that there were quite a few developers out there using Qt on the Mac, but getting a chance to talk them in person is always great. The big question that most people asked was, “what is Trolltech going to do about 64-bit?” As a developer, I couldn’t really give a definitive answer other than, “I would be surprised if we don’t have some sort of 64-bit solution.” This seemed to ease the fear for these developers and they also seemed to indicate that they were willing to wait a bit for the solution to materialize. As a developer, I can appreciate that response.

Now that I’ve been back in Oslo, I’ve actually had a chance to talk to product management and it seems that we will indeed have that 64-bit solution. The official statement is here. It also includes some Q&A that should cover most concerns.

So, in the future you can expect to see a 64-bit version of Qt using Cocoa under the covers. That is, of course, assuming we still have something like HITheme available to draw our controls. Unfortunately, even now I don’t know what that answer will be (hopefully yes). When we know what APIs are actually available to us, we can start actually making some sort of schedule. Right now, it’s a bit unnerving. If we do get Carbon back in 64-bit, we are in much better shape of course :)

If you feel strongly about this, please don’t hesitate to get ahold of your local Apple contact (whether via WWDR or through the contact information in the link above). We already have, but to Apple, Trolltech is but a pebble in the water, but if all Qt/Mac developers let their voice be heard we are a much stronger force.

trenton
Qt
Posted by trenton
 in Qt
 on Sunday, March 11, 2007 @ 21:39

Well, we are closing in on 4.3 and it looks like it is shaping up to be a good release. Of course, this is what I usually think with every release. Anyway, since I usually talk about “Mac things,” I thought I would take this opportunity to show off something that seems to caused a bit of a local stir at work, Mac OS X unified toolbars.

If you are running Mac OS X 10.4 or higher (Tiger if you think in cats), you have seen that many applications have there toolbars blending right into the title bar. You probably were wondering, “How did they do that?” Probably followed up by a “how can I do that in Qt?”

Well, with 4.2, it was possible to do (though you would have to write a fair amount of code). That’s usually enough to make a programmer reconsider the endeavor. With Qt 4.3, though, we’ve made it fairly easy. Simply create your QMainWindow and toolbars as normal. Then take a look at the QMainWindow::setUnifiedTitleAndToolBarOnMac() property. This will put all the toolbars in the top toolbar area and does the magic to blend the toolbars into the title bar. It’s that simple!

So, how does it look? Well, we added it to Assistant. The before and after picture are below, take a look:

Picture of Qt Assistant from Qt 4.2 with classic toolbars and Qt Assistant in Qt 4.3 with toolbars unified with the title bar

If you want to take a look at this in the snapshots and provide feedback, please do. Don’t report that the window doesn’t stay in the same spot the next time you open the application, though. We are already aware of that issue and are working on it.

trenton
Qt
Posted by trenton
 in Qt
 on Sunday, October 08, 2006 @ 15:47

Now that Qt 4.2 has been out for the past couple of days, I figured it would be
worthwhile to highlight a couple of new features in Qt 4.2. Even though Qt is a
cross-platform toolkit, there are always some new things that are platform
specific.

One thing that may come as a surprise in this version is what isn’t in it. Qt
4.2 has dropped support for Mac OS X 10.2 (Jaguar if you follow the cat names).
The main reason for this was that we just could not support certain things in
10.2 (among them widgets in the menu bar). There were also APIs that we had to
duplicate in order to to get things to work OK in Jaguar (such as an Appearance
Manager-based style and a HITheme-based style, a Quartz2D paintengine and a
QuickDraw paintengine) that made maintenance a bit of a headache. We just
decided that there were diminishing returns (that provided with the fact that
no machines since late 2003 can even run Jaguar) that we figured it was time to
drop support for Jaguar. You can still use Qt 4.1.4 to deploy to Jaguar (and it
works as well), but if you want to use the new features in Qt 4.2, you will
have to target 10.3 (Panther) or higher.

Now that we’ve gotten past all that version number madness, we can focus on
something that is a little more fun. If you ever been programming inside Xcode,
it is kind of convienent to look at the documentation for function inside the
Xcode documentation browser. Of course the Qt documentation isn’t in its index,
so you need some other tool, like Qt Assistant, to read Qt documentation.
However, we’ve changed the documentation tags in Qt 4.2 to allow you to view
the Qt documentation in Xcode. The only problem is that it takes such a long
time to add the documentation to Xcode that we don’t do this automatically.
Here are the extra steps to get the docs into Xcode’s index.

1) Edit Xcode’s documentation index file (/Developer/ADC Reference Library/indexes/MacOSXDeveloper.pbHelpIndexerList on OS X 10.4) to include Qt’s documentation.

2) Run sudo /Developer/Tools/pbhelpindexer to update the index. This is a perl
script that runs through ALL the directories in the array above. This will take
a long time, so find something to do in the meantime.

After the script finishes, open up Xcode and you should find the Qt
documentation in your documentation browser. Here’s a picture that to show off.

Awesome picture of Xcode documentation browser with Qt docs!

There are still a couple of other things that are new in Qt 4.2, but we’ll
leave them around for another time.

trenton
Qt
Posted by trenton
 in Qt
 on Friday, August 04, 2006 @ 20:58

Well, after a more or less quiet week at home in rural Minnesota, I’m off to San Francisco for WWDC to check out all the new stuff that Apple is working on. So, if anyone wants to discuss Qt/Mac or anything else, just track me down, I’ll be in some sort of Trolltech-themed shirt.

Comments Off
trenton
Qt
Posted by trenton
 in Qt
 on Wednesday, December 07, 2005 @ 20:16

OK, many people are starting to wonder about Mac OS X universal binaries. The good news is that you can start playing with universal binaries already with the release candidate for Qt 4.1.0. Here’s the steps, assuming you are on a PPC machine.

configure Qt with these extra flags:

-universal -sdk /path/to/MacOSX10.4u.sdk

After which you can simply build Qt normally. BUT, If you are one of those people who have upgraded to Xcode 2.2, you will have to edit QTDIR/mkspecs/features/mac/sdk.prl to make it look a little more like this:

!isEmpty(QMAKE_MAC_SDK) {
QMAKE_CFLAGS += -isysroot $$QMAKE_MAC_SDK
QMAKE_CXXFLAGS += -isysroot $$QMAKE_MAC_SDK
QMAKE_LFLAGS += -Wl,-syslibroot,$$QMAKE_MAC_SDK
}

This will be fixed for the final Qt 4.1.0 release.

After which, if you want to build your own program as a universal binary add this to your .pro file

QMAKE_MAC_SDK=/path/to/MacOSX10.4u.sdk
CONFIG+=x86 ppc

Afterwards, run ‘file’ on your binary and you should see that you have a PPC and x86 binary.

Congratulations, you just doubled the size of your binary :)