Qt Creator and other tools

Two ways:

promotion (the easy one, you won't see any graphical difference between your custom widget and the parent one, cause it "promises" you only the fact that setupUi method will create a widget of your custom type, and not the original one). In this case, just right-click on your widget, promote it, give your .h header file and the type of your custom widget.

writing a component for Qt designer (the long one). In this case, refer to Qt documentation, just look for "Creating Custom Widgets for Qt Designer" in Qt Assistant, or have a look to this example: "Custom Widget Plugin Example":http://doc.trolltech.com/4.6/designer-customwidgetplugin.html

Tony.

Okay, that's great.

Thanks guys for such a fast response.

See "QTBUG-7777":http://bugreports.qt.nokia.com/browse/QTBUG-7777. It is planned for 4.8

[ Turned URL into a link, tobias ]

This is best diagnosed by trying to run 'git pull' from the command line (cmd.exe, emulating Qt Creator calling).
A common pitfall in an installation with msysGit 1.7.X configured with 'git bash' only is that git relies on the environment variable HOME being set in order to locate the SSH key files.
bash does that, but for cmd.exe and Qt Creator executing git, it is not set and git then defaults to its installation directory to find the keys.
As a workaround, HOME can be set to %HOMEDRIVE%/%HOMEPATH% in the Windows environment. Qt Creator 2.1 will contain a setting to optionally do this when running git.

Ok, I didn't read that it's not supported with linux.
Maybe, I will give the remote service a try..

Thank you for your help!

Thanks Tobias!

You've been a great help!

Even better:-)

i'm getting the code from master now ;-)

You could still consider it. CDB is pretty slow when you have debugging helpers enabled...

if you are doing like @qsTr("some string")@ in your qml and running @lupdate someqmlscript.qs -ts someqmlscript_en.tr@ it should be working I believe.

It depends on how you set up your build environment:-)

The system environment should be identical to your environment outside creator, but the clean environment should be just the bare minimum.

Of course Creator does tweak both environments for the tools it is going to use, so the system environment might be a bit different from the one seen in your shell.

[quote author="kimf" date="1282680414"]

Zambesi : I don't see any place to set the version number (please see picture), can you explain some more, please ?

[/quote]

Whoops, looks like Creator 2.0 hardcodes the version number. Sorry about that, it's not so easy to keep track of when what feature was added. Anyway, Creator 2.0.1, which is coming very soon, will let you set the package version. (It's mostly a bugfix release, but it has some new features as well).

Great that creator works for you!

Source packages are listed "here":http://qt.nokia.com/developer/eclipse-integration/.

Ah....fair enough!

[quote author="Tobias Hunger" date="1281783078"]How should we handle mode switching? Should each creator window have its own mode (currently creator is based on the assumption that only one mode is active at any time)?[/quote]

That would actually be nice. In this scenario, one could edit the forms and the code at the same time. It would be nice to be able to graphically reference the names of your widgets as you write control code for them.

[quote]We like to have creator fully usable with just the keyboard, and we really want to keep it this way. So how is the user supposed to switch between multiple creator windows? Is it enough to rely on the OS-provided window-switching behavior or do we need to do something more tailored to the creator use-cases?[/quote]

I think you have to rely on the operating system's window management at some point. It really doesn't make sense to have this window switching behavior controlled by the client. Otherwise, the use would probably be surprised that their alt-tab (or equivalent) OS window control doesn't work. I don't really know how the QtCreator use-cases handle behavior for windows that are minimized or in the background. However, I think you must let the window manager have as much control as it would of any other program

[quote]Where should newly opened editors appear? What should happen when a file is already open in an editor in another window? Should that window then become active to show the file? Is that the right thing to do when that window is obscured/minimized? Should we raise/un-minimize it then or is that too distracting?[/quote]

Other multi-window editors I have used update inactive windows with changes made to the active window. I don't know if this is preferable, but if an inactive window shares a document with an active window, the inactive window should be updated with changes made in the active window when it becomes active.

You're right, there are some tricky use-cases here. However, I really see this feature as very important in making QtCreator competetive with other, more established IDEs.

Thanks for responding!

cool :)

I finally found it, you need to add $(QTDIR)\src to your Tools->Options->Projects and Solutions->VC++ Directories->Source files.

IIRC MinGW isn’t anymore supplied when you don’t install full SDK, which is atleast for me the preferred way(I need/want newest GCC anyway)

chetankjain: Thanks:-)