Zambesi : I don't see any place to set the version number (please see picture), can you explain some more, please ?
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).
[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.
[quote author="Smar" date="1281084862"]CMake's syntax is a bit unintuitive and if you need to do anything besides declarations, it gets pretty messy unless you want to put quite a bit time to write modules...
Or that's how I think about it.
Ok, Smar, this is an option form in CMake for build/update translations.
@option (UPDATE_TRANSLATIONS "Update source translation *.ts files (WARNING: make clean will delete the source .ts files! Danger!)")
Try running master: That has a great class browser contributed by Denis Mingulov:-) Unfortunately I do not think that this code can be backported to 2.0/2.1 since it uses the C++ engine which had quite some improvements since the 2.0/2.1 branch was made.
I think that is not the same class browser shown at the link you provided though. So maybe that one was ported to 2.0? I do not know who wrote that plugin, so I can't tell, sorry.
[quote author="DrMaboule" date="1279318875"]I fact you could declare more than one variable using this code:
QObject *pParent = NULL, *pParent2 = NULL; // Two pointer
But is différent from
QObject *pParent = NULL, pParent; // One pointer and a none pointer object.
This is something I don't do anyway. I would call this a code smell on its own.
QObject pParent : The variable is a pointer on a objet of type QObject. QObject is not a class but a pointer on a class. The variable is a pointer, so * should be next the variable.
You are right, QObject* is not a class, but a pointer to a class. But it is atype.
Don't you agreed?
Obviously no, but it is a matter of taste. I'll agree to Tobias Hunger that you should be consistent
to the code at hand and for my code it's T* name
Yeah, I'm voting for leaving two different modes, it makes development and debugging more flexible. I'm thinking that automatic switching should be done to mode that was last. For example, if you were in design view and started debugging than after end of debugging it should switch back to design view. But if you were in edit view, started debugging, manually switched to design view, after it switched back to debug view and finished session than it should switch to design view. Not sure that it is reasonable to switch to such views as project or documentation.