Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Graeme, If Delphi is dead, then what's Lazarus? The subtext is that with Delphi you can pull off the hat trick of a 2.3 million line app that sells for big bucks and where the client does not tolerate bugs or instabilities or excuses. Can anyone make that claim for Lazarus? Thanks. -Phil - Graeme Geldenhuys gra...@mastermaths.co.za wrote: Phil Hess wrote: that should make merging a bit easier. But I have to say that Roman was quite dismayed to learn that ports of many other packages that he uses were done as one-way ports to Lazarus, leaving Delphi compatibility behind. To be fair, Delphi itself was left behind for a few years and started looking like it was heading the way of Kylix. Same applies to many component suites. So in that case why bother with the extra effort to keep compatibility with a dead product. Now speaking as somebody that has ported a fare share of components and complete projects to other GUI toolkits. Most of the time changes will never be back-ported to the original project. Plus, it's hard enough already to port a component to another GUI toolkit, and then you expect to obfuscate the code even further with IFDEFs just to keep it alive for two compilers and various GUI toolkits - that's crazy. And double work! Take TSynEdit for example. The code has changed such a lot from the original, I don't think anybody will be able to backport Lazarus's synedit to the original code. So why not simply clean up the Lazarus code and remove all those damn IFDEFs so the code is actually readable. All I do is try and notify the original author to let them know their component or project lives on in another project and keep the credits or copyright notice in the units. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Zeljko, This is what my Qt Crashes for TOvcSpinner is based on. And also on testing with the current stable version. If this is fixed, that's great, but doesn't help the user who has 0.9.28.2. Also, I want to make sure there aren't any Mac-specific or even endian issues here. I think most of the endian things were wrung out of LCL years ago, but you never know. Thanks. -Phil - zeljko zel...@holobit.net wrote: On Wednesday 02 December 2009 01:37, Phil Hess wrote: Zeljko, I'm not seeing the same problem with the Qt widgetset that you reported: TApplication.HandleException Access violation Stack trace: $02345E7C $0445EFB4 $00260568 TQTDEVICECONTEXT__QDRAWWINPANEL, line 1958 of qtobjects.pas $001C9574 TQTWIDGETSET__FRAME3D, line 1775 of qtwinapi.inc $000D6210 FRAME3D, line 222 of ./include/lclintf.inc $000EEA08 TCANVAS__FRAME3D, line 963 of ./include/canvas.inc $002A4CDC DRAWBUTTONFACE, line 984 of mymisc.pas $0028E954 TOVCSPINNER__SCDRAWNORMALBUTTON, line 1194 of ovcsc.pas $0028AD64 TOVCSPINNER__SCDRAWBUTTON, line 613 of ovcsc.pas $0028A2FC TOVCSPINNER__SCDOMOUSEUP, line 531 of ovcsc.pas $0029111C TOVCSPINNER__WMLBUTTONUP, line 1713 of ovcsc.pas $00011018 $0018D640 TCONTROL__WNDPROC, line 1593 of ./include/control.inc $00180C90 TWINCONTROL__WNDPROC, line 4920 of ./include/wincontrol.inc $00249D44 TQTWIDGET__DELIVERMESSAGE, line 3826 of qtwidgets.pas $00246548 TQTWIDGET__SLOTMOUSE, line 2413 of qtwidgets.pas $00245148 TQTWIDGET__EVENTFILTER, line 1819 of qtwidgets.pas Could you test with 0.9.28.2? That's what I've got on my PowerPC Mac that I use for testing. huh...0.9.28.2 ? no :) I'm using trunk all the time :), and haven't ppc but intel mac 10.4.XX. I'll do my best to test it (I have qt-4.5.1 on mac) There was some problems with qDrawWinPanel. Crash is fixed in 0.9.29 r 21876 http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/qt/qtobjects.pas?root=lazarusr1=21821r2=21876 so again it works for me :). it is probably merged into 0.9.28.3. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Graeme Geldenhuys wrote: Take TSynEdit for example. The code has changed such a lot from the original, I don't think anybody will be able to backport Lazarus's synedit to the original code. So why not simply clean up the Lazarus code and remove all those damn IFDEFs so the code is actually readable. That process is already started. Marc -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Phil Hess wrote: If Delphi is dead, then what's Lazarus? What I meant to say was that after about Delphi 7 and the rise of Visual Studio + .NET, Delphi took a major hit in popularity. Combine that with Borlands many failed attempt at getting into .NET and then deciding to sell Delphi, the future looked bleak. This is what I meant with the uncertain future of Delphi (looking similar to Kylix). That's the time our company moved to FPC and Lazarus. The open source toolchain had a brighter future, so the idea of keeping ported components active for Delphi did not seem worth the effort. Embarcadero seems to be doing a better job with Delphi now, so maybe now there is more intensive to keep backward compatibility with Delphi. But I'm not going to bother. The subtext is that with Delphi you can pull off the hat trick of a 2.3 million line app that sells for big bucks and where the client does not tolerate bugs or instabilities or excuses. Can anyone make that claim for Lazarus? Well, our application is not quite that big, sitting around 300,000 lines of code at the moment. Our product also sells well (I'm still employed wink), and has an install base of over 15,000 computers. So yeah, I don't think we are doing to bad considering we are not using a commercial product like Delphi, but rather open source software like FPC and Lazarus. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Marc Weustink wrote: That process is already started. I take it you mean cleaning up the code and not backporting to the original code. In that case, excellent news. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Graeme Geldenhuys wrote: Marc Weustink wrote: That process is already started. I take it you mean cleaning up the code and not backporting to the original code. In that case, excellent news. ;-) Yes, he means cleaning up. Some of the IFDEF have been removed already, and the only supported/compiling version is the Lazarus version. The original SynEdit also has code that in LazArus is part of the LCL = that is also gradually removed from SynEdit, to use the LCL instead. Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Wednesday 02 December 2009 15:22, Phil Hess wrote: Zeljko, This is what my Qt Crashes for TOvcSpinner is based on. And also on testing with the current stable version. If this is fixed, that's great, but doesn't help the user who has 0.9.28.2. But it could be in 0.9.28.3 then. Also, I want to make sure there aren't any Mac-specific or even endian issues here. I think most of the endian things were wrung out of LCL years ago, but you never know. Haven't any spare time to test in on my mac...so probably tomorrow. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
No hurry. I'm actually kind of excited now again about the prospect of actually getting Orpheus and THtmlPort packages running reliably on all 4 major widgetsets (win32, carbon, gtk2, qt). The improvements in GTK2 / LCL in SVN are big, I think. And if Qt has improved too in SVN... Of course one question would be how soon to get all these LCL/widgetset improvements into a stable release. That's critical. Otherwise, I can't really say to Delphi users that these packages are useable since that would mean they would have to start out with building from SVN and become a Lazarus aficianado instead of a Lazarus user. Thanks. -Phil - zeljko zel...@holobit.net wrote: On Wednesday 02 December 2009 15:22, Phil Hess wrote: Zeljko, This is what my Qt Crashes for TOvcSpinner is based on. And also on testing with the current stable version. If this is fixed, that's great, but doesn't help the user who has 0.9.28.2. But it could be in 0.9.28.3 then. Also, I want to make sure there aren't any Mac-specific or even endian issues here. I think most of the endian things were wrung out of LCL years ago, but you never know. Haven't any spare time to test in on my mac...so probably tomorrow. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
- Graeme Geldenhuys gra...@mastermaths.co.za wrote: The subtext is that with Delphi you can pull off the hat trick of a 2.3 million line app that sells for big bucks and where the client does not tolerate bugs or instabilities or excuses. Can anyone make that claim for Lazarus? Well, our application is not quite that big, sitting around 300,000 lines of code at the moment. Our product also sells well (I'm still employed wink), and has an install base of over 15,000 computers. So yeah, I don't think we are doing to bad considering we are not using a commercial product like Delphi, but rather open source software like FPC and Lazarus. Well, I guess you can say you're within an order of magnitude of that 2.3 million lines. By the way, Delphi 2010 compiles that 2.3 million lines of code in 70 seconds, including linking and creating a map file. The 2.3 does not include any Delphi RTL/VCL source or 3rd party components. Thanks. -Phil -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Wed, 2 Dec 2009, Phil Hess wrote: - Graeme Geldenhuys gra...@mastermaths.co.za wrote: The subtext is that with Delphi you can pull off the hat trick of a 2.3 million line app that sells for big bucks and where the client does not tolerate bugs or instabilities or excuses. Can anyone make that claim for Lazarus? Well, our application is not quite that big, sitting around 300,000 lines of code at the moment. Our product also sells well (I'm still employed wink), and has an install base of over 15,000 computers. So yeah, I don't think we are doing to bad considering we are not using a commercial product like Delphi, but rather open source software like FPC and Lazarus. Well, I guess you can say you're within an order of magnitude of that 2.3 million lines. By the way, Delphi 2010 compiles that 2.3 million lines of code in 70 seconds, including linking and creating a map file. Strange. It takes longer to compile my work project, which is around 700.000 lines. It takes up to 5 minutes to compile on any reasonable new computer. Just to say: Giving such numbers is quite dangerous, because It all depends on the file layout, number of packages and whatnot. For fun, I created a small program that creates program code for 2.3 million lines distributed over 460 units (approx 6000 lines per unit), and a program that calls a routine from each unit. The 64-bit compiler compiles it all in 1m53s. Given that the 32-bit compiler is much faster than the 64-bit one, I think it's close to a tie with Delphi. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Good to know that PtInRegion is now part of LclIntf - it wasn't when I ported
this and there's no way of knowing when new functions are added without
monitoring closely every commit!
However, the current code works with other widgetsets. Do you know why it
didn't work with Qt?
I'll look at this tonight.
Thanks for your investigation.
-Phil
- zeljko zel...@holobit.net wrote:
On Monday 30 November 2009 18:17, Phil Hess wrote:
I wish I knew! I really don't have time (or patience) to do more
than test
Orpheus against each widgetset for the stable release of Lazarus.
A couple observations are in order:
(1) Although once in a while I stumble across something in the
Orpheus code
that allows me to fix a problem (as in the expression Even a blind
sow
occasionally finds an acorn), in general improvements in Orpheus
are due
to improvements in the LCL and widgetsets. Or in some cases, as
happened
with 0.9.28, Orpheus gets worse over time through no fault of its
own.
My fast observations qt fixes from last night:
1.I've fixed crash in getRegionType function (qt) which happens when
someone
create region with negative width or height.
2.Orpheus spinner control (and maybe others) crashed under qt because
of
MyMisc.ptInRegion() implementation.
function PtInRegion(RGN: HRGN; X, Y: Integer) : Boolean;
{$IFDEF MSWINDOWS}
begin
Result := Windows.PtInRegion(RGN, X, Y);
{$ELSE}
var
ARect : TRect;
APt : TPoint;
begin
GetRgnBox(RGN, @ARect);
APt.X := X;
APt.Y := Y;
Result := LclIntf.PtInRect(ARect, APt);
{$ENDIF}
end;
Why is it implemented in such way when we have
Result := LCLIntf.ptInRegion(RGN, X, Y);
which doesn't crash orpheus controls under qt even
with buggy(was until last night) TQtRegion constructor.
Anyway, it does not crash anymore.
(2) It's apparent that the LCL and widgetset maintainers never test
their
changes against the CCR packages. The attitude seems to be that
package
maintainers will test daily against SVN and notify of any breaks.
Sorry,
can't do that.
Yes, they do that, but orpheus isn't often used seem so.I'm using
virtualtrees
and it work w/o problems. From my observations (eg. ptInRegion()
implementation), some things need to be changed in orpheus , not in
widgetsets or LCL.
zeljko
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Tue, Dec 1, 2009 at 12:35 PM, Phil Hess macp...@fastermac.net wrote: However, the current code works with other widgetsets. Do you know why it didn't work with Qt? Did you test Qt in Windows or Linux? According to the code it seams that any non-win32 widgetset would fail to run in Windows because you use windows operating system ifdefs instead of LCLWin32 ifdef for the widgetset. Using LCL-Qt in Windows doesn't make the handles become Windows handles, they are still Qt handles. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Good point, although if you recall the history of this port, it started with the only two widgetsets that worked back then: win32 and gtk1 - the others just came along for the ride. I'm not even sure that LCLWin32 was defined back when I started. Does anyone use Qt on Windows though? That doesn't make sense to me. Why put another layer on top of Windows when win32 works quite well? And without any auxiliary libraries. Nevertheless, the code probably needs to modernizing. Oh joy... Thanks. -Phil - Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Tue, Dec 1, 2009 at 12:35 PM, Phil Hess macp...@fastermac.net wrote: However, the current code works with other widgetsets. Do you know why it didn't work with Qt? Did you test Qt in Windows or Linux? According to the code it seams that any non-win32 widgetset would fail to run in Windows because you use windows operating system ifdefs instead of LCLWin32 ifdef for the widgetset. Using LCL-Qt in Windows doesn't make the handles become Windows handles, they are still Qt handles. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Tue, Dec 1, 2009 at 1:24 PM, Phil Hess macp...@fastermac.net wrote: Good point, although if you recall the history of this port, it started with the only two widgetsets that worked back then: win32 and gtk1 - the others just came along for the ride. I'm not even sure that LCLWin32 was defined back when I started. I would bet they were already defined, they are extremely old. Does anyone use Qt on Windows though? That doesn't make sense to me. Why put another layer on top of Windows when win32 works quite well? And without any auxiliary libraries. Less work to port between LCL platforms. If you use LCL-Qt in all platforms your port effort between them is minimal (if necessary), both because you are using the same LCL-Qt codebase instead of multiple widgetset codes with various states of supported components and because Qt is not a native toolkit, it just looks native but has custom painting which helps it be very consistent across platforms. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
I see that GTK/GTK2 doesn't appear to have PtInRegion implemented. That's probably why I didn't use it. In some cases the compatibility functions still need to call the Win API regardless of widgetset if running on Windows, but you're right, if a handle is passed, that should only be passed on to Win API if LCLwin32 is defined. I'll review all the compat. functions when I have some time. Thanks. -Phil - Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Tue, Dec 1, 2009 at 1:24 PM, Phil Hess macp...@fastermac.net wrote: Good point, although if you recall the history of this port, it started with the only two widgetsets that worked back then: win32 and gtk1 - the others just came along for the ride. I'm not even sure that LCLWin32 was defined back when I started. I would bet they were already defined, they are extremely old. Does anyone use Qt on Windows though? That doesn't make sense to me. Why put another layer on top of Windows when win32 works quite well? And without any auxiliary libraries. Less work to port between LCL platforms. If you use LCL-Qt in all platforms your port effort between them is minimal (if necessary), both because you are using the same LCL-Qt codebase instead of multiple widgetset codes with various states of supported components and because Qt is not a native toolkit, it just looks native but has custom painting which helps it be very consistent across platforms. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
One of the points about Orpheus and other ported packages that I should probably make is that I've been in contact with Roman Kassebaum who maintains the Orpheus SourceForge projects and recently updated Orpheus for Unicode on Delphi 2009/2010. We've discussed possibly merging our codebases and also possibly trying to support DelphiX when/if it's released. Fortunately since I maintained full Delphi compatibility in my port, that should make merging a bit easier. But I have to say that Roman was quite dismayed to learn that ports of many other packages that he uses were done as one-way ports to Lazarus, leaving Delphi compatibility behind. I could sense his interest in Lazarus quickly dissipating. Roman's largest app is 2.3 million lines of code! I've been encouraging him to see how much of it he can get compiled with Lazarus, not so much to offer the app on other platforms, but as a way of further testing his code and expanding his world (in the U.S., engineers call this sort of effort a skunkworks project - historically lots of great original things come out of those). This would also be a good test of Lazarus. But if the other packages have changed significantly from their Delphi sources, then this might be difficult for him to do. Thanks. -Phil - Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Tue, Dec 1, 2009 at 1:24 PM, Phil Hess macp...@fastermac.net wrote: Good point, although if you recall the history of this port, it started with the only two widgetsets that worked back then: win32 and gtk1 - the others just came along for the ride. I'm not even sure that LCLWin32 was defined back when I started. I would bet they were already defined, they are extremely old. Does anyone use Qt on Windows though? That doesn't make sense to me. Why put another layer on top of Windows when win32 works quite well? And without any auxiliary libraries. Less work to port between LCL platforms. If you use LCL-Qt in all platforms your port effort between them is minimal (if necessary), both because you are using the same LCL-Qt codebase instead of multiple widgetset codes with various states of supported components and because Qt is not a native toolkit, it just looks native but has custom painting which helps it be very consistent across platforms. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Tuesday 01 December 2009 15:35, Phil Hess wrote:
Good to know that PtInRegion is now part of LclIntf - it wasn't when I
ported this and there's no way of knowing when new functions are added
without monitoring closely every commit!
However, the current code works with other widgetsets. Do you know why it
didn't work with Qt?
Because, Qt doesn't like negative width height in QRegion constructor and
because LCLIntf.GetRgnBox() (qt implementation) was marked with warning that
implemenation maybe sucks (now it's fixed also).
As Felipe already mentioned, there's too much wrong ifdefs, qt is pretty
stable and it must work if you change code to be more LCL-ish.
zeljko
I'll look at this tonight.
Thanks for your investigation.
-Phil
- zeljko zel...@holobit.net wrote:
On Monday 30 November 2009 18:17, Phil Hess wrote:
I wish I knew! I really don't have time (or patience) to do more
than test
Orpheus against each widgetset for the stable release of Lazarus.
A couple observations are in order:
(1) Although once in a while I stumble across something in the
Orpheus code
that allows me to fix a problem (as in the expression Even a blind
sow
occasionally finds an acorn), in general improvements in Orpheus
are due
to improvements in the LCL and widgetsets. Or in some cases, as
happened
with 0.9.28, Orpheus gets worse over time through no fault of its
own.
My fast observations qt fixes from last night:
1.I've fixed crash in getRegionType function (qt) which happens when
someone
create region with negative width or height.
2.Orpheus spinner control (and maybe others) crashed under qt because
of
MyMisc.ptInRegion() implementation.
function PtInRegion(RGN: HRGN; X, Y: Integer) : Boolean;
{$IFDEF MSWINDOWS}
begin
Result := Windows.PtInRegion(RGN, X, Y);
{$ELSE}
var
ARect : TRect;
APt : TPoint;
begin
GetRgnBox(RGN, @ARect);
APt.X := X;
APt.Y := Y;
Result := LclIntf.PtInRect(ARect, APt);
{$ENDIF}
end;
Why is it implemented in such way when we have
Result := LCLIntf.ptInRegion(RGN, X, Y);
which doesn't crash orpheus controls under qt even
with buggy(was until last night) TQtRegion constructor.
Anyway, it does not crash anymore.
(2) It's apparent that the LCL and widgetset maintainers never test
their
changes against the CCR packages. The attitude seems to be that
package
maintainers will test daily against SVN and notify of any breaks.
Sorry,
can't do that.
Yes, they do that, but orpheus isn't often used seem so.I'm using
virtualtrees
and it work w/o problems. From my observations (eg. ptInRegion()
implementation), some things need to be changed in orpheus , not in
widgetsets or LCL.
zeljko
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Tuesday 01 December 2009 17:10, Phil Hess wrote: I see that GTK/GTK2 doesn't appear to have PtInRegion implemented. That's probably why I didn't use it. So the best thing would be that you try to implement it :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Zeljko, I'm not seeing the same problem with the Qt widgetset that you reported: TApplication.HandleException Access violation Stack trace: $02345E7C $0445EFB4 $00260568 TQTDEVICECONTEXT__QDRAWWINPANEL, line 1958 of qtobjects.pas $001C9574 TQTWIDGETSET__FRAME3D, line 1775 of qtwinapi.inc $000D6210 FRAME3D, line 222 of ./include/lclintf.inc $000EEA08 TCANVAS__FRAME3D, line 963 of ./include/canvas.inc $002A4CDC DRAWBUTTONFACE, line 984 of mymisc.pas $0028E954 TOVCSPINNER__SCDRAWNORMALBUTTON, line 1194 of ovcsc.pas $0028AD64 TOVCSPINNER__SCDRAWBUTTON, line 613 of ovcsc.pas $0028A2FC TOVCSPINNER__SCDOMOUSEUP, line 531 of ovcsc.pas $0029111C TOVCSPINNER__WMLBUTTONUP, line 1713 of ovcsc.pas $00011018 $0018D640 TCONTROL__WNDPROC, line 1593 of ./include/control.inc $00180C90 TWINCONTROL__WNDPROC, line 4920 of ./include/wincontrol.inc $00249D44 TQTWIDGET__DELIVERMESSAGE, line 3826 of qtwidgets.pas $00246548 TQTWIDGET__SLOTMOUSE, line 2413 of qtwidgets.pas $00245148 TQTWIDGET__EVENTFILTER, line 1819 of qtwidgets.pas Could you test with 0.9.28.2? That's what I've got on my PowerPC Mac that I use for testing. I'm running against Qt 4.5.2. Thanks. -Phil - zeljko zel...@holobit.net wrote: On Tuesday 01 December 2009 17:10, Phil Hess wrote: I see that GTK/GTK2 doesn't appear to have PtInRegion implemented. That's probably why I didn't use it. So the best thing would be that you try to implement it :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
I wish I knew! I really don't have time (or patience) to do more than test Orpheus against each widgetset for the stable release of Lazarus. A couple observations are in order: (1) Although once in a while I stumble across something in the Orpheus code that allows me to fix a problem (as in the expression Even a blind sow occasionally finds an acorn), in general improvements in Orpheus are due to improvements in the LCL and widgetsets. Or in some cases, as happened with 0.9.28, Orpheus gets worse over time through no fault of its own. (2) It's apparent that the LCL and widgetset maintainers never test their changes against the CCR packages. The attitude seems to be that package maintainers will test daily against SVN and notify of any breaks. Sorry, can't do that. Thanks. -Phil - zeljko zel...@holobit.net wrote: On Sunday 29 November 2009 19:49, Phil Hess wrote: Juha, I test the 5 major widgetsets with several packages of custom controls that I've ported from Delphi and the Qt widgetset appears to be the least stable: http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls hmm...qt doesn't look very stable here. Can you point to some bug inside qtlcl which can be fixed , so orph ctls can work ok with qt ? eg. I see that TOvcSpinner is marked as Crashing ... zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Monday 30 November 2009 18:17, Phil Hess wrote:
I wish I knew! I really don't have time (or patience) to do more than test
Orpheus against each widgetset for the stable release of Lazarus.
A couple observations are in order:
(1) Although once in a while I stumble across something in the Orpheus code
that allows me to fix a problem (as in the expression Even a blind sow
occasionally finds an acorn), in general improvements in Orpheus are due
to improvements in the LCL and widgetsets. Or in some cases, as happened
with 0.9.28, Orpheus gets worse over time through no fault of its own.
My fast observations qt fixes from last night:
1.I've fixed crash in getRegionType function (qt) which happens when someone
create region with negative width or height.
2.Orpheus spinner control (and maybe others) crashed under qt because of
MyMisc.ptInRegion() implementation.
function PtInRegion(RGN: HRGN; X, Y: Integer) : Boolean;
{$IFDEF MSWINDOWS}
begin
Result := Windows.PtInRegion(RGN, X, Y);
{$ELSE}
var
ARect : TRect;
APt : TPoint;
begin
GetRgnBox(RGN, @ARect);
APt.X := X;
APt.Y := Y;
Result := LclIntf.PtInRect(ARect, APt);
{$ENDIF}
end;
Why is it implemented in such way when we have
Result := LCLIntf.ptInRegion(RGN, X, Y);
which doesn't crash orpheus controls under qt even
with buggy(was until last night) TQtRegion constructor.
Anyway, it does not crash anymore.
(2) It's apparent that the LCL and widgetset maintainers never test their
changes against the CCR packages. The attitude seems to be that package
maintainers will test daily against SVN and notify of any breaks. Sorry,
can't do that.
Yes, they do that, but orpheus isn't often used seem so.I'm using virtualtrees
and it work w/o problems. From my observations (eg. ptInRegion()
implementation), some things need to be changed in orpheus , not in
widgetsets or LCL.
zeljko
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Juha Manninen wrote: On sunnuntai, 29. marraskuuta 2009 15:11:24 Vincent Snijders wrote: As Florian noted, Lazarus needs developers more than users. There are more gtk2 issues than win32 issues, so we need to focus our martekting (if any) more to the potential gtk2 developers (on linux) than on the potential win32 developers. What about potential QT developers? My suggestion is to make QT bindings the default recommended (on Linux at least), and consider stable QT bindings as a requirement for v1.0. Why not ship via getlaz off the wiki with both sets of bindings? -- LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/ Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/ GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Juha, I test the 5 major widgetsets with several packages of custom controls that I've ported from Delphi and the Qt widgetset appears to be the least stable: http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls Thanks. -Phil - Juha Manninen juha.manni...@phnet.fi wrote: On sunnuntai, 29. marraskuuta 2009 15:11:24 Vincent Snijders wrote: As Florian noted, Lazarus needs developers more than users. There are more gtk2 issues than win32 issues, so we need to focus our martekting (if any) more to the potential gtk2 developers (on linux) than on the potential win32 developers. What about potential QT developers? My suggestion is to make QT bindings the default recommended (on Linux at least), and consider stable QT bindings as a requirement for v1.0. This is a very realistic goal. I have compiled Lazarus for QT widgets and it works great. The bugs I found I have reported and Zeljan has already fixed them. Only some minor OpenSuse related issues remain. I already know some places where QT bindings work better than GTK2 bindings. QT has better design internally than GTK2. Many programmers have stated that, it is not only my opinion. Thus I believe bindings for QT are easier to make. (This was an educated guess, I don't know the details.) QT has lots of momentum now that Nokia bought it. There are more potential QT developers than GTK2 developers to attract if you advertise it as the number one stable binding. Regards, Juha Manninen -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
2009/11/29 Phil Hess macp...@fastermac.net: http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls I'm curious... I once installed but never used TovcXXX controls (years ago and can't remember if it was Delphi or Lazarus). What exactly does the TOvcController do? And do you have an example of how it is used? Is it something like TAction component? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
Phil Hess schrieb: I test the 5 major widgetsets with several packages of custom controls that I've ported from Delphi and the Qt widgetset appears to be the least stable: http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls Wow, great work :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] QT bindings as defalt (was Release 1.0, part 2)
On Sunday 29 November 2009 19:49, Phil Hess wrote: Juha, I test the 5 major widgetsets with several packages of custom controls that I've ported from Delphi and the Qt widgetset appears to be the least stable: http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls hmm...qt doesn't look very stable here. Can you point to some bug inside qtlcl which can be fixed , so orph ctls can work ok with qt ? eg. I see that TOvcSpinner is marked as Crashing ... zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
