| Trolltech Home | Qt4-preview-feedback Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Ran into another one. Just to be clear, I am following the
instructions in ./INSTALL w.r.t. compiling. IE, ./configure followed
by make.
make
g++ -c -pipe -g -Wall -W -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -
DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I../../../mkspecs/macx-g++ -I. -
I../../../include/QtCore -I../../../include/QtCore -I../../../include/
QtGui -I../../../include/QtGui -I../../../include -I.moc/debug-shared -
I.uic/debug-shared -F/Users/dap/proj/qt/qt-mac-cocoa-opensource-
src-4.4.0-alpha1/lib -o .obj/debug-shared/calculator.o calculator.cpp
calculator.h:82: error: ISO C++ forbids declaration of 'Button' with
no type
calculator.h:82: error: expected ';' before '*' token
calculator.h:107: error: ISO C++ forbids declaration of 'Button' with
no type
calculator.h:107: error: expected ';' before '*' token
calculator.cpp: In constructor 'Calculator::Calculator(QWidget*)':
calculator.cpp:81: error: 'digitButtons' was not declared in this scope
calculator.cpp:82: error: 'createButton' was not declared in this scope
calculator.h has:
QT_BEGIN_NAMESPACE
class QLineEdit;
QT_END_NAMESPACE
class Button;
....
private:
//! [1] //! [2]
Button *createButton(const QString &text, const QColor &color,
const char *member);
This is with i686-apple-darwin9-g++-4.0.1.
Prepending 'class ' was needed to disambiguate.
Found the culprit:
# 400 "/System/Library/Frameworks/Carbon.framework/Frameworks/
HIToolbox.framework/Headers/Events.h" 3
extern Boolean
Button(void) ;
Fix: change most of the 'Button' to 'class Button' in the calculator.h
and calculator.cpp, as necessary to get the thing to compile.
Again, I assume these are already noted and fixed. Please point me to
where I can find the rest of them.....
Cheers.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Another one.
demos/macmainwindow/
g++ -c -pipe -Os -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -
D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_SHARED -I../../mkspecs/
macx-g++ -I. -I../../include/QtCore -I../../include/QtCore -I../../
include/QtGui -I../../include/QtGui -I../../include -I.moc/release-
shared -I.uic/debug-shared -F/Users/dap/proj/qt/qt-mac-cocoa-
opensource-src-4.4.0-alpha1/lib -o .obj/release-shared/main.o main.cpp
main.cpp: In constructor 'SearchWidget::SearchWidget(QWidget*)':
main.cpp:83: error: invalid conversion from 'void*' to 'OpaqueMenuRef*'
Issue of MenuRef vs OSMenuRef.
Changed to:
MenuRef macSearchMenu = (OpaqueMenuRef *) searchMenu-
>macMenu(0);
to get it to compile, and then get:
Undefined symbols:
"QMenu::macMenu(void*)", referenced from:
SearchWidget::SearchWidget(QWidget*)in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [macmainwindow.app/Contents/MacOS/macmainwindow] Error 1
So I revert to just // out the macMenu call plus next line.
Sorry if this is all known all ready.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Damon: THANK YOU THANK YOU THANK YOU for posting these reports! I had the same trouble with the Cocoa version; curious that we don't have these errors with the Carbon one, because these compile problems are in top-level demos and examples, not in Qt internals themselves. Anyhow, here is a patch file that should incorporate the fixes that you mentioned:
Attachment:
Attachment:
patch-demos.diff
Attachment:
Attachment:
qt4-mac-port.tbz
Description: Binary data
If I can get a clean compile out of this, then I'll post a MacPorts
port for qt-mac-cocoa-4.4-alpha1 soon!
- boyd
Boyd Waters
Mac Programmer Person
National Radio Astronomy Observatory
Socorro, New Mexico
http://www.aoc.nrao.edu/~bwaters
Message 4 in thread
On Apr 3, 2008, at 5:45 PM, Damon Permezel wrote:
> qtdemo was completely unusable.
> The selected left hand menu button, for example, did not match where
> the mouse pointer was. Clicking on the mouse button did not bring
> up anything else.
I get that, too; notice that the highlighted thing is *opposite* of
what it should be; this is some weird array-indexing problem where
it's going the wrong way through the controls.
FWIW, it just happens that at the OpenGL demo, the mouse pointer and
the highlight are over the same button, so the OpenGL stuff launches
just fine.
Also note that - for legacy reasons, I suppose - all demos and
examples are linked against the Carbon framework. I tried some of the
tools, re-linking them *without* Carbon, and they still worked. So a
spec file needs updating somewhere.
> I also disabled the qt-mac port version because I could find no
> qtdemo anywhere.
I believe that stock MacPorts is going to install the Qt demos in /
Applications/MacPorts, but I'm not certain. I modified my MacPorts
settings so that applications are installed in ${prefix}/Applications,
which by default would be /opt/local/Applications.
It works fine.
The patch I posted earlier does not quite work, a newer patch is
included in this MacPorts port:
Description: Binary data
I used Apple's GCC 4.2.1 to compile Qt on my Core (NOT Core2) Intel
laptop.
Tomorrow I'll try a 64-bit build on the Mac Pro...
Message 5 in thread
Hi guys.
I think the problem is that the macwindows demo probably shouldn't have
been built since it's based heavily on Carbon stuff and not ready for
Cocoa at all.
Anyway glad that they were sorted out. We will try to make sure
everything compiles in both 64- and 32-bit for the next release.
Promise :-)
On 2008-04-04 02:53:12 +0200, Boyd Waters <bwaters@xxxxxxxx> said:
>
>
>
> On Apr 3, 2008, at 5:45 PM, Damon Permezel wrote:
>
>> qtdemo was completely unusable.
>> The selected left hand menu button, for example, did not match where
>> the mouse pointer was. Clicking on the mouse button did not bring
>> up anything else.
>
>
> I get that, too; notice that the highlighted thing is *opposite* of
> what it should be; this is some weird array-indexing problem where
> it's going the wrong way through the controls.
>
> FWIW, it just happens that at the OpenGL demo, the mouse pointer and
> the highlight are over the same button, so the OpenGL stuff launches
> just fine.
This is a known issue in the current alpha, when dispatching mouse
events, the global pos is in the "Cocoa" coordinates which has (0, 0)
at the bottom left instead of top left.
>
>
> Also note that - for legacy reasons, I suppose - all demos and
> examples are linked against the Carbon framework. I tried some of the
> tools, re-linking them *without* Carbon, and they still worked. So a
> spec file needs updating somewhere.
Probably. We were most focused on making the libraries working than
fixing all the examples.
Thanks for the feedback,
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 6 in thread
On Apr 4, 2008, at 6:32 AM, Trenton Schulz wrote:
> I think the problem is that the macwindows demo probably shouldn't
> have been built since it's based heavily on Carbon stuff and not
> ready for Cocoa at all.
Still, it's a damn fine example so please keep it in there or Cocoa-
ify it!
>> I get that, too; notice that the highlighted thing is *opposite* of
>> what it should be; this is some weird array-indexing problem where
>> it's going the wrong way through the controls.
>
>
> This is a known issue in the current alpha, when dispatching mouse
> events, the global pos is in the "Cocoa" coordinates which has (0,
> 0) at the bottom left instead of top left.
Ahh, yes... good old Display Postscript!
From the "View Programming Guide for Cocoa":
> Specifying that a view subclass uses a flipped coordinate system is
> done by overriding the isFlipped method. The default implementation
> of NSView returns NO, which means that the origin of the coordinate
> system lies at the lower-left corner of the default bounds
> rectangle, and the y-axis runs from bottom to top. When a subclass
> overrides this method to returnYES, the view machinery automatically
> adjusts itself to assume that the upper-left corner is the origin.
And
> QWidget::winId() will return an NSView pointer
Hmm...
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 7 in thread
>> This is a known issue in the current alpha, when dispatching mouse
>> events, the global pos is in the "Cocoa" coordinates which has (0,
>> 0) at the bottom left instead of top left.
>
>
> Ahh, yes... good old Display Postscript!
>
> From the "View Programming Guide for Cocoa":
>> Specifying that a view subclass uses a flipped coordinate system is
>> done by overriding the isFlipped method. The default implementation
>> of NSView returns NO, which means that the origin of the coordinate
>> system lies at the lower-left corner of the default bounds
>> rectangle, and the y-axis runs from bottom to top. When a subclass
>> overrides this method to returnYES, the view machinery
>> automatically adjusts itself to assume that the upper-left corner
>> is the origin.
Oh, I see..
in src/gui/kernel/qcocoaview.mm
you already have
> - (BOOL)isFlipped;
> {
> return YES;
> }
So how should we work around the mouse-event reporting problem, I'm
still thinking about it...
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 8 in thread
On 2008-04-04 20:23:47 +0200, Boyd Waters <bwaters@xxxxxxxx> said:
>>> This is a known issue in the current alpha, when dispatching mouse
>>> events, the global pos is in the "Cocoa" coordinates which has (0, 0)
>>> at the bottom left instead of top left.
>>
>>
>> Ahh, yes... good old Display Postscript!
>>
>> From the "View Programming Guide for Cocoa":
>>> Specifying that a view subclass uses a flipped coordinate system is
>>> done by overriding the isFlipped method. The default implementation of
>>> NSView returns NO, which means that the origin of the coordinate
>>> system lies at the lower-left corner of the default bounds rectangle,
>>> and the y-axis runs from bottom to top. When a subclass overrides this
>>> method to returnYES, the view machinery automatically adjusts itself
>>> to assume that the upper-left corner is the origin.
>
>
> Oh, I see..
>
> in src/gui/kernel/qcocoaview.mm
>
>
> you already have
>
>> - (BOOL)isFlipped;
>> {
>> return YES;
>> }
>
>
> So how should we work around the mouse-event reporting problem, I'm
> still thinking about it...
As I said, the problem was the global coordinates. The local
coordinates should be OK. At least they are when I try things here.
Anyway, it should be in better shape for the next beta, and hopefully
I'll get to that after finishing up some things with 4.4.
Hope this helps,
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 9 in thread
Could you talk more about the QMouseEvent::hasExtendedInfo() method?
Ref: http://doc.trolltech.com/4.4rc1/qmouseevent.html#hasExtendedInfo
The Qt 4.4 RC1 documentation mentions it, but the description block is
empty.
What is extended info? And if the mouse event has it, how does one get
it (e.g. there is no getExtendedInfo())?
Is this related to some improved integration with tablets?
Thanks,
Yvon
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 10 in thread
On 2008-04-04 20:20:21 +0200, Boyd Waters <bwaters@xxxxxxxx> said:
>
> On Apr 4, 2008, at 6:32 AM, Trenton Schulz wrote:
>
>> I think the problem is that the macwindows demo probably shouldn't
>> have been built since it's based heavily on Carbon stuff and not ready
>> for Cocoa at all.
>
>
>
> Still, it's a damn fine example so please keep it in there or Cocoa- ify it!
We'll decide what to do this eventually, don't worry. Fixing that
example isn't at the top of our priorities at the moment.
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx