[lazarus] DropFiles Implementation
Hi, We had an discussion about the OnDropFiles implementation in german lazarus forum lately. And most people had the meaning that the current implementation is not so good. The main problem is that it is impossible to drop files to special controls. In most cases the people dont need the Files on the whole Form but in special controls. AllowDropFiles makes no sense for me. The second thing is I think it is not very LCLisch. I think an correct implementation add an OnDropFiles event to TWinControl or TCustomControl and not to TForm. I think we should think twice about these and implement it bevore 1.0 after that we shouldnt break existing code. best regards Christian _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] DropFiles Implementation
Christian U. wrote: The second thing is I think it is not very LCLisch. I think an correct implementation add an OnDropFiles event to TWinControl or TCustomControl and not to TForm. I think we should think twice about these and implement it bevore 1.0 after that we shouldnt break existing code. What for we need OnDropFiles? We already have OnDragOver and OnDragDrop. To distinct that we are dragging files we can invent new descendant of TDragObject. This way dragging/dropping files will be very LCLisch. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] DropFiles Implementation
Paul Ishenin schrieb: Christian U. wrote: The second thing is I think it is not very LCLisch. I think an correct implementation add an OnDropFiles event to TWinControl or TCustomControl and not to TForm. I think we should think twice about these and implement it bevore 1.0 after that we shouldnt break existing code. What for we need OnDropFiles? We already have OnDragOver and OnDragDrop. To distinct that we are dragging files we can invent new descendant of TDragObject. This way dragging/dropping files will be very LCLisch. nice idea. 100% agree. Best regards, Paul Ishenin. _ 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
On Jan 20, 2008, at 8:00 AM, Graeme Geldenhuys wrote: On 20/01/2008, Damien Gerard [EMAIL PROTECTED] wrote: I better understand with all these explanations. Thanks to all ! Again, I disagree. ;-) I did a study on this. I opened a random set of applications that have things like File Dialogs and Font Dialogs. You will be amazed at the amount of different dialogs being used. They are not all the same - some look similar though. Some dialogs in applications don't have the shortcut bar on the left etc... This was true for Windows and Gnome. KDE was the most consistent of them all. I've already put some thought into adding a shortcut feature in File Open and File Save dialogs. fpGUI's font dialog is much better (or will be) than Windows or GTKx's ones. It has a Collections column sorting fonts by All fonts, Recently Used, Favourites, Fixed Width, Sans, Serif and Font Aliases. Other improvement to any dialog type could easily be added if needed. Overall they work similar to all other 'native' dialogs, so the user will have no difficulty in using them. I don't think the Font dialog matters under win and Unix (for now). But for Open and Save dialogs it was a criteria for my clients when they saw the different prototypes, the same for integration for the OS (that means a version for Ubuntu and a version for KDE and a Windows version with the good themes) -- 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] OpenMoko and FPC/Lazarus
Marc Weustink wrote: ik wrote: Hi, While google suggest rewards for developing applications for Android, there is an open source firmware named OpenMoko (http://openmoko.org/). I asked Michael Shiloh what are some of the requirement in building apps in different compilers (FPC to be exact, and I also mentioned Lazarus :)). Well all that is required is to bind ourself to the C libraries. I wonder what does it mean (other then binding) to make FPC and Lazarus to support such environment. I've been playing with that thought also (I've been following that project for a while now). It supports X and gtk so that part should work and AFAIK it runs some arm-linux so imo fpc could genererste some exe. Since there wasn't an (easy) emulator environment, I stopped thinging about it and didn't test. OK, thinks have inmroved and you now can run a qemu emulator :) I did some tests. First, just using the gnu-arm-linux binutils, I compiled a arm-linux trunk fpc and compiled a test (RTTIdump) console app. It runs fine on the emulated moko. Second I tried one of my simple test gtk2 apps. It compiles, but failed to link since the gnu-arm-linux binutils don't understand the format used for the X, gdk, gtk libs. I should have done some more initial reading, since openmoko brings its own binutils. After installing the openmoko toolchain I tried and linking my testapp failed again. Now ld was complaining that the .o files of the rtl had a wrong eabi version. Sure, true, indeed, I forgot to recompile fpc. And that ends in: /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s: Assembler messages: /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s:15225: Error: selected processor does not support `rfs r0' /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s:15228: Error: selected processor does not support `wfs r0' /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s:19155: Error: selected processor does not support `stfd f0,[r13]' It seems that the used arm core has no floatingpoint unit. Does fpc support softfloat ? (if yes, how to use ?) 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: Marc Weustink wrote: ik wrote: Hi, While google suggest rewards for developing applications for Android, there is an open source firmware named OpenMoko (http://openmoko.org/). I asked Michael Shiloh what are some of the requirement in building apps in different compilers (FPC to be exact, and I also mentioned Lazarus :)). Well all that is required is to bind ourself to the C libraries. I wonder what does it mean (other then binding) to make FPC and Lazarus to support such environment. I've been playing with that thought also (I've been following that project for a while now). It supports X and gtk so that part should work and AFAIK it runs some arm-linux so imo fpc could genererste some exe. Since there wasn't an (easy) emulator environment, I stopped thinging about it and didn't test. OK, thinks have inmroved and you now can run a qemu emulator :) I did some tests. First, just using the gnu-arm-linux binutils, I compiled a arm-linux trunk fpc and compiled a test (RTTIdump) console app. It runs fine on the emulated moko. Second I tried one of my simple test gtk2 apps. It compiles, but failed to link since the gnu-arm-linux binutils don't understand the format used for the X, gdk, gtk libs. I should have done some more initial reading, since openmoko brings its own binutils. After installing the openmoko toolchain I tried and linking my testapp failed again. Now ld was complaining that the .o files of the rtl had a wrong eabi version. Sure, true, indeed, I forgot to recompile fpc. And that ends in: /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s: Assembler messages: /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s:15225: Error: selected processor does not support `rfs r0' /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s:15228: Error: selected processor does not support `wfs r0' /net/thunder/mnt/mirror1/src/fpc/trunk/rtl/units/arm-linux/system.s:19155: Error: selected processor does not support `stfd f0,[r13]' It seems that the used arm core has no floatingpoint unit. Does fpc support softfloat ? (if yes, how to use ?) It should be enough to build FPC with OPT=-dFPC_ARMEL _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Am Sonntag, den 20.01.2008, 09:00 +0200 schrieb Graeme Geldenhuys: Always speaking about GTK-bugs but what about fpGUI bugs ? When using Lazarus and the LCL, the underlying toolkits are not under your control. It's quick and easy to fix fpGUI bugs. You can't fix Win32 native component bugs and how long until you see GTK1 or GTK2 bug fixes come through. Only one additional note: fpGUI is actively developed, GTK1 is long time abandoned in favour of GTK2. 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
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? Great! (not that I grasp the full implications of oabi vs. eabi, but I'd like to make some experiment with my n800, which is an eabi system). Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] GTK1 Application Performance
Hi all, I've just started testing a couple of application originally written on my XP machine on Linux (CentOS4) running in a virtual machine. I noticed that some things seem to be a little slow. Particularly, there is a form with a stringgrid on it and highlighting a new row seems to have a lag between when clicked and the row being highlighted. Also, if I click too fast, meaning that I click on the row and quickly move away from it, the row doesn't get highlighted. Almost as if the mouseup event doesn't get called to generate a click event. As I mentioned, this is running in a VM so it could very well be the environment. I don't have an extra box to install linux on until the end of the week so I was curious if anyone else sees this kind of slowness. -- Warm Regards, Lee The only thing that kept me out college...was high school. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 20/01/2008, Marco van de Voort [EMAIL PROTECTED] wrote: Apparantly the only person with skills to run into that started his own widgetset :-) It didn't even take a lot of effort to hit those problems... Just write commercial software. :-) Good news is that some day Lazarus will benefit from my work with fpGUI. I would like to try and complete the LCL-fpGUI integration to have it as another working widgetset choice for developers using Lazarus and LCL. Obviously this is all time permitting so I have no time frame set. I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. 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] OpenMoko and FPC/Lazarus
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. Great! (not that I grasp the full implications of oabi vs. eabi, but I'd like to make some experiment with my n800, which is an eabi system). Bye _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Lord Satan wrote: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. 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. Now we only get this sucking Win API, GTK1, GTK2, Carbon and QT. Nothing really works and all is full of bugs. Take easy. If you are not help with it you have three options: - Don't use anymore - Make patches - Do a fork For myself i have some differences with Lazarus developers vision, but i will never call them stupid. Instead, i make patches. Luiz _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Lord Satan wrote: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. 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. Now we only get this sucking Win API, GTK1, GTK2, Carbon and QT. Nothing really works and all is full of bugs. If we had used OpenGL, then we had to create out component framework first. Keep in mind, Lazarus is primarely focused in using *native* components and I repeat it again *native* components. OpenGL is *not* native. EOD. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Lord Satan schrieb: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. 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. The initial coding for fpGUI was done at the same time as lazarus starts (1999). However, nobody was interested in contributing to it so it went into hibernation. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 21/01/2008, Lord Satan [EMAIL PROTECTED] wrote: Stupid Lazarus developers. Now we only get this sucking Win API, GTK1, GTK2, Carbon and QT. Nothing really works and all is full of bugs. I agree with Luiz. Lazarus developers are *not* stupid. They have done an amazing job so far in getting the LCL to wrap so many toolkits - it just wasn't the right fit for our company. They simply followed a different path to what I would have taken, but I am sure at the time they thought it to be the best solution. Hindsight is always great! ;-) Plus, if it wasn't for them, I wouldn't have such a cool IDE to work with! 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] TimeCallBack under Win32
On Jan 19, 2008, at 2:07 PM, Mark Morgan Lloyd wrote: Damien Gerard wrote: n := FTimerData.Count; while (n0) do begin dec(n); It seems FTimerData is not properly set. Is it possible ? May be it is related to some bad behavior of my application (I really don't know what but it is not impossible) Try explicitly disabling this while the loop is running in case it's going reentrant. In fact I have problems once I use Threads in my application under Windows (works perfectly under Linux). Is this relevant? Is the code you've quoted being run by a non-main thread or trying to share something? I've got a program here using multiple threads on Windows, linux/386 and linux/sparc. Obviously all user interaction is handled by the main thread, various UDP etc. is running in the background. When I use TTimer instead of my own Thread it works under Windows ... :( May be you are right. It must have multiple interaction with the gui. -- 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
