qtcsharp-list Mailing List for Qt#
Status: Inactive
Brought to you by:
manyoso
Menu
▾
▴
qtcsharp-list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(6) |
Jun
(22) |
Jul
(35) |
Aug
(48) |
Sep
(96) |
Oct
(58) |
Nov
(81) |
Dec
(59) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(60) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marcus <ma...@my...> - 2003-01-28 08:22:17
|
As I've discussed with Adam, I think that we should change our handling of=
=20
some of the classes in Qt#, particularly the implicitly-shared classes:=20
QBitmap, QBrush, QCursor, QFont, QFontInfo, QFontMetrics, QIconSet, QMap,=20
QPalette, QPen, QPicture, QPixmap, QRegion, QRegExp, QString, QStringList,=
=20
QValueList, and QValueStack.
Of these classes, I've worked most closely with QString, but the other clas=
ses=20
are similar. In each QString instance, one of the fields has type QStringDa=
ta=20
and is named "d". This appears to be a common idiom in C++ -- a d-pointer. =
In=20
any case, the "real" string data of a QString is contained in the d field.=
=20
The QStringData is reference-counted and implicitly-shared. When a QString =
is=20
initially created, its d-pointer is created with the real string data. When=
=20
copying a QString, a new QString is created, but the new QString's d-pointe=
r=20
points to the same data as the origin QString. So the data is shared. QStri=
ng=20
also features copy-on-write so that any QString methods that would alter th=
e=20
d-data cause that data to be copied into a new d-pointer, hence "detached."=
=20
The destructor for QString decrements the reference count. When the referen=
ce=20
count for the QStringData reaches 0, the "real" string data is deleted.
=46rom the Qt# perspective, whenever we create a QString, we are also creat=
ing a=20
new instance of a d-pointer that contains the actual string data. Many=20
methods in Qt# will pass the data to Qt functions. Some Qt functions will=20
retain a copy of the data, using the copy constructor. So the actual data o=
f=20
the string will remain allocated as locate as *any* QString instance needs=
=20
it. The Qt# finalizer ("destructor") for QString can safely delete the=20
QString instance because of this implicit sharing. For it any Qt class stil=
l=20
retains a copy of the QString, the actual string data will be retained as=20
needed. On the other hand, if no copy of the string data is needed, Qt will=
=20
delete the underlying data, thus returning the memory to the feel pool.
|
|
From: Pedro A. S. <ped...@ya...> - 2003-01-26 21:08:44
|
Thank you for the fast fix. I have not tested yet the cvs, but I have
connected the signals and slots by hand and it works now. I prefer this
solution until the next version of Qt# is released, to make easy for the
people to try SkyNET.
El dom, 26-01-2003 a las 09:00, Marcus escribió:
> First, the code that you mentioned in the original post should now work. In
> turns out that there is also a work-around. When you specify a non-null
> "receiver" and "slot" when creating a QToolButton, the constructor actually
> just makes the connection
>
> Connect( toolButton, SIGNAL("clicked()"), receiver, slot)
>
> which is exactly how I did it in the C# version of the constructor.
>
> I'm attaching a copy of a small program that shows how to connect everything
> up.
>
> By the way, QMainWindow already provides a QMenuBar, which you can retrieve
> using the MenuBar() method. You might want to make your file menu
> (QPopupMenu) a child of MenuBar() instead of creating a new menu bar. Until
> recently, the MenuBar() method was broken...
>
> On Saturday 25 January 2003 04:46 pm, Pedro Abelleira Seco wrote:
> > I have added a Qt# frontend to my app SkyNET (sky-net.sourceforge.net)
> > this weekend. All was surprisingly smoothly, but I have found a problem.
> > Qt# is founding my slots in the menubar, but not in the toolbar. I'm not
> > a Qt/KDE developer, so the problem could well be plain ignorance. The
> > code:
--
Pedro Abelleira Seco <ped...@ya...>
___________________________________________________
Yahoo! Mes
Personaliza tu m con tu logo y melodfavorito
en http://moviles.yahoo.es
|
|
From: Marcus <ma...@my...> - 2003-01-26 08:00:03
|
First, the code that you mentioned in the original post should now work. In
turns out that there is also a work-around. When you specify a non-null
"receiver" and "slot" when creating a QToolButton, the constructor actually
just makes the connection
Connect( toolButton, SIGNAL("clicked()"), receiver, slot)
which is exactly how I did it in the C# version of the constructor.
I'm attaching a copy of a small program that shows how to connect everything
up.
By the way, QMainWindow already provides a QMenuBar, which you can retrieve
using the MenuBar() method. You might want to make your file menu
(QPopupMenu) a child of MenuBar() instead of creating a new menu bar. Until
recently, the MenuBar() method was broken...
On Saturday 25 January 2003 04:46 pm, Pedro Abelleira Seco wrote:
> I have added a Qt# frontend to my app SkyNET (sky-net.sourceforge.net)
> this weekend. All was surprisingly smoothly, but I have found a problem.
> Qt# is founding my slots in the menubar, but not in the toolbar. I'm not
> a Qt/KDE developer, so the problem could well be plain ignorance. The
> code:
|
|
From: Marcus <ma...@my...> - 2003-01-26 06:57:59
|
I've looked into why connecting slots in a QToolBar does not work. Connecting QToolButtons to custom slots is not implemented in the current code. (Connecting to built-in slots should work, but that would not generally be useful.) Special handling is needed to connect to a C# slot, and the generated version of QToolBar lacks that code. I will work on it and let you know when I get it working. On Saturday 25 January 2003 04:46 pm, Pedro Abelleira Seco wrote: > I have added a Qt# frontend to my app SkyNET (sky-net.sourceforge.net) > this weekend. All was surprisingly smoothly, but I have found a problem. > Qt# is founding my slots in the menubar, but not in the toolbar. I'm not > a Qt/KDE developer, so the problem could well be plain ignorance. The > code: |
|
From: Adam T. <ma...@ya...> - 2003-01-26 04:16:26
|
On Saturday 25 January 2003 08:40 pm, Ashley Winters wrote: > --- Germain Garand <ge...@eb...> wrote: > This all stems from the fact that connect() isn't virtual, and the > meta-object interface has no friendly introspective wrapper class we > can all use like happy lemmings. Here's waiting for Qt-4.x... > > Okay, I'm not actually ticked about it, since PerlQt-3's ugly, > disgusting hack doesn't suffer from those problems. :) We do the same thing with signal/slots (a bunch of proxy slots for each signature) and have been looking for a better way. The ideal solution for us would be a Connect method that took a function pointer as the slot. Do you know if TT is working on a introspective wrapper or some other tool for the bindings in Qt-4.x? If not then maybe we can ask in unison and see what they say ;) |
|
From: Adam T. <ma...@ya...> - 2003-01-26 02:56:26
|
On Saturday 25 January 2003 05:46 pm, Pedro Abelleira Seco wrote: > Hi, list > > I have added a Qt# frontend to my app SkyNET (sky-net.sourceforge.net) > this weekend. All was surprisingly smoothly, but I have found a problem. > Qt# is founding my slots in the menubar, but not in the toolbar. I'm not > a Qt/KDE developer, so the problem could well be plain ignorance. The > code: I'll have a look at the QToolBar/slot problem. Very cool application Pedro! I put up a screenshot and a news blurb on the site :) http://qtcsharp.sourceforge.net/ http://qtcsharp.sourceforge.net/screen/skynet-0.6.png Cheers, Adam > > BTW I'm uploading a qt# screenshot of my app. I'm releasing version > 0.0.5 with both qt and gtk support this weekend. > Oh! and the code is horrible, but I only want to have a working gtk, qt > and SWF working asap and concentrate in core functionality then. If you > have suggestions, comments or patches they'll be much appreciated. THe best suggestion is to use the QCanvas* classes. I think this will speed up the app quite a bit. Currently it is repainting the entire buffer and causing flicker. I'm not sure why or what you've done, but the qfractals/scribblewindow do not have this flicker. Thanks for the work though! |
|
From: Adam T. <ma...@ya...> - 2003-01-25 22:55:27
|
On Saturday 25 January 2003 03:11 am, Marcus wrote: > Are there any new features we would like to add to QTSHARP-0_6_BRANCH right > now? I've been using this as a testing area for new ideas, for example, > with unicode support and with changing the memory management for QString. I > want to use similar memory management with the other implicitly-shared > classes as well. I'm thinking about trying to make the the Qt collection > classes work, if it's not too big of undertaking. > > Any other ideas? Any conclusions with the OpenGL bindings? BTW, Jowenn said that uicsharp is working with the latest version of Mono .19 though I don't know how they'd fair with pnet. I am going to convert the libqtsharp build in BRANCH to use qmake I think ... still many problems from people with that... Adam |
|
From: Pedro A. S. <ped...@ya...> - 2003-01-25 22:46:06
|
Hi, list I have added a Qt# frontend to my app SkyNET (sky-net.sourceforge.net) this weekend. All was surprisingly smoothly, but I have found a problem. Qt# is founding my slots in the menubar, but not in the toolbar. I'm not a Qt/KDE developer, so the problem could well be plain ignorance. The code: //Setup the filemenu filemenu = new QPopupMenu (null, "filemenu"); filemenu.InsertItem("&Zoom+", this, SLOT("SlotZoomp()")); //Setup the menubar menubar = new QMenuBar (this, ""); menubar.InsertItem ("&File", filemenu); // Setup the toolbar toolbar = new QToolBar (this, ""); QPixmap zoompIcon = new QPixmap(); zoompIcon.Load("viewmag+.png", "", 0); bt = new QToolButton(new QIconSet(zoompIcon), "Zoom+", "", this, SLOT ("SlotZoomP()"), toolbar, ""); when I run the app the slots are correctly invoked from the menubar but I get: QObject::connect: No such slot QMainWindow::SlotZoomp() QObject::connect: (sender name: '') QObject::connect: (receiver name: 'main') I don't know why it searches QMainWindow. Could you help me? Thanks a lot. BTW I'm uploading a qt# screenshot of my app. I'm releasing version 0.0.5 with both qt and gtk support this weekend. Oh! and the code is horrible, but I only want to have a working gtk, qt and SWF working asap and concentrate in core functionality then. If you have suggestions, comments or patches they'll be much appreciated. -- Pedro Abelleira Seco <ped...@ya...> ___________________________________________________ Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito en http://moviles.yahoo.es |
|
From: Marcus <ma...@my...> - 2003-01-25 08:11:02
|
Are there any new features we would like to add to QTSHARP-0_6_BRANCH right now? I've been using this as a testing area for new ideas, for example, with unicode support and with changing the memory management for QString. I want to use similar memory management with the other implicitly-shared classes as well. I'm thinking about trying to make the the Qt collection classes work, if it's not too big of undertaking. Any other ideas? |
|
From: <mu...@my...> - 2003-01-23 10:24:12
|
I've added support for unicode in QString now. I hacked on the generator to make prevent it from converting QStrings to strings. I tried ripping out all the QString code, but it didn't seem to act right, so I had to play around until I got things working right. I'll try to make it a little more elegant soon, but it doesn't appear that I broken anyway with these changes. The examples still work fine. The major changes are * Where the C++ Qt function takes a QString, so does the C# function. * There are implicit conversions between string and QString, which is mostly useful when creating new widgets. * QString no longer needs to implement IDisposible, and QtSupport does not need to track them because they are implicitly shared and reference counted. The actual string it not deleted until the reference count reaches. So if we create a QString in Qt# code, we have 1 reference to it. When we pass it to a QPushButton, Qt can make a copy of it. If the C# QString object is eligible for garbage collection, the C# finalizer will call qt_del_QString, which deletes our reference to the string and lowers the reference count by one. (If there are no other copies of the QString, Qt may delete it at this point.) |
|
From: Marcus <ma...@my...> - 2003-01-20 23:25:30
|
Yeah. Ashley's stuff is written in Perl, which is mostly incomprehensible, so I'm writing something in C# to do the same thing. On Monday 20 January 2003 05:02 pm, Patrick Hartling wrote: > Adam, > I do have some patches to the existing parser, but after reading through > the archives of the kde-bindings list, it seems that it might not be > worth the effort to hack away on it. It appears that Ashley has already > done quite a lot (in quite a short time!) towards using gcc's > -fdump-translation-unit option. I can definitely say that implementing a > full C++ parser is probably too much effort. |
|
From: Patrick H. <pa...@vr...> - 2003-01-20 23:02:01
|
Adam, I do have some patches to the existing parser, but after reading through the archives of the kde-bindings list, it seems that it might not be worth the effort to hack away on it. It appears that Ashley has already done quite a lot (in quite a short time!) towards using gcc's -fdump-translation-unit option. I can definitely say that implementing a full C++ parser is probably too much effort. -Patrick Adam Treat wrote: > Hello Patrick, > > On Saturday 18 January 2003 05:18 pm, Patrick Hartling wrote: > >>Yeterday, I ran across the work being done on binge to automate the >>generation of C# bindings for Qt. It looks like exactly what I need to >>allow the use of roughly 350 C++ classes with the .NET languages. I am >>quite anxious to put binge to use if I can. >> >>I have checked out the current Qt# source from CVS, but I am finding >>that the parser tool for generating an XML API file has some limitations >>when there are method implementations inlined in class declarations. Is >>there any other tool for generating these API files? If not, is there >>any interest in patches to extend the capabilities of the parser >>utility, or should I just hack together some preprocessing scripts for >>my own use? I'm fairly new to C#, but I think I could probably take a >>stab at making additions to the parser. > > > We would gladly accept any patches to improve the parser. That being said, we > are considering a move away from the parser and towards an application that > would modify and XML'ify the output of gcc's -f-dump option. Work on this > has already begun and you can read about it on the kdebindings list as well > as here. > > We are considering this shift because our Parser is reaching the maximum of > it's capabilities without a major rewrite which would parse a more complete > set of the C++ syntax. Using gcc has the advantage because it can already > parse the full range of C++ syntax. You should speak with Marcus and Ashley > about this as they are kind of the experts on the parsing options. > > We would also gladly accept patches and improvements to binge proper if you > create them. Am going to forward to the kdebindings list. I would encourage > you to drop by our IRC chat room and hopefully catch one of us when we are > around so we can discuss further. > > IRC channel #qtsharp on Freenode.net > > Cheers, > > Adam > > PS: If it would make sense and people are interested perhaps we can create > #kde-bindings on freenode.net and move the #qtsharp discussion over there if > the other kdebindings developers are interested... > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will > allow you to extend the highest allowed 128 bit encryption to all your > clients even if they use browsers that are limited to 40 bit encryption. > Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > _______________________________________________ > Qtcsharp-list mailing list > Qtc...@li... > https://lists.sourceforge.net/lists/listinfo/qtcsharp-list -- Patrick L. Hartling | Research Assistant, VRAC pa...@vr... | 2624 Howe Hall: 1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ |
|
From: Adam T. <ma...@ya...> - 2003-01-20 06:40:32
|
Hello everyone, Here is the my prototype for the new SIGNAL/SLOT implementation. This consists of two files: SigSlots.cs and test.cs I've commented both pretty heavily to show everything that is going on and what is/isn't allowed. It is almost feature complete aside from the lack of native signals/slots, but that is an implementation detail and will not affect the public API. Please, have a look and let me know what you think ... flames, comments or praise ;) Cheers, Adam |
|
From: Kai R. <kai...@ud...> - 2003-01-19 13:41:25
|
Hi !
All the QGL* (opengl) classes are missing.
Marcus Urban give me the tipp, that those wrapper classes are still in the
sources, so I added them to the
qtsharp-0.6/src/bindings/qt.build file.
But they don't compile :-(
Building target `all' for project `Qt#'
/usr/bin/mcs --target library -o ./Qt.dll -nowarn:0108 -nowarn:0114
...
./QWheelEvent.cs ./QWidget.cs ./QWidgetFactory.cs ./QWidgetItem.cs
./QWidgetList.cs ./QWidgetListIt.cs ./QWidgetPlugin.cs ./QWidgetStack.cs
./QWindowsMime.cs ./QWindowsStyle.cs ./QWizard.cs ./QWorkspace.cs
./QXmlAttributes.cs ./QXmlContentHandler.cs ./QXmlDTDHandler.cs
./QXmlDeclHandler.cs ./QXmlDefaultHandler.cs ./QXmlEntityResolver.cs
./QXmlErrorHandler.cs ./QXmlInputSource.cs ./QXmlLexicalHandler.cs
...
./QGLWidget.cs(39) error CS0103: The name `Connect' could not be found in
`Qt.QGLWidget'
./QGLWidget.cs(52) error CS0103: The name `Connect' could not be found in
`Qt.QGLWidget'
GC Warning: Repeated allocation of very large block (appr. size 380928):
May lead to memory leak and poor performance.
Compilation failed: 2 error(s), 0 warnings
*** Target `all' for project `Qt#' failed ***
*** Project `Qt#' build failed ***
Command exited with non-zero status 1
73.87user 1.09system 1:22.38elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1382major+34764minor)pagefaults 0swaps
make[2]: *** [Qt.dll] Error 1
It would be great, if those classes work, so that I can port my qt-opengl
projects to qt#.
Greetings,
Kai Reichert
|
|
From: Marcus <ma...@my...> - 2003-01-19 07:33:06
|
I've spent some time lately looking through Qt's documentation and source code to see if we can come up with a cleaner way to implement signals and slots. Adam really wanted to avoid having all the custom prototypes for each slot type. What we really need is to something akin to Connect( QObject* sender, const char* signalName, QObject* receiver, void* slotFunction ) The problem is that Qt goes to great lengths to allow the user to specify the slot as a string (char*) rather than a function pointer. Qt uses moc to create data structures at compile time to map between signal/slot names are methods. Unfortunately, these data structures are not officially sanctioned by TrollTech. So far I have not found a simple way to achieve what we want without either using undocumented functions. By "undocumented" functions, I mean functions that are not listed in the for the classes in $QTDIR/doc/html. I will continue to look for something, but I'm not sure that I will find it. I have even looked at PyQt to see how they handle this, and it appears that they do something similar to what we are currently doing. We can probably clean the code up a bit, but unless we are willing to use some gray-area functionality of Qt, we might have to retain the current approach. I wil conitnue looking, but it would like some feedback. |
|
From: Adam T. <ma...@ya...> - 2003-01-18 23:51:52
|
Hello Patrick, On Saturday 18 January 2003 05:18 pm, Patrick Hartling wrote: > Yeterday, I ran across the work being done on binge to automate the > generation of C# bindings for Qt. It looks like exactly what I need to > allow the use of roughly 350 C++ classes with the .NET languages. I am > quite anxious to put binge to use if I can. > > I have checked out the current Qt# source from CVS, but I am finding > that the parser tool for generating an XML API file has some limitations > when there are method implementations inlined in class declarations. Is > there any other tool for generating these API files? If not, is there > any interest in patches to extend the capabilities of the parser > utility, or should I just hack together some preprocessing scripts for > my own use? I'm fairly new to C#, but I think I could probably take a > stab at making additions to the parser. We would gladly accept any patches to improve the parser. That being said, we are considering a move away from the parser and towards an application that would modify and XML'ify the output of gcc's -f-dump option. Work on this has already begun and you can read about it on the kdebindings list as well as here. We are considering this shift because our Parser is reaching the maximum of it's capabilities without a major rewrite which would parse a more complete set of the C++ syntax. Using gcc has the advantage because it can already parse the full range of C++ syntax. You should speak with Marcus and Ashley about this as they are kind of the experts on the parsing options. We would also gladly accept patches and improvements to binge proper if you create them. Am going to forward to the kdebindings list. I would encourage you to drop by our IRC chat room and hopefully catch one of us when we are around so we can discuss further. IRC channel #qtsharp on Freenode.net Cheers, Adam PS: If it would make sense and people are interested perhaps we can create #kde-bindings on freenode.net and move the #qtsharp discussion over there if the other kdebindings developers are interested... |
|
From: Patrick H. <pa...@vr...> - 2003-01-18 22:19:36
|
Yeterday, I ran across the work being done on binge to automate the generation of C# bindings for Qt. It looks like exactly what I need to allow the use of roughly 350 C++ classes with the .NET languages. I am quite anxious to put binge to use if I can. I have checked out the current Qt# source from CVS, but I am finding that the parser tool for generating an XML API file has some limitations when there are method implementations inlined in class declarations. Is there any other tool for generating these API files? If not, is there any interest in patches to extend the capabilities of the parser utility, or should I just hack together some preprocessing scripts for my own use? I'm fairly new to C#, but I think I could probably take a stab at making additions to the parser. -Patrick -- Patrick L. Hartling | Research Assistant, VRAC pa...@vr... | 2624 Howe Hall: 1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ |
|
From: Adam T. <ma...@ya...> - 2003-01-18 17:07:24
|
On Saturday 18 January 2003 07:04 am, Adam Treat wrote:
> On Saturday 18 January 2003 05:50 am, Marcus wrote:
> > Okay. By the way, I think might we still have some problems, but Paolo
> > was around a while ago, and we did find one thing that is a bug in mono.
> > I changed hello.cs further so that the constructor just created a
> > QPushButton with no label or anything, i.e. QPushButton(null), and ilrun
> > wasn't crashing but mono was.
> >
> > If you want to fix it, change line 2186 in marshal.c to
> >
> > if (t->data.klass && t->data.klass->delegate) {
> >
> > Paolo said that he would fix it properly (presumably in CVS) later today.
>
> Oh thanks for finding this!
>
> > Also, I noticed that you were passing "this" pointers into C++ functions.
> > You probably know this already, but you really aren't supposed to do
> > that. The addresses of managed objects can move, so you should store a
> > GCHandleRef instead. (It's explicitly convertible to an IntPtr.)
>
> Actually, 'this' is implicitly converted to a GCHandle and then returned
> as an IntPtr. I know, I know, implicit conversion isn't the way togo I was
> just doing it temporarily ... i'll set it up so that is uses
> ICustomMarshaller today...
>
> _If_ we have an implicit conversion of a QtSharp object to an IntPtr it
> should probably be to the QtSharp.RawObject ...
|
|
From: Adam T. <ma...@ya...> - 2003-01-18 17:07:09
|
On Saturday 18 January 2003 07:05 am, Adam Treat wrote:
> Sorry, I made all of those changes you were speaking of and forgot to
> commit last night ;) I'll commit them today and install csc...
>
> On Saturday 18 January 2003 05:00 am, Marcus wrote:
> > I have to make some changes to the QApplication.cs's constructor because
> > of the int& argc parameter in new_QApplication0. Since argc is passed by
> > reference in C++, the P/Invoke signature needs to be "ref int". Also, I
> > had to create a temporary variable
> >
> > int length = args.Length
> >
> > since you can't you can't write "ref args.Length" because you can't
> > assign to args.Length (in C terms, it's not an lvalue).
> >
> > Mono is still totally unhappy about this program. ilrun gets a little
> > further -- far enough to produce this when I run it under gdb:
> >
> > marcus@linux:~/src/QTSHARP-HEAD/qtsharp> gdb /usr/local/bin/ilrun
> >
> > (gdb) r hello.exe
> > Starting program: /usr/local/bin/ilrun hello.exe
> > [New Thread 1024 (LWP 10707)]
> > qApp
> > Qt: gdb: -nograb added to command-line options.
> > Use the -dograb option to enforce grabbing.
> > HelloWorld
> > Qt.QString
> > Qt.QPushButton
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1024 (LWP 10707)]
> > 0x409db2da in QString::unicode() const (this=0x8130ed4)
> > at ../include/qstring.h:597
> > 597 const QChar* unicode() const { return d->unicode; }
> > Current language: auto; currently c++
> > (gdb) bt
> > #0 0x409db2da in QString::unicode() const (this=0x8130ed4)
> > at ../include/qstring.h:597
> > #1 0x40dd5cac in operator==(QString const&, QString const&)
> > (s1=@0x8287734, s2=@0x8130ed4) at tools/qstring.cpp:17323
> > #2 0x40b5a2c2 in QButton::setText(QString const&) (this=0x82876c0,
> > text=@0x8130ed4) at widgets/qbutton.cpp:467
> > #3 0x40be47bf in QPushButton (this=0x82876c0, text=@0x8130ed4,
> > parent=0x0, name=0x823efe8 "") at widgets/qpushbutton.cpp:284
> > #4 0x40746ac2 in QPushButtonGlue (this=0x82876c0, text=@0x8130ed4,
> > parent=0x0,
> > name=0x823efe8 "") at QPushButtonGlue.cpp:7
> > #5 0x407468e9 in new_QPushButton1 (managedPtr=0x12, text=@0x8130ed4,
> > parent=0x0, name=0x823efe8 "") at QPushButtonGlue.cpp:16
> > #6 0x080b1acb in ffi_call_SYSV ()
> > #7 0x080b1a92 in ffi_raw_call ()
> > #8 0x0808101d in _ILCVMInterpreter (thread=0x8108fc0) at cvm_call.c:665
> > #9 0x0804b912 in _ILCallMethod (thread=0x810903c, method=0x8109068,
> > unpack=0x804b620 <_ILCallUnpackDirectResult>, result=0x1, isCtor=0,
> > _this=0x1, pack=0x804b2a0 <_ILCallPackVaParams>, userData=0x1) at
> > call.c:705
> > #10 0x0804bc6c in ILExecThreadCall (thread=0x1, method=0x1, result=0x1)
> > at call.c:909
> > #11 0x0804b09b in main (argc=2, argv=0xbffff5e4) at ilrun.c:344
> > #12 0x40093991 in __libc_start_main () from /lib/libc.so.6
|
|
From: Marcus <ma...@my...> - 2003-01-18 01:31:29
|
Someone on mono-list mentioned another tool for building. It's found at http://premake.sourceforge.net |
|
From: <ped...@ya...> - 2003-01-17 11:02:27
|
--- Marcus <ma...@my...> escribió: > I talked with Dietmar about the problem with > exceptions before. Dietmar seems > to think it might be a GCC bug or possibly a problem > with Qt, but he isn't > sure. He is downloading Qt, so maybe will help us > find the answer. Even > though he thinks that it's not Mono that's the > *cause* of the problem, the > problem seems to be triggered by the native > exception handling optimizations > he put into Mono a while back. > > When Dietmar had me remove the -fexceptions and > -DMONO_USE_EXC_TABLES from > around lines 35--37, and rebuild mono, the > exceptions were handled correctly! > > I just wanted to update people on this. > > (Even though I think I'm the only one who reads > this.) You are not! :-) ___________________________________________________ Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito en http://moviles.yahoo.es |
|
From: Marcus <ma...@my...> - 2003-01-17 10:46:16
|
I talked with Dietmar about the problem with exceptions before. Dietmar seems to think it might be a GCC bug or possibly a problem with Qt, but he isn't sure. He is downloading Qt, so maybe will help us find the answer. Even though he thinks that it's not Mono that's the *cause* of the problem, the problem seems to be triggered by the native exception handling optimizations he put into Mono a while back. When Dietmar had me remove the -fexceptions and -DMONO_USE_EXC_TABLES from around lines 35--37, and rebuild mono, the exceptions were handled correctly! I just wanted to update people on this. (Even though I think I'm the only one who reads this.) |
|
From: Marcus <ma...@my...> - 2003-01-17 08:49:19
|
I also spent some time writing a tiny binding to QString by hand, using some code from current Qt#. Creating a QString from a System.String preserved unicode information. So does the implicit conversion from System.String to QString. I'll work on the other direction tomorrow. This should allow the next version of Qt# to have full unicode support. By the way, when appending data, QString is actually a little faster than Mono's StringBuilder class. |
|
From: Marcus <ma...@my...> - 2003-01-17 07:14:09
|
Today I added support for slots that accept a signal QString parameter. Using this type of slot has a couple of tricks because of the way strings are mapped in this version of Qt#: in the places where the C++ member function takes a QString, the C# equivalent uses a string. (The Qt# binding takes care of the conversion.) Qt#'s signal connection code expected to find a slot with the same parameter type(s) as the signal. Suppose that I want to connect a QLineEdit's textchanged signal to a QLabel's setText slot. The QLineEdit actually has a parameter with type QString, but QLabel's SetText takes a *string* parameter. As a consequence, you can only connect to a user-defined slot like public void StringSlot(QString s) For an example, see the attached file qstring-slot.cs, also found in the samples directory in CVS (QTSHARP-0_6_BRANCH). |
|
From: Adam T. <ma...@ya...> - 2003-01-16 17:38:41
|
Holger, I have started setting up a build system for Qt/X11 3.1 for mingw/cygwin in Windows (I couldn't get your stuff to build). Basically, I created a new mkspec/QMake.conf for mingw/m-no-cygwin. I would be happy to send you what I've done (it tries to build qmake and get's as far as qdir_win.cpp and qfile_win.cpp (these *_win.cpp files are just copied from the *_unix.cpp counterparts). Once these files are ported I think qmake can be built as a native tool on windows and we can use that for the rest. This should work for either mingw or -m-no-cygwin and hopefully could be rolled into KDE's qt-copy when it is ready. I don't think either of these files would be hard to port for someone knowledgable with Windows API. Since Qt3.1 is the latest and greatest perhaps that is the best target. A nice build system that would compile something would help to let people play with what you have so far :) Cheers, Adam --- Holger Schroeder <hol...@ho...> wrote: > Hi, > > the short form is, i was on the ccc meeting in berlin and now i have a > lot to do for university this week, but i will prepare my changes for a > new branch in the qt-2 module this week. so people shoould be able to > checkout stuff by the next week. > now i bought the programming windows-book from charles petzold, and it > helped quite a lot. i also have to clean up my file names to fit into > the kde-cygwin layout and look over the copyrights in the files. > > don´t download my old stuff at the old link, it is already quite > outdated.. > > Holger > > > On Wed, 2003-01-15 at 00:16, David Fraser wrote: > > Ralf Habacker wrote: > > > > >>BTW: I have added you to this list. > > >> > > >> > > >> > > > > > >I mean the email address from the uni hannover, from which you have send your > > >last mail > > >(I assume that your holgis.net email account will not work yet because of your > > >name server problem) > > > > > >Regards > > > > > >Ralf > > > > > >_______________________________________________ > > >kde-cygwin mailing list > > >kde...@ma... > > >http://mail.kde.org/mailman/listinfo/kde-cygwin > > > > > > > > > > > Anything further happened with the KDE/QT native port? Problems, > > difficulties, success or holidays :-)? > > > > David > > > > _______________________________________________ > > kde-cygwin mailing list > > kde...@ma... > > http://mail.kde.org/mailman/listinfo/kde-cygwin > > > > > > _______________________________________________ > kde-cygwin mailing list > kde...@ma... > http://mail.kde.org/mailman/listinfo/kde-cygwin __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
2258 messages has been excluded from this view by a project administrator.
