One suggestion: Autocomplete is bound to the keystroke Command+Space. But Command+Space is used by OS X to invoke Spotlight. Ctrl+Period would be a better choice. That is the same keystroke used by Xcode.
With Nokia laying off 7000 people, I have to wonder about the future of Qt.
I have to admit I am worried about this as well.
However Qt was here before Nokia and before this abomination that is Nokia/Microsoft.
For sure not many of those poor 7000 Nokia employees had much to do with Qt.
As Qt is an essential part of the KDE desktop and there are many other companies who have a stake in Qt I believe it will continue as normal.
I'm getting a weird compiler error. When I compile a project that includes a source file that is in the search path instead of in the same directory as the file being compiled I get the error "Object requires at least one PUB block". This happens even if Eliminate Unused SPIN Methods is turned off. If I open the file before compiling, it compiles successfully.
Steve, could you send me the sources of the project, with description where the files are located (this - in project dir, that - in search path, etc)? I suspect the problem is in preprocessor that searches for included objects.
I changed the shortcut bindings under OS X for Autocomplete and Call Tip. I've attached a patch file.
I would prefer to keep shortcuts uniform between platforms. I'm fine with Ctrl+. for completion, but I was thinking about Ctrl+Shift+. and Ctrl+Shift+, for fold/unfold
I can understand wanting shortcuts to be uniform between platforms, but that goal absolutely has to be secondary to being consistent with the platform. Two reasons:
1) When a common shortcut does something unexpected or when an action is assigned to a non-standard shortcut, things that could normally be done automatically suddenly require the user to stop and think about the action. This takes them out of the flow of their actual task (in this case programming). The user experience design should do everything possible to allow the user to focus. Task switching kills focus and productivity.
2) A small number of pzst users will be using it on more than one platform so the benefit of cross-platform consistency is small. Even if someone does use it on multiple platforms, they expect the shortcuts to be consistent with the platform they're on. My fingers know that when I'm running Windows, I use Ctrl+C, Ctrl+X, and Ctrl+V for copy, cut, and paste and that when I'm on the Mac I use Command+C, Command+X, and Command+V. I don't have to think about it. Even if I'm using Windows under Parallels on my Mac. I don't have to give it any thought whatsoever.
Speaking of shortcuts, I think it would be a good idea to assign shortcuts to "Increase Font Size" and "Decrease Font Size" (which on the Mac should be Command+Shift++ and Command+Shift+-). As I learned last night at the propeller meetup it's really handy for presentations.
I added most of the code to implement Increase and Decrease Font Size. It successfully changes the font size in the preferences. The only problem is that I don't know Qt well enough to get the editor window to see the new font size and refresh itself. But I've attached patches anyway. I made a comment at the point where my code stops working.
The simple way would be to use current approach and find all files named "/dev/tty.*" or "/dev/cu.*" - this approach is currently used for both Win32 and POSIX( but with different name pattern). I am aware that this is not very reliable though.
I will now move serial port enumeration routine from preferences dialog to serial port class. Possibly, someone will be able to make enumeration for OS X.
I can work on that. I will have some stumbling blocks since I don't know Qt. For example, how do I tell Qt to link to the IOKit Framework? I can get that sample serial device enumeration code to compile, but it fails at the link phase:
g++ -headerpad_max_install_names -o dirtest main.o -F/Library/Frameworks -L/Library/Frameworks -framework QtCore -L/tmp/qt-stuff-6474/source/qt-everywhere-opensource-src-4.7.0/lib
[COLOR="red"]ld: warning: directory '/tmp/qt-stuff-6474/source/qt-everywhere-opensource-src-4.7.0/lib' following -L not found
Undefined symbols:
"_IOServiceGetMatchingServices", referenced from:
FindModems(unsigned int*)in main.o
"_CFDictionarySetValue", referenced from:
FindModems(unsigned int*)in main.o
"_IOServiceMatching", referenced from:
FindModems(unsigned int*)in main.o
"___CFConstantStringClassReference", referenced from:
cfstring=IORS232SerialStream in main.o
cfstring=IOSerialBSDClientType in main.o
"_kIOMasterPortDefault", referenced from:
FindModems(unsigned int*)in main.o
ld: symbol(s) not found[/COLOR]
I'm not sure what the other two ports are, but I don't think we should restrict the results to tty.usb*. There may be other valid ports.
I'm glad you found that link to the sample code from Apple. That helped me hit the ground running.
One thing you'll need to double-check. I'm not sure if I'm leaking memory in enumeratePorts with the declaration of ports and subsequent assignment to ports.
One thing you'll need to double-check. I'm not sure if I'm leaking memory in enumeratePorts with the declaration of ports and subsequent assignment to ports.
No leak there, that's ok. But there can be another problem though. IOObjectRelease() is called unconditionally. I think tha's not correct, because if either of IOServiceMatching() or IOServiceGetMatchingServices() fails, serialPortIterator will be uninitialized. I think that serialPortIterator should only be released if findSerialPorts() succeeds
No leak there, that's ok. But there can be another problem though. IOObjectRelease() is called unconditionally. I think tha's not correct, because if either of IOServiceMatching() or IOServiceGetMatchingServices() fails, serialPortIterator will be uninitialized. I think that serialPortIterator should only be released if findSerialPorts() succeeds
You're right. I mis-read the Apple sample code. I thought IOServiceGetMatchingServices only got called when IOServiceMatching didn't return NULL. I missed the closing brace amongst the comments. I'll take another look but it might not be for a few days. I have appointments after work Monday and Tuesday.
Those who do not mind compiling PZST themselves, and want to be on the bleeding edge - you may want to subscribe to pzst-announcements Google group. The group is read-only. Repository commit notifications are posted there.
I've modified eserialport_osx.cpp to more closely match Apple's example code. Now matchingServices is always initialized in findSerialPorts so it is always released in enumeratePorts.
Comments
Still working out some issues, but it's running!
http://www.nytimes.com/2011/04/28/technology/28iht-nokia27.html?_r=2
I have to admit I am worried about this as well.
However Qt was here before Nokia and before this abomination that is Nokia/Microsoft.
For sure not many of those poor 7000 Nokia employees had much to do with Qt.
As Qt is an essential part of the KDE desktop and there are many other companies who have a stake in Qt I believe it will continue as normal.
I've attached a zipped screenshot movie to illustrate the problem.
pzst compile error.mov.zip
This compiles just fine, regardless of whether BenkyLCDDriver is open in editor or not. BenkyLCDDriver is in search path
BTW Even if QT dies, at least the current version works well, so do not worry too much about this until something really happens.
I'm not sure what Call Tip does, though. [Edit: I read back through the thread and found the screenshot illustrating Call Tip]
mainwindow.cpp.patch.txt
The third - I do not know, looks like that is from qt's generated makefile
I would prefer to keep shortcuts uniform between platforms. I'm fine with Ctrl+. for completion, but I was thinking about Ctrl+Shift+. and Ctrl+Shift+, for fold/unfold
I can understand wanting shortcuts to be uniform between platforms, but that goal absolutely has to be secondary to being consistent with the platform. Two reasons:
1) When a common shortcut does something unexpected or when an action is assigned to a non-standard shortcut, things that could normally be done automatically suddenly require the user to stop and think about the action. This takes them out of the flow of their actual task (in this case programming). The user experience design should do everything possible to allow the user to focus. Task switching kills focus and productivity.
2) A small number of pzst users will be using it on more than one platform so the benefit of cross-platform consistency is small. Even if someone does use it on multiple platforms, they expect the shortcuts to be consistent with the platform they're on. My fingers know that when I'm running Windows, I use Ctrl+C, Ctrl+X, and Ctrl+V for copy, cut, and paste and that when I'm on the Mac I use Command+C, Command+X, and Command+V. I don't have to think about it. Even if I'm using Windows under Parallels on my Mac. I don't have to give it any thought whatsoever.
Speaking of shortcuts, I think it would be a good idea to assign shortcuts to "Increase Font Size" and "Decrease Font Size" (which on the Mac should be Command+Shift++ and Command+Shift+-). As I learned last night at the propeller meetup it's really handy for presentations.
mainwindow patches.zip
The bad news: pzst doesn't find the Propeller's serial port.
The good news: when I hard-code the name of the serial port, pzst successfully finds and programs the Propeller.
So we just need to figure out a good way to identify the serial ports under OS X. My serial port is named "tty.usbserial-A3001Mq9".
Seems to me, a default serial port name option would sort out platform / port name issues.
I'm not sure I follow. Do you mean the user would have to go to the command line and create a symbolic link to point to the serial port to use?
The correct way is decribed here : http://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/WorkingWSerial/WWSerial_SerialDevs/SerialDevices.html - possibly someone with a Mac could try to implement serial device enumeration using the code from the article.
I added these lines to src.pro:
Here's the code:
eserialport_osx.cpp.zip
I'm not sure what the other two ports are, but I don't think we should restrict the results to tty.usb*. There may be other valid ports.
I'm glad you found that link to the sample code from Apple. That helped me hit the ground running.
One thing you'll need to double-check. I'm not sure if I'm leaking memory in enumeratePorts with the declaration of ports and subsequent assignment to ports.
No leak there, that's ok. But there can be another problem though. IOObjectRelease() is called unconditionally. I think tha's not correct, because if either of IOServiceMatching() or IOServiceGetMatchingServices() fails, serialPortIterator will be uninitialized. I think that serialPortIterator should only be released if findSerialPorts() succeeds
You're right. I mis-read the Apple sample code. I thought IOServiceGetMatchingServices only got called when IOServiceMatching didn't return NULL. I missed the closing brace amongst the comments. I'll take another look but it might not be for a few days. I have appointments after work Monday and Tuesday.
eserialport_osx.cpp.zip
1) version_tpl.h is not found in the PZST-build-desktop/src directory. It is present in my development src directory.
2) The date command in OS X doesn't recognize the --rfc-2822 option
Here is the compiler output. I tried cleaning the project and also deleting the PZST-build-desktop directory (which I assume is the same thing).