Re: [lazarus] What is wrong with the Toolbar?
On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ attachment: lazarus_r13826.png
Re: [lazarus] What is wrong with the Toolbar?
On Tue, 22 Jan 2008 09:24:25 +0100 (CET) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... This is quite strange, because I submitted a bug report about this, and Paul fixed that. I tested his fix a couple of days ago, and the toolbar now actually paints the background. (I used and tested GTK 1) I can confirm, it has improved, but the the tool button backgrounds are still not painted correct. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
On Jan 22, 2008, at 9:24 AM, Michael Van Canneyt wrote: On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... This is quite strange, because I submitted a bug report about this, and Paul fixed that. I tested his fix a couple of days ago, and the toolbar now actually paints the background. (I used and tested GTK 1) GTk2/ Ubuntu Not always. If you only put a TToolBar on a new form of a new project it works indeed. However if you put a TListView and you choose to directly edit columns from the IDE the toolbar remains transparent. And you can not select an item in this form. inline: colomns.jpg -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty)
Re: [lazarus] What is wrong with the Toolbar?
On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... This is quite strange, because I submitted a bug report about this, and Paul fixed that. I tested his fix a couple of days ago, and the toolbar now actually paints the background. (I used and tested GTK 1) Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Where can I find the snapshot build scripts?
Paul Michell schreef: Could someone please tell me where I can find the build scripts for the daily snapshots? My own batch file for reading SVN and building locally has been failing for the last couple of days so I would like to see how the snapshots do it. Most scripts are in lazarus\tools\install. They are called by wrapper scripts that pass the correct svn directories (already checked out) and upload the installers, .dmg or rpms. Those scripts are not in svn. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OpenMoko and FPC/Lazarus
Marc Weustink schrieb: Marc Weustink wrote: Florian Klaempfl wrote: Luca Olivetti schrieb: En/na Florian Klaempfl ha escrit: It should be enough to build FPC with OPT=-dFPC_ARMEL So it's now possible to produce eabi code with fpc? Well, I did initial support. If you provide bugs reports, I'll try to fix them. hmm... current openmoko versions are eabi, but when I run a testapp build by such fpc I get: Program received signal SIGILL, Illegal instruction. 0x000129d0 in SYSTEM_FPSYSCALL$LONGINT$$LONGINT () (gdb) bt #0 0x000129d0 in SYSTEM_FPSYSCALL$LONGINT$$LONGINT () #1 0x00012e1c in SYSTEM_FPGETRLIMIT$LONGINT$PRLIMIT$$LONGINT () #2 0x0001eef8 in SYSTEM_CHECKINITIALSTKLEN$LONGWORD$$LONGWORD () #3 0x0001efbc in SYSTEM_init () #4 0x0001a7ec in fpc_initializeunits () #5 0xe668 in main () at gtk2query.pp:263 I tried something more. I compiled FPC without FPC_ARMEL, but tweaked init_settings.fputype:=fpu_soft in globals.pas so it would use soft fpu. Now my testapp crashes on the first librarycall (how surprising), but passes the fpc_initializeunits (and manages to do some writeln). From this I assume syscalls in this case are correct and I guess there is some difference between syscall calling and library calling. As Luca suspected, this is the wrong way :) You've a kernel with old syscall support. You should find out why it crashes with -dFPC_ARMEL. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OpenMoko and FPC/Lazarus
Florian Klaempfl wrote: Marc Weustink schrieb: Marc Weustink wrote: Florian Klaempfl wrote: Luca Olivetti schrieb: En/na Florian Klaempfl ha escrit: It should be enough to build FPC with OPT=-dFPC_ARMEL So it's now possible to produce eabi code with fpc? Well, I did initial support. If you provide bugs reports, I'll try to fix them. hmm... current openmoko versions are eabi, but when I run a testapp build by such fpc I get: Program received signal SIGILL, Illegal instruction. 0x000129d0 in SYSTEM_FPSYSCALL$LONGINT$$LONGINT () (gdb) bt #0 0x000129d0 in SYSTEM_FPSYSCALL$LONGINT$$LONGINT () #1 0x00012e1c in SYSTEM_FPGETRLIMIT$LONGINT$PRLIMIT$$LONGINT () #2 0x0001eef8 in SYSTEM_CHECKINITIALSTKLEN$LONGWORD$$LONGWORD () #3 0x0001efbc in SYSTEM_init () #4 0x0001a7ec in fpc_initializeunits () #5 0xe668 in main () at gtk2query.pp:263 I tried something more. I compiled FPC without FPC_ARMEL, but tweaked init_settings.fputype:=fpu_soft in globals.pas so it would use soft fpu. Now my testapp crashes on the first librarycall (how surprising), but passes the fpc_initializeunits (and manages to do some writeln). From this I assume syscalls in this case are correct and I guess there is some difference between syscall calling and library calling. As Luca suspected, this is the wrong way :) You've a kernel with old syscall support. You should find out why it crashes with -dFPC_ARMEL. I did this test only to see if there is a difference between calling conventions used for libraries and for syscalls. It was not an attempt to get this path to working. Assuming that there is a difference on purpose (need to sort that out), I tried to build a version with FPC_USE_LIBC to eliminate syscalls. After 2 patches, I got a RTL build with it, but it somehow fails to allocate mem. (fmmap returns -1) Also that needs to be investigated (it was way beyond my bedtime) Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Mattias Gaertner wrote: Al Boldi [EMAIL PROTECTED] wrote: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OpenMoko and FPC/Lazarus
Luca Olivetti wrote: En/na Marc Weustink ha escrit: From this I assume syscalls in this case are correct and I guess there is some difference between syscall calling and library calling. Maybe openmoko as an eabi kernel compiled with oabi compatibility? (otherwise I think old style syscalls wouldn't work). And, I don't know if there are differences in library calling, but sure there are differences in structure alignment (especially if there are enums in the structures). Yes, I know. But how can I tell the compiler that for syscalls oabi alignment should be used and for libraries eabi ? (assuming that is crashes on wrong alignment and that there is indeed such difference) Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OpenMoko and FPC/Lazarus
Marc Weustink schrieb: Luca Olivetti wrote: En/na Marc Weustink ha escrit: From this I assume syscalls in this case are correct and I guess there is some difference between syscall calling and library calling. Maybe openmoko as an eabi kernel compiled with oabi compatibility? (otherwise I think old style syscalls wouldn't work). And, I don't know if there are differences in library calling, but sure there are differences in structure alignment (especially if there are enums in the structures). Yes, I know. But how can I tell the compiler that for syscalls oabi alignment should be used and for libraries eabi ? (assuming that is crashes on wrong alignment and that there is indeed such difference) You shouldn't. We simply need to fix -dFPC_ARMEL. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] [OT] QT licensing costs?
On Tue, 22 Jan 2008 08:41:02 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I don't use C/C++ but I think they have a kick ass toolkit. Leaps and bounds ahead of anybody else. I am forced to use C++ and Qt at work and I beg to differ. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Damien Gerard wrote: On Jan 22, 2008, at 9:24 AM, Michael Van Canneyt wrote: On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... This is quite strange, because I submitted a bug report about this, and Paul fixed that. I tested his fix a couple of days ago, and the toolbar now actually paints the background. (I used and tested GTK 1) GTk2/ Ubuntu Not always. If you only put a TToolBar on a new form of a new project it works indeed. However if you put a TListView and you choose to directly edit columns from the IDE the toolbar remains transparent. And you can not select an item in this form. Ok, I understand :) I moved some old code in gtk, gtk2 widgetsets and forget about toolbar and toolbutton (they are ownerdrawn conrols and I thought it is not needed to create special widget for them). Later I found toolbar transparency issue and restore widget creation code. Now I see that toolbutton is also needs special widget. I only dont understand exactly why GtkApiWidget (special widget for drawing) is not enought for them. Anyway, I'll fix this tomorow. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Zitat von Paul Ishenin [EMAIL PROTECTED]: Damien Gerard wrote: On Jan 22, 2008, at 9:24 AM, Michael Van Canneyt wrote: On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... This is quite strange, because I submitted a bug report about this, and Paul fixed that. I tested his fix a couple of days ago, and the toolbar now actually paints the background. (I used and tested GTK 1) GTk2/ Ubuntu Not always. If you only put a TToolBar on a new form of a new project it works indeed. However if you put a TListView and you choose to directly edit columns from the IDE the toolbar remains transparent. And you can not select an item in this form. Ok, I understand :) I moved some old code in gtk, gtk2 widgetsets and forget about toolbar and toolbutton (they are ownerdrawn conrols and I thought it is not needed to create special widget for them). Later I found toolbar transparency issue and restore widget creation code. Now I see that toolbutton is also needs special widget. I only dont understand exactly why GtkApiWidget (special widget for drawing) is not enought for them. GtkApiWidget is a special widget for custom controls, which do everything themselves. It is not for regular LCL controls. AFAIK Marc wanted to replace eventually TToolBar/TToolButton with real widgets (not LCL drawn). Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Mattias Gärtner wrote: GtkApiWidget is a special widget for custom controls, which do everything themselves. It is not for regular LCL controls. TToolButton and TToolBar are also custom controls. AFAIK Marc wanted to replace eventually TToolBar/TToolButton with real widgets (not LCL drawn). Yes, and I wanted that too, but this is not easy since gtk, win32, carbon and qt needs implementation in one moment. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] c++ to object pascal converter
Hi, Is there any automatic C++ to Object Pascal converter? I am thinking of porting a C++ game to Object Pascal and want to have some code as a basic to work with. It's enough if just the syntax got translated and some easy designed objects. Greetings, Albert _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gaertner wrote: Al Boldi [EMAIL PROTECTED] wrote: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Partially. The codetools already support three 'languages': pascal (delphi, objfpc, parts of macpas, parts of tp), lfm and pascal directives. The file caches could and should be used (for speed and for integrity with the other IDE tools). The code trees can be used (with other constants). Then some ctags functions should be added to the TCodeToolManager for easy handling. Finally some IDE features could use the ctags information. e.g. method jumping and code explorer. Of course ctags is a pretty simple parser and can not be used to parse macros correctly. And of course the file interdependencies can not be handled neither, as this requires a C IDE, which is not the goal of lazarus. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] generics
Hi, If have just googled a bit about Generics in FPC and the Lazarus Wiki says that they are implemented since FPC 2.3.1. How is the current state? Are they used? Are all the common containers (like list, vector, map, etc.) available as generic classes? In the FPC reference, it seems that a lot of parts are not implemented yet (function generics, operators). Regards, Albert _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
Graeme Geldenhuys ha scritto: [...I forgot the attachment size limit so split the email in two...] -- Forwarded message -- From: Graeme Geldenhuys [EMAIL PROTECTED] Date: 22 Jan 2008 09:33 Subject: Lazarus compiled with GTK2 To: lazarus@miraclec.com Hi, Every couple of months I try Lazarus compiled with GTK2. In the end I still find GTK1 much better, though GTK2 has improved a lot since my last attempt. I attached a few images show some strange positioning and sizing... GTK1 and Win32 are perfect on these screens. All screenshots are from the Editor Options dialog in Lazarus. Does anybody else experience the same screen positioning / sizing issue with GTK2? I've had the same experiences. You didn't see the problem with TButton: the only way to display a visible caption is to use AutoSize (otherwise you loose the bottom half of fonts), but then the button is resized also in x, which isn't always what you want/need. Moreover, until last time I tested, z-order wasn't implemented, TPanel didn'have a border, etc. etc. I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Paul Ishenin ha scritto: Mattias Gärtner wrote: GtkApiWidget is a special widget for custom controls, which do everything themselves. It is not for regular LCL controls. TToolButton and TToolBar are also custom controls. AFAIK Marc wanted to replace eventually TToolBar/TToolButton with real widgets (not LCL drawn). Yes, and I wanted that too, but this is not easy since gtk, win32, carbon and qt needs implementation in one moment. You see what I mean? Moving implementation from LCL to widgetset is simply the WRONG way to go. It pushes Lazarus 1.0 farther away each day. Attached a screenshot of the Configure Custom Tools Dialog, which used to show just fine. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) inline: Tools.png
Re: [lazarus] What is wrong with the Toolbar?
On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Moving implementation from LCL to widgetset is simply the WRONG way to go. Then use fpGUI or mseGUI. This is not wrong way, it is way selected by lazarus team long time ago. Custom controls cannot bring native functionality - only imitation of it. This is not what we want and what we need. Okay, I'll shut up now. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Michael Van Canneyt ha scritto: On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. It provides properties and methods which are in most cases self-explanatory. The Color Property of a Form or of a Button dictates its color. Well, try just to set this property to clRed, or clButtonFace with different widgesets, and compare the behavior. This is a question of priority. Some widgetset developers and some lazarus developers think that changing the 'color' is seldom a good solution and so they don't invest time on this. So it is up to those who think, that this property is useful to implement and maintain it. If the implementation breaks other features then the developers have to decide what is more important. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Or they could achieve native look just by using a Bitmap, and consistent behavior with code in LCL, with less duplicated work, less bugs, and better results. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. When you're told that the feature can't be implemented because the widgetset doesn't support it, you stop reporting. When you see that the development line is to move the implementation from LCL to widgetset, instead of the opposite, (and breaking what was already working in the process), you stop providing patches, and start whining. :-( Breaking is bad, but sometimes inevitable. For example Drag and Drop was improved in the LCL/gtk, but without a proper threshold, so treeviews become unusable on some machines. I will not complain, because the general direction is right and if no one fixes it I will fix it myself. Even though I already fixed it in the past. About: move from LCL to widgetset That was the goal of lazarus from the beginning. If you want a visual component library with a minimal backend, then use fpGUI or msegui. Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). So basically every drawing should be avoided in the LCL or at least use only high level drawing functions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
On Jan 22, 2008, at 1:31 PM, Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) I've tried to use Lazarus/GTK2 for half a day now. It's horribly slow as well, compared to GTK1. For now I switched back to GTK1 and will try GTK2 in a few months again. May be but GTK1 does not use UTF8. -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) I've tried to use Lazarus/GTK2 for half a day now. It's horribly slow as well, compared to GTK1. For now I switched back to GTK1 and will try GTK2 in a few months again. I fear that won't change much, gtk2 itself is slower than gtk1 due to all clientside graphic stuff Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Giuliano Colla wrote: Paul Ishenin ha scritto: Mattias Gärtner wrote: GtkApiWidget is a special widget for custom controls, which do everything themselves. It is not for regular LCL controls. TToolButton and TToolBar are also custom controls. AFAIK Marc wanted to replace eventually TToolBar/TToolButton with real widgets (not LCL drawn). Yes, and I wanted that too, but this is not easy since gtk, win32, carbon and qt needs implementation in one moment. You see what I mean? Moving implementation from LCL to widgetset is simply the WRONG way to go. Then use fpGUI or mseGUI. This is not wrong way, it is way selected by lazarus team long time ago. Custom controls cannot bring native functionality - only imitation of it. This is not what we want and what we need. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Yes, and I wanted that too, but this is not easy since gtk, win32, carbon and qt needs implementation in one moment. You see what I mean? Moving implementation from LCL to widgetset is simply the WRONG way to go. It pushes Lazarus 1.0 farther away each day. I can't agree more. And it's a lot more work. One implementation now becomes 4 and the more widget sets we support, the worse it gets. A year or so ago, Lazarus became more and more stable over time (talking about trunk versions, not release versions). In the last few months things seem to be going the other way round - more and more things that used to work are being broken. :-( Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) I've tried to use Lazarus/GTK2 for half a day now. It's horribly slow as well, compared to GTK1. For now I switched back to GTK1 and will try GTK2 in a few months again. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Paul Ishenin ha scritto: Giuliano Colla wrote: Paul Ishenin ha scritto: Mattias Gärtner wrote: GtkApiWidget is a special widget for custom controls, which do everything themselves. It is not for regular LCL controls. TToolButton and TToolBar are also custom controls. AFAIK Marc wanted to replace eventually TToolBar/TToolButton with real widgets (not LCL drawn). Yes, and I wanted that too, but this is not easy since gtk, win32, carbon and qt needs implementation in one moment. You see what I mean? Moving implementation from LCL to widgetset is simply the WRONG way to go. Then use fpGUI or mseGUI. This is not wrong way, it is way selected by lazarus team long time ago. Custom controls cannot bring native functionality - only imitation of it. This is not what we want and what we need. The only problem is that you have another goal which is to be Delphi compatible. When two goals are in conflict, as they are, you should make a choice. Either drop Delphi compatibility and use native widgetsets, or drop native widgesets. Of course I can take my own way, but when you see friends taking a way which leads to nowhere, you feel your duty to prevent them. Then it's up to them to decide. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Op dinsdag 22-01-2008 om 15:03 uur [tijdzone +0200], schreef Graeme Geldenhuys: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? Hindsight is a awesome thing. :-) For me: if Lazarus woudn't use native widgets, I woudn't use it. It's one of the most important features for me. Else I could also use Java, for example. for me the main issue with Java is that it doesn't 'feel' native for most users. Joost _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Damien Gerard ha scritto: On Jan 21, 2008, at 10:03 PM, Graeme Geldenhuys wrote: On 21/01/2008, Den Jean [EMAIL PROTECTED] wrote: On Monday 21 January 2008 01:18:56 pm Giuliano Colla wrote: Either one takes the Qt way, i.e. using style to *mimic* the native *look*, without actually using it, and provides a consistent behavior, this does not honour the huge Qt effort. Qt DOES use the native widget when necessary do have native look for XP, Vista and Mac OS X style. This is why these styles are not available on the other platforms because the lack of the native widget set library. Nope, it's like I explained before. Qt does all custom painting, it does not required the underlying 'native' widgets. They used to copy the look of OS's by manually drawing all controls. Since late 3.x or starting with 4.x (not sure which version) Qt under XP, Vista, MacOS X and GTK asks the corresponding component (via native API) to draw itself on a memory bitmap. Qt then paints that bitmap to the correct location on the form. This overcomes the issue when user install there own custom themes. Qt does not create a instance of the native widget. For others I don't know but for Carbon I have a big doubt. It's virtually impossible to support styles (which can be changed at run-time, don't forget) and actually use native widgetsets. This would mean dynamically readjust all dependencies, taking into account the different implementation whims. They would be fools, and they aren't. From Qt4 sources (Qtstyle.cpp): /quote Qt contains a set of QStyle subclasses that emulate the styles of the different platforms supported by Qt (QWindowsStyle, QMacStyle, QMotifStyle, etc.). By default, these styles are built into the QtGui library. Styles can also be made available as plugins. Qt's built-in widgets use QStyle to perform nearly all of their drawing, ensuring that they look exactly like the equivalent native widgets. The diagram below shows a QComboBox in eight different styles. quote/ Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? Hindsight is a awesome thing. :-) Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. As I mentioned before. This is very easy to achieve - Trolltech has proved this. Simply ask the native widget to draw itself on a memory bitmap. All native toolkits send out a message when the theme changes, so it's very easy to detect that as well. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). All this can be implemented in a custom drawn toolkit. At least that way all platforms will have these features. Currently only GTK Notebook has tab menu for example. LCL now needs to support a basic set of features which are common to all widget sets - nothing more otherwise it's not compatible across widget sets. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
On 22/01/2008, Damien Gerard [EMAIL PROTECTED] wrote: May be but GTK1 does not use UTF8. And GTK2 doesn't support Raize Font. :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
Marc Weustink wrote: Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) I've tried to use Lazarus/GTK2 for half a day now. It's horribly slow as well, compared to GTK1. For now I switched back to GTK1 and will try GTK2 in a few months again. I fear that won't change much, gtk2 itself is slower than gtk1 due to all clientside graphic stuff Gtk2 is in fact slower than Gtk1, every one agree, but LCL/Gtk2 application are much slower than other Gtk2 applications Luiz _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? I would optimize it for smart linking and a console widgetset. Hindsight is a awesome thing. :-) Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. As I mentioned before. This is very easy to achieve - Trolltech has proved this. Simply ask the native widget to draw itself on a memory bitmap. All native toolkits send out a message when the theme changes, so it's very easy to detect that as well. Why should qt render a native button, if they can draw a qt button with a 'native' looking theme? Are you sure, that qt uses native widgets? - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). All this can be implemented in a custom drawn toolkit. Yes, by reinventing the wheel. At least that way all platforms will have these features. Currently only GTK Notebook has tab menu for example. A Mac user will be confused if she sees this menu. A disabled person wants to use his OS features and not setup this for each program. LCL now needs to support a basic set of features which are common to all widget sets - nothing more otherwise it's not compatible across widget sets. Only the API is limited to the common features. The program is not limited. As said above: You get extra features of the widgetset. And if a programmer needs uncommon things, he can write a specific control. See for example the printers4lazarus or the lazopenglcontext package. They started on one platform and nowadays they run on all majors. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
On Jan 22, 2008, at 1:51 PM, Graeme Geldenhuys wrote: On 22/01/2008, Damien Gerard [EMAIL PROTECTED] wrote: May be but GTK1 does not use UTF8. And GTK2 doesn't support Raize Font. :) Which I don't care since it is displaying my japanese texts :) -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Mattias Gärtner wrote: Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gaertner wrote: Al Boldi [EMAIL PROTECTED] wrote: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Partially. The codetools already support three 'languages': pascal (delphi, objfpc, parts of macpas, parts of tp), lfm and pascal directives. The file caches could and should be used (for speed and for integrity with the other IDE tools). The problem with the caches is that they are somewhat misleading when you start changing the code, and then forget to reindex. So doing it on-the-fly should be much safer and faster for large trees. The code trees can be used (with other constants). Then some ctags functions should be added to the TCodeToolManager for easy handling. Finally some IDE features could use the ctags information. e.g. method jumping and code explorer. Of course ctags is a pretty simple parser and can not be used to parse macros correctly. And of course the file interdependencies can not be handled neither, as this requires a C IDE, which is not the goal of lazarus. I think the least we should handle are the #include's, otherwise the on-the-fly ctags may not work. Parsing the files for #include's should be easy, right? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Graeme Geldenhuys wrote:
On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote:
Moving implementation from LCL to widgetset is simply the WRONG way to
go.
Then use fpGUI or mseGUI. This is not wrong way, it is way selected by
lazarus team long time ago. Custom controls cannot bring native
functionality - only imitation of it. This is not what we want and what
we need.
Okay, I'll shut up now.
Before you do that, I just tried fpGUI and it didn't compile due to cursorfont
unit missing.
So I added {$include cursorfont.inc} from fpc/packages/extra/forms, then it
compiles ok,
but I get this crash on run using fpc2.0.2:
An unhandled exception occurred at $08055F23 :
EAccessViolation : Access violation
$08055F23 TNETWINDOWLAYER__UPDATESUPPORTEDATOMS, line 296 of _netlayer.pas
$08057856 TNETWINDOWLAYER__CREATE, line 1021 of _netlayer.pas
$08051DCD TFPGWINDOWIMPL__DOSETWINDOWTITLE, line 1202 of gfx_x11.pas
$08055A01 TFPGFORM__SETWINDOWPARAMETERS, line 171 of gui_form.pas
$08051A79 TFPGWINDOWIMPL__DOALLOCATEWINDOWHANDLE, line 1090 of gfx_x11.pas
$0804E0C6 TFPGWINDOWBASE__ALLOCATEWINDOWHANDLE, line 718 of gfxbase.pas
$08054845 TFPGWIDGET__HANDLESHOW, line 468 of gfx_widget.pas
$08055C8E TFPGFORM__HANDLESHOW, line 239 of gui_form.pas
$08055B63 TFPGFORM__SHOW, line 197 of gui_form.pas
$0808C876 TMAINDESIGNER__CREATEWINDOWS, line 287 of vfdmain.pas
$08078866 MAINPROC, line 38 of uidesigner.lpr
How can this be fixed?
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
On Tue, 22 Jan 2008 14:15:03 +0100 Giuliano Colla [EMAIL PROTECTED] wrote: The only problem is that you have another goal which is to be Delphi compatible. When two goals are in conflict, as they are, you should make a choice. Either drop Delphi compatibility and use native widgetsets, or drop native widgesets. Great Idea. Drop Delphi compatibility now. Drop it I say. Do you here me, Delphi, go away. Just my 1.57$ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Everything has its ups and downs. But the nice thing about Lazarus is that it can use for instance FPGUI, which will work on all platforms, hence rendering the whole discussion moot. I was waiting for another 50 or so replies before mentioning that ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gärtner wrote: Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gaertner wrote: Al Boldi [EMAIL PROTECTED] wrote: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Partially. The codetools already support three 'languages': pascal (delphi, objfpc, parts of macpas, parts of tp), lfm and pascal directives. The file caches could and should be used (for speed and for integrity with the other IDE tools). The problem with the caches is that they are somewhat misleading when you start changing the code, and then forget to reindex. So doing it on-the-fly should be much safer and faster for large trees. I can't follow you here. I was talking about the caches for files. For example the cache for the file unit1.pas. The pascal parser reads and creates a code tree. This code tree is cached as well, but this is another cache and can not be used by the ctags. I only said, that the plugin should use the file caches instead of accessing the files on disk directly. The code trees can be used (with other constants). Then some ctags functions should be added to the TCodeToolManager for easy handling. Finally some IDE features could use the ctags information. e.g. method jumping and code explorer. Of course ctags is a pretty simple parser and can not be used to parse macros correctly. And of course the file interdependencies can not be handled neither, as this requires a C IDE, which is not the goal of lazarus. I think the least we should handle are the #include's, otherwise the on-the-fly ctags may not work. Parsing the files for #include's should be easy, right? I'm no ctags expert. I don't know if ctags has a preprocessor. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Mattias Gärtner ha scritto: Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Michael Van Canneyt ha scritto: On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. It provides properties and methods which are in most cases self-explanatory. The Color Property of a Form or of a Button dictates its color. Well, try just to set this property to clRed, or clButtonFace with different widgesets, and compare the behavior. This is a question of priority. Some widgetset developers and some lazarus developers think that changing the 'color' is seldom a good solution and so they don't invest time on this. So it is up to those who think, that this property is useful to implement and maintain it. If the implementation breaks other features then the developers have to decide what is more important. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Or they could achieve native look just by using a Bitmap, and consistent behavior with code in LCL, with less duplicated work, less bugs, and better results. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. When you're told that the feature can't be implemented because the widgetset doesn't support it, you stop reporting. When you see that the development line is to move the implementation from LCL to widgetset, instead of the opposite, (and breaking what was already working in the process), you stop providing patches, and start whining. :-( Breaking is bad, but sometimes inevitable. For example Drag and Drop was improved in the LCL/gtk, but without a proper threshold, so treeviews become unusable on some machines. I will not complain, because the general direction is right and if no one fixes it I will fix it myself. Even though I already fixed it in the past. About: move from LCL to widgetset That was the goal of lazarus from the beginning. If you want a visual component library with a minimal backend, then use fpGUI or msegui. Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). So basically every drawing should be avoided in the LCL or at least use only high level drawing functions. Well, I can't claim that I only hold the truth, and everybody else is wrong. But I can claim to represent a part of the outside world, those who are USING Delphi,Lazarus, etc. to develop applications, and who make a living out of it. I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) I presume i didn't do it so badly, because I never missed a meal, and the only customers I've ever lost are those who died of old age (sadly too many, now that I think of it). I could happily retire now, weren't that I still have fun doing what I'm doing. Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Recently I've visited a customer which has still an old text-style implementation (sort of custom ncurses) and when I proposed a GUI interface, he reacted: Provided it's not Windows-like. We have already had this bad experience. We want something user oriented, not Windows oriented!. Then I showed him some samples and he
Re: [lazarus] Introduction
On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: Why should qt render a native button, if they can draw a qt button with a 'native' looking theme? Are you sure, that qt uses native widgets? Qt has built-in themes (custom coded) and also allows for hooking into the native widgets theme manager. Take Windows XP for example: By simply hooking into the UxTheme API, your custom toolkit can look like any Windows XP theme. Trolltech does similar. All this can be implemented in a custom drawn toolkit. Yes, by reinventing the wheel. Yeah but it would be a 'super' wheel that fits and works on all cars! :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] c++ to object pascal converter
On Jan 22, 2008 11:29 AM, Albert Zeyer [EMAIL PROTECTED] wrote: Hi, Is there any automatic C++ to Object Pascal converter? I am thinking of porting a C++ game to Object Pascal and want to have some code as a basic to work with. It's enough if just the syntax got translated and some easy designed objects. Greetings, Albert Hi, Recently I have used C to Pascal Converter to convert a simple project with some success (but the generated code has to be reviewed) Link: http://codecentral.borland.com/Item/23991 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
I don't know whether the Toolbar has been correctly fixed (bug 0010530: Toolbar background not painted), but bug 0010562: (LazDe toolbar shows previous background) certainly has not been resolved - I had assumed it was a consequence of the previous bug, and should be resolved when it was fixed, but this has not happened. Regards - Chris _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Lord Satan [EMAIL PROTECTED] wrote: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. Have a look on SourceForge. I have seen quite a few toolkits implemented in C/C++ and uses OpenGL or SDL or whatever hw acceleration they picked. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). I only develop commercial applications with Lazarus and from judging by all these conversations, it seems like we are the only two. Also we seem to experience the same issues - coincidence? What does everyone else use Lazarus for? Console apps maybe? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 16:20:57 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 22/01/2008, Lord Satan [EMAIL PROTECTED] wrote: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. Have a look on SourceForge. I have seen quite a few toolkits implemented in C/C++ and uses OpenGL or SDL or whatever hw acceleration they picked. SDL is no acceleration, only if you use its OpenGL wrapper functionality you get hw acceleration. I know a lot of those 'widgetsets', too, but they are meant for OpenGL apps and they are not general purpose widgetsets like WIN API, GTK, QT, etc. Most of them are very basic tools to provide GUIs for 3D apps. So I would really like to know of at least one specific one. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Mac OS X : TBitBtn Transparency
On Jan 11, 2008 10:09 AM, Dominique Louis [EMAIL PROTECTED] wrote: Hi Paul, Does this mean that TBitBtn under Mac OS X does not support transparency for Bitmaps only via PNGs? I just searched through the code and the Mac OS X Function TButtonGlyph.Draw() in buttonglyph.inc is a bit sparse and there is no code there makes use of the passed in Transparency. I also noticed in TCustomBitBtn.ActionChange/CopyImage it has a // TODO : Transparency comment. So I'm guessing it's not done yet. It used to work, but after bitmap rewrite (which moved transparency in TBitmap to mask) it was broken. I hope, I have fixed it in latest SVN. Tom _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 15:28:15 +0100 Mattias Gärtner [EMAIL PROTECTED] wrote: Zitat von Lord Satan [EMAIL PROTECTED]: @Mattias: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. For example: -gtk on embedded devices can render directly to the framebuffer. -trolltech advertises hardware accelerations on their website, but I don't know if this available for free. -afaik carbon uses some opengl hw acceleration -And all widgetsets use some hand tuned graphic libs using vector libs or sse instructions. Looks like we have different definitions of hw acceleration. If it is not D3D/OpenGL/OpenES it is not accelerated in my book (hw acceleration = gfx card does the job, and no the standard 2D acceleration from 20 years ago does not count). Perhaps carbon qualifies but I don't know enough about its interiors or better I don't how the textures are created that they pass to OpenGL. And would you please stop talking about SSE. ASM _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Lord Satan [EMAIL PROTECTED]: [..] - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). @Mattias: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. For example: -gtk on embedded devices can render directly to the framebuffer. -trolltech advertises hardware accelerations on their website, but I don't know if this available for free. -afaik carbon uses some opengl hw acceleration -And all widgetsets use some hand tuned graphic libs using vector libs or sse instructions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). Well, I develop major database projects (in Delphi), and none of our customers has ever asked for a specific look. So I would be the last to ask this from lazarus. The thing I am looking for is portability. Most of our users hardly understand windows, let alone that they would require a specific (and hence more confusing) look for our application. By keeping it close to the windows standards, we make the application less frightful for them. And we have many thousands of such users. As in all things, it is dangerous to generalize your own experience. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 17:02:08 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: No, the ones I looked at was for creating standard applications (not games). They just used shadow events under menus, dropdown animation, etc... On my system the composition manager does this work not the widgetset. Sometimes people have strange ideas. I'll see if I can find them again. This would be nice. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Graeme Geldenhuys schreef:
As for the latest trunk revision of fpGUI (actually the last week or
so) it's been a bit unstable with verbose output. I'm hunting down a
few bugs and added lots of debug code in there to test between the
supported platforms. It should be back to normal by the end of the
week. [Next time I'll use a private branch for such verbose debugging]
You could also add them with {$IFDEF VerboseDebugFewBugs} and use
-dVerboseDebugFewBugs in your private builds.
Vincent
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 14:50:16 +0100 Mattias Gärtner [EMAIL PROTECTED] wrote: And if a programmer needs uncommon things, he can write a specific control. See for example the printers4lazarus or the lazopenglcontext package. They started on one platform and nowadays they run on all majors. More or less. I just can't hunt down the lazopenglcontext GTK2 resize bug. But I keep trying. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Well, Lazarus is intended to develop commercial applications, not GPL utilities to be added to Gnome desktop. Oops. Sorry, I didn't know. Commercial applications take care to provide their own specific look. If we look at some widely known multiplatform applications, we find that Red Hat created it's specific Bluecurve style, in order to avoid the native look of gtk, and provide uniform RedHat style to Gnome and Kde desktops. ... and RedHat achieved that, because the programs follow the system settings. OpenOffice, Mozilla, Gimp, Acrobat Reader (to some extent), Qt Designer, not to speak of players like Winamp or XMMS provide the same look in all platforms, with OpenOffice and Acrobat going to the point of using only their own fonts. Mozilla is using gtk under linux. OpenOffice descended from StarOffice, which look much more the same on all platforms. With every new version OO is becoming more native looking on all platforms. Gimp - it invented gtk. ... Moreover multiplatform doesn't mean adding up all limitations of the supported platforms, but rather providing a consistent look and behavior in different platforms, with minimal programmer extra work. We are trying to improve the LCL to minimize the programmer work. But we don't have the man power of Graeme and Martin, so either be patient or use fpGUI/msegui/qt/gtk/wxWidgets/... . Of course, I can take a different path for myself (fpGUI, msegui, MyOwnGui), but I feel belonging to Lazarus community, I see a lot of work being done, a lot of impressing achievements whenever the sacred cows of Delphi compatibility and widgetset compliance are forgotten, such as in component anchoring or in IDE conception. Therefore, backed by my personal experience, I feel it right to raise doubts on the priorities you clearly indicated, and humbly suggest that it could be the time to reconsider them with open mind. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
On 22/01/2008, Al Boldi [EMAIL PROTECTED] wrote:
Before you do that, I just tried fpGUI and it didn't compile due to
cursorfont unit missing.
So I added {$include cursorfont.inc} from fpc/packages/extra/forms, then it
compiles ok,
but I get this crash on run using fpc2.0.2:
The last time I tested it worked fine with 2.0.4 and 2.2.0. I honestly
don't see the point in supporting all old versions of FPC when you can
upgrade for free. So if you can, please upgrade to fpc 2.0.4 or
preferably 2.2.0. I tend to only support the last two FPC versions
until I know the latest FPC release has proven itself to be truly
stable, then I start using features of that (latest) release.
As far as I can see the 'cursorfont' unit in X11's backed comes from
fpcsrc/packages/extra/x11/cursorfont.pp
Is there any specific reason you are stuck with 2.0.2 and can't
upgrade? If it's a good reason, I can consider adding a IFDEF in the
code.
As for the latest trunk revision of fpGUI (actually the last week or
so) it's been a bit unstable with verbose output. I'm hunting down a
few bugs and added lots of debug code in there to test between the
supported platforms. It should be back to normal by the end of the
week. [Next time I'll use a private branch for such verbose debugging]
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Lord Satan [EMAIL PROTECTED] wrote: SDL is no acceleration, only if you use its OpenGL wrapper functionality you get hw acceleration. That's what I meant with SDL. I know a lot of those 'widgetsets', too, but they are meant for OpenGL apps and they are not general purpose widgetsets like WIN API, GTK, QT, etc. Most of them are very basic tools to provide GUIs for 3D apps. So I would really like to know of at least one specific one. No, the ones I looked at was for creating standard applications (not games). They just used shadow events under menus, dropdown animation, etc... I'll see if I can find them again. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 16:30:48 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: What does everyone else use Lazarus for? Console apps maybe? For me it is just a hobby (at work there is only C++ and no chance to ever change this). As I do graphics programming I don't need a lot of GUI elements. Some Buttons, Labels, Edits, Memos, etc. The IDE is the main reason to use lazarus for me and the IDE should use native widgets to be visually pleasing to my eyes. Since I have the freedom of ignoring Windows, I am satisfied if I can get the native Linux (GTK for Gnome and QT for KDE would be nice) and OSX look. It is just my choice and another good reason to use Lazarus. And it is really ugly to have shiny 3D graphics and Motif Buttons. I really can't care less what commercial developers need and I doubt that whining on the mailing list really impresses the Lazarus developers. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] c++ to object pascal converter
Thanks for the hint. Sadly I need the same realy for C++ as most of the code is C++ based (a lot of classes). Am Dienstag, den 22.01.2008, 14:20 + schrieb Luis Quental: On Jan 22, 2008 11:29 AM, Albert Zeyer [EMAIL PROTECTED] wrote: Hi, Is there any automatic C++ to Object Pascal converter? I am thinking of porting a C++ game to Object Pascal and want to have some code as a basic to work with. It's enough if just the syntax got translated and some easy designed objects. Greetings, Albert Hi, Recently I have used C to Pascal Converter to convert a simple project with some success (but the generated code has to be reviewed) Link: http://codecentral.borland.com/Item/23991 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Lord Satan wrote: On Tue, 22 Jan 2008 14:15:03 +0100 Giuliano Colla [EMAIL PROTECTED] wrote: The only problem is that you have another goal which is to be Delphi compatible. When two goals are in conflict, as they are, you should make a choice. Either drop Delphi compatibility and use native widgetsets, or drop native widgesets. Great Idea. Drop Delphi compatibility now. Drop it I say. Do you here me, Delphi, go away. can we just stop discussions on this. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Graeme Geldenhuys wrote:
On 22/01/2008, Al Boldi [EMAIL PROTECTED] wrote:
Before you do that, I just tried fpGUI and it didn't compile due to
cursorfont unit missing. So I added {$include cursorfont.inc} from
fpc/packages/extra/forms, then it compiles ok, but I get this crash on
run using fpc2.0.2:
The last time I tested it worked fine with 2.0.4 and 2.2.0. I honestly
don't see the point in supporting all old versions of FPC when you can
upgrade for free. So if you can, please upgrade to fpc 2.0.4 or
preferably 2.2.0. I tend to only support the last two FPC versions
until I know the latest FPC release has proven itself to be truly
stable, then I start using features of that (latest) release.
As far as I can see the 'cursorfont' unit in X11's backed comes from
fpcsrc/packages/extra/x11/cursorfont.pp
Is there any specific reason you are stuck with 2.0.2 and can't
upgrade? If it's a good reason, I can consider adding a IFDEF in the
code.
Well, when Vincent starts posting incremental updates, I may actually be able
to upgrade easily.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Mattias Gärtner wrote: Zitat von Al Boldi [EMAIL PROTECTED]: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Partially. The codetools already support three 'languages': pascal (delphi, objfpc, parts of macpas, parts of tp), lfm and pascal directives. The file caches could and should be used (for speed and for integrity with the other IDE tools). The problem with the caches is that they are somewhat misleading when you start changing the code, and then forget to reindex. So doing it on-the-fly should be much safer and faster for large trees. I can't follow you here. I was talking about the caches for files. For example the cache for the file unit1.pas. The pascal parser reads and creates a code tree. This code tree is cached as well, but this is another cache and can not be used by the ctags. I only said, that the plugin should use the file caches instead of accessing the files on disk directly. Ok, then we are in agreement. I think the least we should handle are the #include's, otherwise the on-the-fly ctags may not work. Parsing the files for #include's should be easy, right? I'm no ctags expert. I don't know if ctags has a preprocessor. AFAIK it doesn't. For example ctags * only indexes the current dir, and doesn't pick up includes, whereas ctags -R does it recursively picking up the whole tree except external includes. Which means that we have to handle the #include's manually. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] sigsegv with TOpenDialog Win32(XPSP2)
strange problem that happens only if i run the program from within the
ide. A blank form, one button and a topendialog (does not matter if it
is on the form or manually created). The dialog opens and after some
seconds (sometimes i have to move the mouse), i get a sigsegv, Running
the program outside the ide (with or without gdb) works without problems.
This happens with yesterdays snapshot and with 0.9.24. (Have not tried
other versions)
Btw, the same happens with TSelectDirectoryDialog
unit Unit1;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs,
Menus, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
public
end;
var Form1: TForm1;
implementation
procedure TForm1.Button1Click(Sender: TObject);
var t : TOpenDialog;
begin
t := TOpenDialog.Create(Self);
try
t.execute;
finally
t.Free;
end;
end;
initialization
{$I unit1.lrs}
end.
gdb output
(gdb)
-environment-cd .
^done
(gdb)
-environment-cd C:/WinPrj/testopen/
^done
(gdb)
-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC
^done,value=0x0
(gdb)
-exec-arguments
^done
(gdb)
-gdb-set language pascal
^done
(gdb)
info address main
info address main\n
~Symbol \main\ is a function at address 0x4025b0.\n
^done
(gdb)
-break-insert -t *4203952
^done,bkpt={number=1,type=breakpoint,disp=del,enabled=y,addr=0x004025b0,func=main,file=project1.lpr,fullname=C:\\WinPrj\\testopen/project1.lpr,line=13,times=0}
(gdb)
-break-insert FPC_RAISEEXCEPTION
^done,bkpt={number=2,type=breakpoint,disp=keep,enabled=y,addr=0x00408d06,func=fpc_raiseexception,file=except.inc,line=189,times=0}
(gdb)
-break-insert FPC_BREAK_ERROR
^done,bkpt={number=3,type=breakpoint,disp=keep,enabled=y,addr=0x0040a1b0,func=HANDLEERRORADDRFRAME,file=system.inc,line=794,times=0}
(gdb)
-break-insert FPC_RUNERROR
^done,bkpt={number=4,type=breakpoint,disp=keep,enabled=y,addr=0x0040a2a3,func=RUNERROR,file=system.inc,line=837,times=0}
(gdb)
info file
info file\n
~Symbols from \C:/WinPrj/testopen/project1.exe\.\n
~Local exec file:\n
~\t`C:/WinPrj/testopen/project1.exe', file type pei-i386.\n
~\tEntry point: 0x4f31c0\n
~\t0x00401000 - 0x004f31e0 is .text\n
~\t0x004f4000 - 0x00534ee8 is .data\n
~\t0x00535000 - 0x00549950 is .bss\n
~\t0x0054a000 - 0x0054c520 is .idata\n
^done
(gdb)
-exec-run
^running
(gdb)
*stopped,thread-id=1,frame={addr=0x004025b0,func=main,args=[],file=project1.lpr,fullname=C:\\WinPrj\\testopen/project1.lpr,line=13}
(gdb)
info program
info program\n
~\tUsing the running image of child thread 26416.0x671c.\n
~Program stopped at 0x4025b0.\n
~It stopped at a breakpoint that has since been deleted.\n
~Type \info stack\ or \info registers\ for more information.\n
^done
(gdb)
-exec-continue
^running
(gdb)
~[Switching to thread 26416.0x6534]\n
*stopped,reason=signal-received,signal-name=SIGSEGV,signal-meaning=Segmentation
fault,thread-id=4,frame={addr=0x01fb4fa8,func=??,args=[]}
(gdb)
-stack-info-depth
^done,depth=5
(gdb)
-stack-list-arguments 1 0 0
^done,stack-args=[frame={level=0,args=[]}]
(gdb)
-stack-list-frames 0 0
^done,stack=[frame={level=0,addr=0x01fb4fa8,func=??}]
(gdb)
-stack-list-arguments 1 1 1
^done,stack-args=[frame={level=1,args=[]}]
(gdb)
-stack-list-frames 1 1
^done,stack=[frame={level=1,addr=0x021effb4,func=??}]
(gdb)
-stack-list-arguments 1 2 2
^done,stack-args=[frame={level=2,args=[]}]
(gdb)
-stack-list-frames 2 2
^done,stack=[frame={level=2,addr=0x7c92761c,func=ntdll!RtlUpcaseUnicodeStringToAnsiString,from=C:\\WINDOWS\\system32\\ntdll.dll}]
(gdb)
-stack-list-arguments 1 3 3
^done,stack-args=[frame={level=3,args=[]}]
(gdb)
-stack-list-frames 3 3
^done,stack=[frame={level=3,addr=0x7c927569,func=ntdll!RtlUpcaseUnicodeStringToAnsiString,from=C:\\WINDOWS\\system32\\ntdll.dll}]
(gdb)
-stack-list-arguments 1 4 4
^done,stack-args=[frame={level=4,args=[]}]
(gdb)
-stack-list-frames 4 4
^done,stack=[frame={level=4,addr=0x,func=??}]
(gdb)
-stack-list-frames 0 0
^done,stack=[frame={level=0,addr=0x01fb4fa8,func=??}]
(gdb)
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Which one is the best? How does OOP affect development (pros/cons)? Is there a better dev-approach than OOP? What has OOP missing? When is it wrong to use OOP? How can OOP be misused? Thanks for shedding some light! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
On 22/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote:
You could also add them with {$IFDEF VerboseDebugFewBugs} and use
-dVerboseDebugFewBugs in your private builds.
I should really do that. Thanks for the idea.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] HowTo increase developer contributions
Hi. Long time, not posting about Lazarus. Vincent Snijders wrote: So what we need it users that are willing to become contributors, not Of course, there are many, a lot of people, people that use open (or free) source software like Lazarus, and many of them request things to be done, and return nothing. Quoting Al Boldi [EMAIL PROTECTED]: in the beginning, and support them to start walking on their own, then maybe they will start to contribute, but only when you have been nice and supportive to them. But, sometimes a few of them, start getting involved, with few stuff, and eventually, get more involved. I don't expect either that a new developer builts a whole new IDE in a few days ;-) Cheers !!! mramirez _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi/Lazarus comparison by Codegear
Quoting Giuliano Colla [EMAIL PROTECTED]: I stumbled, by chance, into a rather fair comparison of Delphi and Lazarus in the Delphi Wiki: http://delphi.wikia.com/wiki/The_Business_Case_For_Delphi#FreePascal.2FLazarus_.28FP.2FLZ.29 I wonder if there should be a The case against Delphi by the Lazarus community article ;-) Seems the CodeGear guys forgot that many people start getting interested in Lazarus, as plain users or active developers, because they where previous Delphi users, and when Borland (now CodeGear) crap the quality of the product, the people turn into open source... Just my 2c !!! mramirez _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Well, I develop major database projects (in Delphi), and none of our customers has ever asked for a specific look. So I would be the last to ask this from lazarus. The thing I am looking for is portability. Our clients normally don't want way-out looking apps. They simply want some customizations using various colors for example. Validation screens must change background colors of components to indication an error state or missing input, Label colors indicating some or other business status etc... As you can see, I'm not talking about triangular buttons or odd shaped forms - just subtle customizations. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Fast math library
Hi everyone, I just cannot believe that I am the only Lazarus user that writes computational intensive programs. There must be others. If you are one of them I would be really interested to know what math libraries you use to achieve the best performance you can get. AFAIK there are no SSE enhanced libs for FPC and my own experiments failed miserably with SSE enhanced code being slower than standard pascal code. Sorry for being OT and thanks for any help. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Al Boldi schreef: Is there any specific reason you are stuck with 2.0.2 and can't upgrade? If it's a good reason, I can consider adding a IFDEF in the code. Well, when Vincent starts posting incremental updates, I may actually be able to upgrade easily. Are you referring to me? If so, what exactly are you talking about? Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
Armin Diehl schreef: strange problem that happens only if i run the program from within the ide. A blank form, one button and a topendialog (does not matter if it is on the form or manually created). The dialog opens and after some seconds (sometimes i have to move the mouse), i get a sigsegv, Running the program outside the ide (with or without gdb) works without problems. This happens with yesterdays snapshot and with 0.9.24. (Have not tried other versions) Btw, the same happens with TSelectDirectoryDialog Also reported as http://bugs.freepascal.org/view.php?id=10409 idea Maybe I should recompile my LCL without unicode support, so I can see this bug. /idea Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
On 22/01/2008, Al Boldi [EMAIL PROTECTED] wrote: Is there any specific reason you are stuck with 2.0.2 and can't upgrade? If it's a good reason, I can consider adding a IFDEF in the code. Well, when Vincent starts posting incremental updates, I may actually be able to upgrade easily. Sorry, I don't understand what you mean. Can you explain a bit more? Incremental updates of what? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Vincent Snijders wrote: Al Boldi schreef: Is there any specific reason you are stuck with 2.0.2 and can't upgrade? If it's a good reason, I can consider adding a IFDEF in the code. Well, when Vincent starts posting incremental updates, I may actually be able to upgrade easily. Are you referring to me? If so, what exactly are you talking about? Sorry Vincent, but I thought you were the person responsible for packaging. I am currently on 2.0.2, and when wanting to upgrade to a new stable-release there should be a way to download only an incremental update like: 2.0.2-2.0.4.tgz and 2.0.4-2.2.0.tgz. Same goes for laz stable-releases. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Al Boldi schreef: Vincent Snijders wrote: Al Boldi schreef: Is there any specific reason you are stuck with 2.0.2 and can't upgrade? If it's a good reason, I can consider adding a IFDEF in the code. Well, when Vincent starts posting incremental updates, I may actually be able to upgrade easily. Are you referring to me? If so, what exactly are you talking about? Sorry Vincent, but I thought you were the person responsible for packaging. I am currently on 2.0.2, and when wanting to upgrade to a new stable-release there should be a way to download only an incremental update like: 2.0.2-2.0.4.tgz and 2.0.4-2.2.0.tgz. Same goes for laz stable-releases. I am of the people responsible for packaging Lazarus releases. If you want incremental upgrades, I suggest you start using svn. Start with svn co http://svn.freepascal.org/svn/fpc/tags/release_2_0_2 fpc-release. Then you could do an incremental update by (all on one line): svn switch http://svn.freepascal.org/svn/fpc/tags/release_2_0_2 http://svn.freepascal.org/svn/fpc/tags/release_2_2_0 fpc-release IMHO zipped incremental updates are impossible, because you cannot zip file removals. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
Vincent Snijders ha scritto: idea Maybe I should recompile my LCL without unicode support, so I can see this bug. /idea I'trying to track som bugs which may be unicode related. Could you save me a lot of search telling me what I should setup in order to compile LCL without unicode support? Thanks in advance. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
Giuliano Colla schreef: Vincent Snijders ha scritto: idea Maybe I should recompile my LCL without unicode support, so I can see this bug. /idea I'trying to track som bugs which may be unicode related. Could you save me a lot of search telling me what I should setup in order to compile LCL without unicode support? Nothing. On win32, LCL without unicode support is still the default. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Vincent Snijders wrote: IMHO zipped incremental updates are impossible, because you cannot zip file removals. I think you can, like this: diff -ruNp file.pas /dev/null file.diff patch file.diff This removes the file. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] TStringGrid.Columns.SizePriority
Hi all, I have some TStrigGrid's on a form with AutoFillColumns := true; I was monkeying around with SizePriority trying to figure out what it did by setting a few columns' SizePriority to 2. At any rate, when running the app with heaptrc active it reports the following on application close: M:\lazarus\projects\maestro\maestro.exe Heap dump by heaptrc unit 17744 memory blocks allocated : 584450/634648 17732 memory blocks freed : 584402/634552 12 unfreed memory blocks : 48 True heap size : 1081344 (112 used in System startup) True free heap : 1080272 Should be : 1080464 Call trace for block $015E38A0 size 4 $004ECC93 TGRIDCOLUMN__SETSIZEPRIORITY, line 8536 of Grids.pas $00441A37 SETORDPROP, line 896 of C:/temp/lazbuild/fpc-patched/rtl/objpas/typinfo.pp $0042C2CC TREADER__READPROPVALUE, line 1104 of C:/temp/lazbuild/fpc-patched/rtl/objpas/classes/reader.inc $0042BDD9 TREADER__READPROPERTY, line 1047 of C:/temp/lazbuild/fpc-patched/rtl/objpas/classes/reader.inc $0042B10B TREADER__READCOLLECTION, line 685 of C:/temp/lazbuild/fpc-patched/rtl/objpas/classes/reader.inc $0042C55A TREADER__READPROPVALUE, line 1165 of C:/temp/lazbuild/fpc-patched/rtl/objpas/classes/reader.inc $0042BDD9 TREADER__READPROPERTY, line 1047 of C:/temp/lazbuild/fpc-patched/rtl/objpas/classes/reader.inc $0042B8AF TREADER__READDATA, line 856 of C:/temp/lazbuild/fpc-patched/rtl/objpas/classes/reader.inc There appears to be a reported leak like that one above, for each TStringGrid on the form that has those particular properties mentioned above. When setting SizePriority back to 1 for every column on every grid, the problem seems to go away: M:\lazarus\projects\maestro\maestro.exe Heap dump by heaptrc unit 17511 memory blocks allocated : 571010/620600 17511 memory blocks freed : 571010/620600 0 unfreed memory blocks : 0 True heap size : 1048576 (112 used in System startup) True free heap : 1048464 I don't actually need SizePriority set to anything other than 1, I was just messing around, but thought I'd report it. This is Lazarus 0.9.24 and FPC 2.2.0 from sourceforge .24 installer. -- Warm Regards, Lee Everything I needed to learn in life, I learned selling encyclopedias door to door. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Al Boldi ha scritto: Giuliano Colla wrote: I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Compiled languages: 1) Assembler from HP minicomputers to IBM mainframes (including an incredible Siemens computer, which at start-up was typing an obscure message in german: if you just typed return, it would take the default action, i.e. assume a new installation and reformat its hard disks! :-) ) , and then micros for all the Intel Family, from 4004 (it was a nightmare, three instructions to read a memory location but with good macros you could get away) to nowadays Pentium 2) Fortran (different flavors in time) 3) Algol 60 4) Intel's PLM's: PLM48 PLM51 PLM80 PLM86 PLM386 5) C 6) C++ 7) Delphi Pascal 8) Free Pascal Interpreted Languages: 9) Basic 10) Visual Basic 11) Python 12) Tcl/Tk Possibly I've left out some, but that's more or less the picture. Which one is the best? Among non OOPL PLM was certainly the best, both in terms of code efficiency and in clean syntax, with the best way I've ever met to deal cleanly with typed pointers (nothing to do with the C mess). It made almost possible to make it become an OOPL, with a minimal extra work. Among OOPL doubtlessly Pascal. However it's a matter of goal. You always end up with native computer instructions: the best language is the one which gives you the best compromise in terms of development costs, maintenance costs, and performance. If the language is good, but the compiler fails to provide efficient code, then it's not the right choice. That's why IBM's PL1 was a failure. How does OOP affect development (pros/cons)? Well designed objects provide the two features of reusability and hidden implementation, which strongly reduces development/debug time. But you must be careful. The clean syntax of Pascal, the clean separation between Interface and implementation encourages to provide good objects. Can't say the same for C++. Bad C habit of making public whatever isn't declared static, or to let through implicit declarations can lead to strange bugs very hard to detect. The con's are that it may encourage lazyness. You may end up using an object because it's ready made, taking advantage of a minimal part of its features, and making your code bigger and slower, and maybe harder to debug, when a small subroutine could have served the same purpose. Is there a better dev-approach than OOP? There's never a best for all approach. If I need to test a formula, Basic is still the best language. If I need a device driver, I may find out that I get the required efficiency only by assembler. Each problem requires the appropriate tools. Tombstones are made of stone. It's a stone-age technology, but it's the most appropriate to cover a grave. What has OOP missing? Well, standard C++ misses the property assignement, unless you go through the chore of overloading the '=' operator. For the rest I'm quite happy with it. When is it wrong to use OOP? Whenever it's not appropriate. How can OOP be misused? Using it when not appropriate. Thanks for shedding some light! Go and be content, my young friend. Study, when you've learned start coding, and don't sin any more. (I can detect sarcasm at least since as long as I have been programming, but your questions deserved a reply nonetheless). Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys ha scritto: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). I only develop commercial applications with Lazarus and from judging by all these conversations, it seems like we are the only two. Also we seem to experience the same issues - coincidence? It's the two of us against the rest of the world, one would say! :-) What does everyone else use Lazarus for? Console apps maybe? I can't say. I read that someone is *using* gtk2. I tried to make a form with a button, and the lower half of the caption was lost. I tried to put a panel with a memo on the form, and I could see the panel through the memo (or the opposite, I don't remember). From time to time I recover my test form, retry it and the situation hasn't changed. I would never think that it's usable. But someone claims to use it. What for is a mystery for me. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TStringGrid.Columns.SizePriority
--- Lee Jenkins [EMAIL PROTECTED] escribió: Hi all, I have some TStrigGrid's on a form with AutoFillColumns := true; I was monkeying around with SizePriority trying to figure out what it did by setting a few columns' SizePriority to 2. At any rate, when running the app with heaptrc active it reports the following on application close: M:\lazarus\projects\maestro\maestro.exe Heap dump by heaptrc unit 17744 memory blocks allocated : 584450/634648 17732 memory blocks freed : 584402/634552 12 unfreed memory blocks : 48 True heap size : 1081344 (112 used in System startup) True free heap : 1080272 Should be : 1080464 Call trace for block $015E38A0 size 4 $004ECC93 TGRIDCOLUMN__SETSIZEPRIORITY, line 8536 of Grids.pas $00441A37 SETORDPROP, line 896 of should fixed by now thanks Jesus Reyes A. ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.yahoo.com.mx/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 22, 2008 8:35 PM, Giuliano Colla [EMAIL PROTECTED] wrote: I can't say. I read that someone is *using* gtk2. I tried to make a form with a button I suppose you meant the gtk2 Lazarus interface. Well, I use it for: http://magnifier.sourceforge.net/ And works pretty well. The magnifier can't actually run in gtk1 at all: it doesn't support screenshot taking. (I tryed to implement it once, didn't work, gave up) And also use it for Lazarus under Linux since more then 1 year and it's quite stable. I think this is another case that generalizing one's experience doesn't work =) I probably never used the things you mentioned on gtk2, so I never noticed they don't work and never had the need to find out why they don't work. The magnifier uses buttons, a TPageControl, a tray icon, some menus, etc, all those things work well in Gtk 2 since more then 1 year at least. At least in the way I used them on the project. My idea of open source is that if everyone fixes the small issues they find. Just enougth to make their apps work. We will eventually have a perfect/bug-free project =) Today I don't see any reason why I would use gtk 1 anymore. Even if the gtk2 interface has bugs, gtk1 has catastrophical failures for me: * Horrible look * Bad/inconsistent internationalization support * Not developed anymore, long time ago obsoleted thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
On 22/01/2008, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote: Gtk2 is in fact slower than Gtk1, every one agree, but LCL/Gtk2 application are much slower than other Gtk2 applications Thanks, that was the point I was trying to make. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
Giuliano Colla schreef: Vincent Snijders ha scritto: I'trying to track som bugs which may be unicode related. Could you save me a lot of search telling me what I should setup in order to compile LCL without unicode support? Nothing. On win32, LCL without unicode support is still the default. Sorry, I forgot to mention. On Linux. Ah, this is a windows only bug. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
Vincent Snijders ha scritto: I'trying to track som bugs which may be unicode related. Could you save me a lot of search telling me what I should setup in order to compile LCL without unicode support? Nothing. On win32, LCL without unicode support is still the default. Sorry, I forgot to mention. On Linux. Thanks, Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Joost van der Sluis ha scritto: Op dinsdag 22-01-2008 om 15:03 uur [tijdzone +0200], schreef Graeme Geldenhuys: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? Hindsight is a awesome thing. :-) For me: if Lazarus woudn't use native widgets, I woudn't use it. It's one of the most important features for me. You mean that someone is eager to see gtk1 style widgets? Or someone is prepared to pay to get a dialog Cancel - Retry -Abort if something goes wrong, instead of a dialog telling something meaningful? Else I could also use Java, for example. for me the main issue with Java is that it doesn't 'feel' native for most users. Well Java is simply ugly, unless you make a lot of work on it. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
Vincent Snijders wrote: Armin Diehl schreef: strange problem that happens only if i run the program from within the ide. A blank form, one button and a topendialog (does not matter if it is on the form or manually created). The dialog opens and after some seconds (sometimes i have to move the mouse), i get a sigsegv, Running the program outside the ide (with or without gdb) works without problems. This happens with yesterdays snapshot and with 0.9.24. (Have not tried other versions) Btw, the same happens with TSelectDirectoryDialog Also reported as http://bugs.freepascal.org/view.php?id=10409 does not seems to be the same, there is a patch in the bug report that initializes ole but it makes no difference. idea Maybe I should recompile my LCL without unicode support, so I can see this bug. /idea Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: Al Boldi ha scritto: Giuliano Colla wrote: I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Compiled languages: 1) Assembler from HP minicomputers to IBM mainframes (including an incredible Siemens computer, which at start-up was typing an obscure message in german: if you just typed return, it would take the default action, i.e. assume a new installation and reformat its hard disks! :-) ) , and then micros for all the Intel Family, from 4004 (it was a nightmare, three instructions to read a memory location but with good macros you could get away) to nowadays Pentium 2) Fortran (different flavors in time) 3) Algol 60 4) Intel's PLM's: PLM48 PLM51 PLM80 PLM86 PLM386 5) C 6) C++ 7) Delphi Pascal 8) Free Pascal Interpreted Languages: 9) Basic 10) Visual Basic 11) Python 12) Tcl/Tk Possibly I've left out some, but that's more or less the picture. Which one is the best? : : Among OOPL doubtlessly Pascal. Why? How does OOP affect development (pros/cons)? : : The con's are that it may encourage lazyness. You may end up using an object because it's ready made, taking advantage of a minimal part of its features, and making your code bigger and slower, and maybe harder to debug, when a small subroutine could have served the same purpose. Good point. (I can detect sarcasm at least since as long as I have been programming, but your questions deserved a reply nonetheless). Actually, there should be nothing sarcastic about trying to learn from somebody more experienced. Just one more question: In another thread you said Java is ugly, what about the language, and how does it compare to pascal? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
I see a lot of complains / demands, so I can't help but to say: If you see a problem, you can contribute a fix. If you expect someone else to fix it for you (doesn't matter who broke it), at least be polite and patient. If you don't like Lazarus, get your money back. thank you for your attention, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: I probably never used the things you mentioned on gtk2, so I never noticed they don't work and never had the need to find out why they Maybe we should create a 'universal' widget set test application... Remember the old one in fpGUI v0.4 (widgetdemo)? That really helped to debug issue between X11 and GDI implementation? I think one can create a much better / in depth toolkit test application for Lazarus. It can test the firing of event orders, runtime (life) component property changes to see the effect, etc... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Al Boldi schreef: Vincent Snijders wrote: IMHO zipped incremental updates are impossible, because you cannot zip file removals. I think you can, like this: diff -ruNp file.pas /dev/null file.diff patch file.diff This removes the file. Ok. You can download your patch by (all on one line): svn diff http://svn.freepascal.org/svn/fpc/tags/release_2_0_2 http://svn.freepascal.org/svn/fpc/tags/release_2_2_0 ugrade.patch Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys schreef: On 22/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: I probably never used the things you mentioned on gtk2, so I never noticed they don't work and never had the need to find out why they Maybe we should create a 'universal' widget set test application... Remember the old one in fpGUI v0.4 (widgetdemo)? That really helped to debug issue between X11 and GDI implementation? I think one can create a much better / in depth toolkit test application for Lazarus. It can test the firing of event orders, runtime (life) component property changes to see the effect, etc... I have been thinking about that too, even started part of it. One of the problems is that X11 and GDI and MacOSX all have different way of triggering events. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sigsegv with TOpenDialog Win32(XPSP2)
just to be sure, retested it with a fresh xp sp2 install under vmware, (no additional software installed) it is reproducible with the small code i already posted. Vincent Snijders wrote: Giuliano Colla schreef: Vincent Snijders ha scritto: I'trying to track som bugs which may be unicode related. Could you save me a lot of search telling me what I should setup in order to compile LCL without unicode support? Nothing. On win32, LCL without unicode support is still the default. Sorry, I forgot to mention. On Linux. Ah, this is a windows only bug. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Vincent Snijders wrote: Ok. You can download your patch by (all on one line): svn diff http://svn.freepascal.org/svn/fpc/tags/release_2_0_2 http://svn.freepascal.org/svn/fpc/tags/release_2_2_0 ugrade.patch Thanks a lot! When will this be on sourceforge as .bz2? Thanks again for the great support! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
Luiz Americo Pereira Camara wrote: Marc Weustink wrote: Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) I've tried to use Lazarus/GTK2 for half a day now. It's horribly slow as well, compared to GTK1. For now I switched back to GTK1 and will try GTK2 in a few months again. I fear that won't change much, gtk2 itself is slower than gtk1 due to all clientside graphic stuff Gtk2 is in fact slower than Gtk1, every one agree, but LCL/Gtk2 application are much slower than other Gtk2 applications Compared to what apps ? Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Al Boldi ha scritto: Giuliano Colla wrote: Which one is the best? : : Among OOPL doubtlessly Pascal. Why? Well, Pascal syntax is much cleaner. It's been planned. C syntax appears to have been made on the way. C (and C++) try to avoid typing as much as possible, and this makes code much less readable. This means in the long run more errors. Pointer arithmetic of C is simply a way to encourage programmer errors. In Pascal you have one Interface section and an Implementation section. They can't be inconsistent because the compiler will tell you, and the Interface is what is used by all other units. In C you have a source file and header files. Your program is the source, but other units will use the header file. If they're inconsistent you'll learn when debugging the program. If you fail to detect inconsistencies, it'll be the end users to experience the trouble. We have our main line of application which is made by some tens of thousands lines in Delphi Pascal, and by a few thousand lines in C. It's a code base we're using for a line of industrial controls, and the C portion is required for the real-time part, which interacts with the Linux kernel. We make a new version for each new control, roughly two a month. Each time, during debug, there are many more errors in the C portion, than in the Pascal portion, although the Pascal portion is ten times larger. But Pascal errors are detected by the compiler, C error by testers. I'm trying to see if the C section could be written in Pascal. Just one more question: In another thread you said Java is ugly, what about the language, and how does it compare to pascal? I don't know enough about Java language to formulate a judgment. I've never used it, and a casual glance to some source code isn't enough to draw conclusions. I seldom used interpreters, because I've always been looking in need of fast response. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
On Jan 22, 2008, at 10:20 PM, Marc Weustink wrote: Luiz Americo Pereira Camara wrote: Marc Weustink wrote: Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: I gather that someone is already using GTK2, but I believe that he's not much demanding in terms of graphic appearance. My customers would run after me with a hammer if I'd dare to show them the current state of the art. :-) I've tried to use Lazarus/GTK2 for half a day now. It's horribly slow as well, compared to GTK1. For now I switched back to GTK1 and will try GTK2 in a few months again. I fear that won't change much, gtk2 itself is slower than gtk1 due to all clientside graphic stuff Gtk2 is in fact slower than Gtk1, every one agree, but LCL/Gtk2 application are much slower than other Gtk2 applications Compared to what apps ? Personaly, I don't think the difference is so much. It is not like using a 3D engine to make transparent windows. There is without a doubt. We were speaking a few days ago the count of layers. As fpGUI, LCL is a layer as well, with its own overhead. Additionally with Lazarus, we often naturally create more widgets than needed (enjoy nested panels) plus some arrangements which may not be lead to the best performance, done by the widgetset and all its policies to ensure its good work. For sure, some of us are tired to read this ml and to see GTK2 is slower GTk2/LCL is slower with infinite threads. It is a fact and we have to accept that. We have to choose for balance, according to our needs and philosophy. Some of us think this is too slow for them ? They can use their own way if they want to and that's good. The future will tell if they were right. May day some day the different ways will lead to the same point. I think others would like to focus on what really matters: To improve the great work done for Lazarus. -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sqldb query parameter properties not loaded?
John wrote: Hi, Environment: win32, Lazarus SVN 13347, fpc SVN 9468 In Lazarus, I have a simple query that uses a parameter: select * from test_cld where code = :code; I am defining it at design time using the object inspector. I set the property parameters to ftString and ptInput, save everything, and close the form, and open it again. If I view the lfm source, it get: Params = item DataType = ftString Name = 'code' ParamType = ptInput end as expected, but in the object inspector, the datatype and Paramtype are back to ftUnknown and ptUnknown. Further, even if I fix them and run the app, I get an error 'unknown field type for parameter code', which implies that the same thing is happening. (With the correct values in the parameter I can open the query at design time). I can't find any reference to this in mantis - has anyone else had the problem ? I posted this about a month ago. After much tracing, adding debug lines, (and general chasing of wild geese,) it appears to me that the following is happening: TReader.ReadData is called for the form. It reads the form components, eventually getting to SQLQuery, and reads the SQL.strings property. At this point, FParams.ParseSQL is called, which reads the SQL text and creates the parameters. The parameter properties are then read, and properties of matching parameters are set (So far so good) At the end of TReader.ReadData for the form, DoFixupReferences is called. This sets the database to which the SQLQuery is attached by calling TCustomSQLQuery.SetDatabase, which: Calls TCustomSQLQuery.OnChangeSQL, which: Calls Fparams.ParseSQL(FSQL.Text,True, ,psInterbase) However, the second parameter, true tells Fparams.ParseSQL to DoCreate, which means dropping all the existing parameters and recreating them from the sql text. This means that the param field type is lost, as the new parameters are created with ftUnknown. (Note also that the parameters are always created as psinterbase type params. I am not sure if this causes a problem, as it may be overwritten somewhere, but it looks strange as there is a 'case' in ParseSQL to cover the different types of parameter styles.) All this is likely to not be a problem if the sql and parameters are set at runtime, as one would typically set the database link before the sql text and parameters. I was originally trying to set up a parent/child link at design time. I have not put this in mantis yet, I thought someone might like to check my analysis - this is my first venture into the component loading code, and I may be on the wrong track entirely. cheers, John Sunderland _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TStringGrid.Columns.SizePriority
Jesus Reyes wrote: --- Lee Jenkins [EMAIL PROTECTED] escribió: Hi all, I have some TStrigGrid's on a form with AutoFillColumns := true; I was monkeying around with SizePriority trying to figure out what it did by setting a few columns' SizePriority to 2. At any rate, when running the app with heaptrc active it reports the following on application close: M:\lazarus\projects\maestro\maestro.exe Heap dump by heaptrc unit 17744 memory blocks allocated : 584450/634648 17732 memory blocks freed : 584402/634552 12 unfreed memory blocks : 48 True heap size : 1081344 (112 used in System startup) True free heap : 1080272 Should be : 1080464 Call trace for block $015E38A0 size 4 $004ECC93 TGRIDCOLUMN__SETSIZEPRIORITY, line 8536 of Grids.pas $00441A37 SETORDPROP, line 896 of should fixed by now thanks Jesus Reyes A. Thanks! -- Warm Regards, Lee Everything I needed to learn in life, I learned selling encyclopedias door to door. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Felipe Monteiro de Carvalho ha scritto: On Jan 22, 2008 8:35 PM, Giuliano Colla [EMAIL PROTECTED] wrote: I can't say. I read that someone is *using* gtk2. I tried to make a form with a button I suppose you meant the gtk2 Lazarus interface. Well, I use it for: http://magnifier.sourceforge.net/ And works pretty well. The magnifier can't actually run in gtk1 at all: it doesn't support screenshot taking. (I tryed to implement it once, didn't work, gave up) Please give a look to the attached screenshots. Design form, and result with gtk2 r13823. The test isn't by me, but by someone who complained about z-order in gtk2 not being correct. A lot of time ago. I know, it's voluntary work, everybody does its best. We take what's available, and thank. But please don't tell me that gtk2 can be taken in consideration for anything else than a specific project carried on by a Lazarus developer, who knows enough the internals to fix the widgets he needs. Today I don't see any reason why I would use gtk 1 anymore. Even if the gtk2 interface has bugs, gtk1 has catastrophical failures for me: * Horrible look I agree, but it's *native look* ;-) * Bad/inconsistent internationalization support I agree. * Not developed anymore, long time ago obsoleted I agree. But an average user can complain about a few well delimited bugs. Gtk2 doesn't require bug fixes, require implementing. It's not ready. Qt, which still is not usable, is more advanced at the moment. What works works, what isn't there doesn't. The priority, for Lazarus 1.0, if I understand properly, was to have at least one widgeset (gtk1) complete. So I don't complain about gtk2, but I can't use it either. Giuliano inline: TestForm0.pnginline: TestForm1.png
Re: [lazarus] Lazarus compiled with GTK2 [part 1 of 2]
Luiz Americo Pereira Camara wrote: Gtk2 is in fact slower than Gtk1, every one agree, but LCL/Gtk2 application are much slower than other Gtk2 applications Is it possible to profile gtk2 lcl application and find what cause this slowleness? Who can do? Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
