Re: [Lazarus] Is Lazarus project in a downward spiral?
Graeme Geldenhuys schrieb: 2010/3/6 Florian Klaempfl flor...@freepascal.org: It causes a lot of load: it takes several seconds to load it. I've attached a summary graph for lazarus. Thanks for the graph Florian. Is it possible to create static versions of the various statistic pages (I don't know what is available), say once per month? Don't you think time should be spended in fixing bugs instead of writing statistics scripts :)? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 6 March 2010 15:29, Michael Van Canneyt mich...@freepascal.org wrote: b) have a larger development group. compare this to fpGUI which is essentially a one-man show. If Graeme for some reason drops out (gods forbid): bye-bye fpGUI. Qt started as a two-man band, so there is hope for fpGUI. ;-) None of this means that I think fpGUI is bad (I have used it), or that making a LCL widgetset for fpGUI (next to the others) is in itself a bad idea. But basing Lazarus' LCL on it: No, thank you. I looked at the LCL-fpGUI widgetset last night. I was shocked at how much Windows-ism is in the common widgetset interface layer of LCL. GDIObject types, many other Win32 API types, WinAPI unit itself, and lots and lots more Windows specific calls etc must all somehow be re-implemented for each widgetsets backend that the LCL supports. Such Windows-ism in a cross-platform product simply cannot be good. It is amazing LCL got as far as it did with this Windows paradigm forced onto all widgetset backend implementers. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 6 March 2010 17:51, Michael Van Canneyt mich...@freepascal.org wrote: I appreciate that some bugs are hard to find. But you are wrong if you think that rolling your own widgetset will guarantee you less bugs. Martin (MSEgui) and myself having first hand experience in this will definitely tell you that there are much less bugs (simply because the code is simpler), easier to fix bugs too. And to fix a bug it's in one location for all supported platforms (99% of the time). But it has been discussed a million times before and not to be repeated here again. Lazarus wanted to take a different approach, by having a native look and feel and using native components where possible. I know this. I just think that LCL took the wrong approach in there implementation. Forcing Windows-ism on every widgetset the LCL supports - hence complicating implementations a lot. Take a look at Qt? No Windows-ism in it's design, no Win32 API types in it's design etc., yet it succeeds in the native look and feel on all large platforms. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Graeme Geldenhuys schrieb: On 6 March 2010 17:51, Michael Van Canneyt mich...@freepascal.org wrote: I appreciate that some bugs are hard to find. But you are wrong if you think that rolling your own widgetset will guarantee you less bugs. Martin (MSEgui) and myself having first hand experience in this will definitely tell you that there are much less bugs (simply because the code is simpler), ... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui, neither the context menu works, so one can not create folders, rename files etc. quickly, no W7 favorite folder list (which I really like) etc. easier to fix bugs too. And to fix a bug it's in one location for all supported platforms (99% of the time). But it has been discussed a million times before and not to be repeated here again. Lazarus wanted to take a different approach, by having a native look and feel and using native components where possible. I know this. I just think that LCL took the wrong approach in there implementation. People want delphi compatibility. Forcing Windows-ism on every widgetset the LCL supports - hence complicating implementations a lot. Take a look at Qt? No Windows-ism in it's design, no Win32 API types in it's design etc., yet it succeeds in the native look and feel on all large platforms. Due to the emulation, it usually still looks strange. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 07, 2010 at 10:55:59AM +0200, Graeme Geldenhuys wrote: Everybody keeps hammering the native look and feel issue, yet it seems very unimportant to the end-user (Mac OS users excluded). And then I haven't even mentioned the biggest product of them all, Web Apps! They run on all platforms, yet their look is consistent across all platforms and doesn't adhere to a single OS's look and feel. Funny that, no end-user has problems with that either. I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 00:09, Tom Lisjac zikon...@gmail.com wrote: The only thing that is stopping Lazarus/FPC from become a stable, mainstream production tool is attitudes... and I'm hoping threads like these will cause a change of focus across the core teams from feature development to stabilize what we have and to release 1.0 as Paul Ishenin suggested yesterday. Thanks Tom. I'm glad somebody else understands the issue. At this point I'm not even worrying about a 1.0 release. I'm just looking for a stable release - whatever version number that might be. And then having a development model where stability is held. End-users can then choose to use the stable version or the unstable version. At least that will give me something to recommend and promote to potential FPC Lazarus users. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 10:47, Florian Klaempfl flor...@freepascal.org wrote: ... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui, I'm sure that will be a quick fix for Martin, it if was brought to his attention. To be honest, no matter what platform, I have never even consider the action of drag-drop into a File Open dialog. Yes I have done drag-drop into a application window, but never into a File Dialog window. It's just amazing how each person works differently. :) neither the context menu works, so one can not create folders, rename files etc. I always smile when I see such comments - I guess it's a matter of oppinion. What is a file open dialog? Maybe the name will give you a hint? Yes, to select a file to open. If you want to manage files or folders, then user Windows Explorer, Total Commander, Double Commander, Nautilus etc... That's what the file manager applications were designed for. quickly, no W7 favorite folder list (which I really like) etc. A handy feature yes, and something fpGUI will have in the next week. It's been on my todo list for long enough. :) I just think that LCL took the wrong approach in there implementation. People want delphi compatibility. I'm not arguing that, I'm simply stating the widgetset interfaces design is not idea, and that has nothing to do with Delphi compatibility. Either GTK1, GTK2, Qt, Cocoa, Carbon, fpGUI or KOL has the notion of a GDIObject type? So why is it in the widgetset interfaces that must be implemented in each of the LCL backends? That's Windows-ism forced down on every developer wanting to implement a new LCL backend. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sunday 07 March 2010 09:47:50 Florian Klaempfl wrote: ... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui, neither the context menu works, so one can not create folders, rename files etc. quickly, no W7 favorite folder list (which I really like) etc. It can be added if there is a sponsor. ;-) It is possible to add platform specific functionality, components and widgets. I don't make it my self because my needs are identical behaviour of MSEgui on Linux and Windows. You are free to add the wanted widgets yourself. BTW there is tguiapplication.registersyseventhandler() in order to hook into Windows and X11 messages. easier to fix bugs too. And to fix a bug it's in one location for all supported platforms (99% of the time). I second that. I used VCL for the pre-predecessor (Windows only) and CLX for the predecessor of MSEgui as base and decided that the goal of creating a high quality and productive platform independent framework based on platform specific widget libraries is too difficult for me. But I am a one man show only, Lazarus has probably better possibilities. But it has been discussed a million times before and not to be repeated here again. Lazarus wanted to take a different approach, by having a native look and feel and using native components where possible. I know this. I just think that LCL took the wrong approach in there implementation. People want delphi compatibility. Delphi compatibility and crossplatform and especially using external widgetsets is a contradiction I fear. It is maybe imaginable to design a dedicated architecture in order to abstract the differences of the widgetset. I don't think VCL was designed for that purpose. Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Graeme Geldenhuys schrieb: On 7 March 2010 10:47, Florian Klaempfl flor...@freepascal.org wrote: ... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui, I'm sure that will be a quick fix for Martin, it if was brought to his attention. To be honest, no matter what platform, I have never even consider the action of drag-drop into a File Open dialog. Yes I have done drag-drop into a application window, but never into a File Dialog window. It's just amazing how each person works differently. :) neither the context menu works, so one can not create folders, rename files etc. I always smile when I see such comments - I guess it's a matter of oppinion. What is a file open dialog? Maybe the name will give you a hint? Yes, to select a file to open. If you want to manage files or folders, then user Windows Explorer, Total Commander, Double Commander, Nautilus etc... That's what the file manager applications were designed for. When saving a file I often realize that I would - overwrite an old one so I rename the old one - or that I want to have it in a new folder - I'd like to see the SCM status - see modification date or whatever - ... Why should I waste time and change to a different program while I could do this in the file open/save dialog? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] New Qt bindings
Hi all, As of lazarus 0.9.29 svn revision 23858 qt bidings v. 2.1 must be used. Lazarus qtlcl is not compileable against bindings 1.72 anymore. Minimum qt libs requirement is qt-4.5.0, but 4.6.XX can be used too. Den: I've added HAIKU ifdef into qt4.pas, please add it to next version of bindings. Happy coding :) zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Graeme Geldenhuys schrieb: I looked at the LCL-fpGUI widgetset last night. I was shocked at how much Windows-ism is in the common widgetset interface layer of LCL. Can you suggest another interface, that better fits the various widgetset APIs? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Martin Schreiber schrieb: BTW there is tguiapplication.registersyseventhandler() in order to hook into Windows and X11 messages. The unreadable names (all lowercase) make it impossible to me to have any closer look at msegui. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC Docs updated
On Sat, 6 Mar 2010, Jonathan wrote: On Sat, 6 Mar 2010 13:57:48 +0100 (CET) Michael Van Canneyt mich...@freepascal.org wrote: Hi, The documentation has been re-generated and put on the website. the fpc/dist/2.4.0/docs directory on the FTP server contains also a version of the latest docs. Thank you! They have been re-generated from version 2.4.0. Naming the version of the FPC that the documentation was generated from in the page footer would be useful. Why does the http://www.freepascal.org/docs-html/ page not have a link to the http://www.freepascal.org/docs-html/lcl/ page? Because till you pointed it out to me, I didn't know the LCL documentation was there. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sunday 07 March 2010 12:19:55 Hans-Peter Diettrich wrote: Martin Schreiber schrieb: BTW there is tguiapplication.registersyseventhandler() in order to hook into Windows and X11 messages. The unreadable names (all lowercase) make it impossible to me to have any closer look at msegui. Interresting. I changed my Pascal conding style three times in the last 25 years, the last time about 10 years ago. It seems for me the optimum of productivity and readability is reached. I write all lowercase exactly because all lowercase has the best readability for me. With camelcase style a symbol breaks into sub-symbols for me which can't be recognised and processed as fast by my brain. Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, 7 Mar 2010, Graeme Geldenhuys wrote: On 6 March 2010 17:51, Michael Van Canneyt mich...@freepascal.org wrote: I appreciate that some bugs are hard to find. But you are wrong if you think that rolling your own widgetset will guarantee you less bugs. Martin (MSEgui) and myself having first hand experience in this will definitely tell you that there are much less bugs (simply because the code is simpler), easier to fix bugs too. And to fix a bug it's in one location for all supported platforms (99% of the time). The downside to this is: there is also a lot less functionality. A simpler product is by definition easier to maintain. As you will introduce more components, you'll also introduce more bugs, this is inevitable. And as soon as someone says 'I want native look and feel', you're in for a lot of work, and again extra bugs, by nature different per platform - and you're in the same situation Lazarus is in now. But it has been discussed a million times before and not to be repeated here again. Lazarus wanted to take a different approach, by having a native look and feel and using native components where possible. I know this. I just think that LCL took the wrong approach in there implementation. Forcing Windows-ism on every widgetset the LCL supports - hence complicating implementations a lot. Take a look at Qt? No Windows-ism in it's design, no Win32 API types in it's design etc., yet it succeeds in the native look and feel on all large platforms. I 100% agree with the critique about windows-isms. I would also have preferred the LCL to be a VCL 'without the windows calls' I think the VCL does a pretty good job of abstracting out the Windows API. You can program it pretty much without knowing anything about the windows API (some corner cases aside, such as keyboard key names). It has always pained me to see lazarus' LCL re-introducing the Windows API to such an extent. If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL: - 1.0 as being what is there now, minus the blatant bugs. No features/components added any more. (I'm pretty condifent Vincent agrees on this goal) - 2.0: Get rid of the windows-isms. Add a set of controls/features deemed necessary, such as an internet browser. The IDE itself is another story, there you are more free. The problematic point is: no-one likes to do bugfixing only. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, 7 Mar 2010, Martin Schreiber wrote: On Sunday 07 March 2010 12:19:55 Hans-Peter Diettrich wrote: Martin Schreiber schrieb: BTW there is tguiapplication.registersyseventhandler() in order to hook into Windows and X11 messages. The unreadable names (all lowercase) make it impossible to me to have any closer look at msegui. Interresting. I changed my Pascal conding style three times in the last 25 years, the last time about 10 years ago. It seems for me the optimum of productivity and readability is reached. For you, yes. I agree with Hans-Peter Diettrich... I write all lowercase exactly because all lowercase has the best readability for me. With camelcase style a symbol breaks into sub-symbols for me which can't be recognised and processed as fast by my brain. I don't think that you can credit the lowercase letters for your increased productivity. It's simply 25 years of programming experience. If I look at code I wrote 12 years ago, I now see all the things I did wrong; and I used CamelCase all the time. So the point is not in the casing. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, 7 Mar 2010 10:55:59 +0200, Graeme Geldenhuys wrote about Re: [Lazarus] Is Lazarus project in a downward spiral?: [snip] Everybody keeps hammering the native look and feel issue, yet it seems very unimportant to the end-user (Mac OS users excluded). And then I haven't even mentioned the biggest product of them all, Web Apps! They run on all platforms, yet their look is consistent across all platforms and doesn't adhere to a single OS's look and feel. Funny that, no end-user has problems with that either. I find that a little difficult to believe. Just using Xfce under Linux, I can see differences in a single Web application if it is rendered with a Gecko-based browser or with a Webkit-based browser. Moreover, I prefer the Webkit rendering, as it looks more native (Gtk+) and less Mozilla-ish. Perhaps my eyesight is worse than I thought and/or I am hallucinating. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hi! - 2.0: Get rid of the windows-isms. Would it be possible while retaining LCL support for existing code. No API changes? Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hi! I've not posted here before, but I've been reading this list for about six months, and I've gotta weigh in on this one. By way of introduction, I'm the Sr. Software Engineer/Team Lead for a major consumer electronics company in the US. We've been using C++ Builder for several years as our PC compiler of choice. It's allowed us to develop robust applications in very short time spans with very limited resources. However, it is (of course) Windows only. Last June the word came down that the market was changing, something we all knew, and that Mac's were gaining a significant enough share of the consumer market to warrant our support. I was charged with finding development tools that would allow us to move our existing programs to the Mac in the quickest and most reliable fashion. My initial impulse was Java, but there were lots of issues, the biggest one being a native look and feel on Windows. Most of our PC products involve communication over USB, and that gets problematic with Java as well - we really need native code compilation. Deployment was also an issue. Ditto for Python, and the other platforms we looked at. Then I stumbled across Lazarus/FPC. Native compilation - check. Native look and feel - check. Similar object structure to our existing code base - check. After about a month of having the team play around with the tool, we decided to go forward. Our entire PC software suite ( ~60 applications) is being moved to Lazarus, with the first release scheduled for mid May, on a new (for us) device category. The rest will be rolled out as updates warrant - all new development is being done in Lazarus. A colleague moved a rather complex software update tool from C++ Builder to Lazarus in 4 days - and we now have a Mac version as well. That, my friends, is nothing short of incredible. Following this downward spiral discussion has led me to believe that perhaps the Lazarus community doesn't really understand what it's managed to do here. AFAIK Lazarus is the ONLY tool in it's class that allows this kind of development - one code base, multiple targets, all native look and feel, all native code. That's just mind boggling. My boss was initially very skeptical - Pascal - that old fuddy-duddy language from the 80's? He's a believer now, and happily relearning Pascal so he can throw in the odd module himself now and again. We're even looking as Lazarus for some of our device code (as some of our newer devices are Linux driven). There's a better than even chance that we'll officially get in touch with the developers at some point in the near future and offer resources to help move the project ahead. We were especially intrigued by the discussion of a multi-platform setup tool - right now we use Inno Setup on Windows and the awful Package Manager thing on Macs... In summary, Lazarus is a fantastic product. It's usable TODAY for commercial development. We've found it (the IDE) more stable on Windows than it's commercial counterparts. RAD Studio will generally lock at least one of our development machines once a day - so far we've had only one issue with Lazarus, and that was on a Mac (and I reported the bug to Mantis, and it was fixed in three days - try that with you-know-who ). These discussions are great, but please don't lose sight of what you've already got - a world class compiler and development tool that's being used right now to solve serious real world problems. Thanks, Dave Haxton Sr. Software Engineer Audiovox Electronics Corp. Carmel,IN USA -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hi, What did you think of my idea of different GUI-specific target modes for Lazarus 2.0? I myself feel it is an extremely cool idea! It is already possible to do so. Have a look at the examples/designnonlcl directory in Lazarus. It was created specially for such things. Interesting. The framework is basically there. Object oriented QT-pascal mapping would be rather easy to do. The existing code maps C++ classes and methods to flat functions, they just need to be mapped back to Object Pascal classes and methods. Clumsy but who cares. Other part would be a QT aware form designer with a different layout manager. That would need some work and a more modular, refactored form designer interface in IDE. Still, doable... This is a fascinating idea actually. Combining the good parts of QT and pascal programming. Regards, Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hello, I'm taking the chance here to confirm that we can exactly agree on Daithi Haxton's posting. We had gone a similar way (had the same decision for a development language and tools) for our cross-platform data recovery software (http://grauonline.de/slides/lazarus.html). Before we made our decision for Lazarus, we developed cross-platform software in Java as well (with similar issues as in the posting before). Then we gave a good known wxWidgets-company the chance to develop a prototype using wxWidgets/C++. They needed 4 months. Finally, we found Lazarus and tried a prototype on our own. We needed 4 days and it worked even better. Lazarus is in fact the ONLY set of tools where you can develop native cross platform apps with the same RAD-IDE on all platforms using a fast compile-cycle. Guys, you really made something unique! Don't give it up. Sure, there are bugs - but the are the same amount in other frameworks, development tools etc. We already spend money on having FreePascal/Lazarus developers helping us to fix bugs. And we are considering spending more money into Lazarus in this way. Best regards Alexander Grau Grau GbR Hardware Software Solutions Huellhorst, Germany Development company for LC Technology, Intl. (www.lc-tech.com) Daithi Haxton schrieb: Hi! I've not posted here before, but I've been reading this list for about six months, and I've gotta weigh in on this one. By way of introduction, I'm the Sr. Software Engineer/Team Lead for a major consumer electronics company in the US. We've been using C++ Builder for several years as our PC compiler of choice. It's allowed us to develop robust applications in very short time spans with very limited resources. However, it is (of course) Windows only. Last June the word came down that the market was changing, something we all knew, and that Mac's were gaining a significant enough share of the consumer market to warrant our support. I was charged with finding development tools that would allow us to move our existing programs to the Mac in the quickest and most reliable fashion. My initial impulse was Java, but there were lots of issues, the biggest one being a native look and feel on Windows. Most of our PC products involve communication over USB, and that gets problematic with Java as well - we really need native code compilation. Deployment was also an issue. Ditto for Python, and the other platforms we looked at. Then I stumbled across Lazarus/FPC. Native compilation - check. Native look and feel - check. Similar object structure to our existing code base - check. After about a month of having the team play around with the tool, we decided to go forward. Our entire PC software suite ( ~60 applications) is being moved to Lazarus, with the first release scheduled for mid May, on a new (for us) device category. The rest will be rolled out as updates warrant - all new development is being done in Lazarus. A colleague moved a rather complex software update tool from C++ Builder to Lazarus in 4 days - and we now have a Mac version as well. That, my friends, is nothing short of incredible. Following this downward spiral discussion has led me to believe that perhaps the Lazarus community doesn't really understand what it's managed to do here. AFAIK Lazarus is the ONLY tool in it's class that allows this kind of development - one code base, multiple targets, all native look and feel, all native code. That's just mind boggling. My boss was initially very skeptical - Pascal - that old fuddy-duddy language from the 80's? He's a believer now, and happily relearning Pascal so he can throw in the odd module himself now and again. We're even looking as Lazarus for some of our device code (as some of our newer devices are Linux driven). There's a better than even chance that we'll officially get in touch with the developers at some point in the near future and offer resources to help move the project ahead. We were especially intrigued by the discussion of a multi-platform setup tool - right now we use Inno Setup on Windows and the awful Package Manager thing on Macs... In summary, Lazarus is a fantastic product. It's usable TODAY for commercial development. We've found it (the IDE) more stable on Windows than it's commercial counterparts. RAD Studio will generally lock at least one of our development machines once a day - so far we've had only one issue with Lazarus, and that was on a Mac (and I reported the bug to Mantis, and it was fixed in three days - try that with you-know-who ). These discussions are great, but please don't lose sight of what you've already got - a world class compiler and development tool that's being used right now to solve serious real world problems. Thanks, Dave Haxton Sr. Software Engineer Audiovox Electronics Corp. Carmel,IN USA -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org
Re: [Lazarus] Is Lazarus project in a downward spiral?
We've been using C++ Builder ...
[...]
Native compilation - check. Native look and feel - check. Similar
object structure to our existing code base - check.
and easier and clearer language syntax - check.
A colleague moved a rather complex software update tool from C++
Builder to Lazarus in 4 days - and we now have a Mac version as well.
That, my friends, is nothing short of incredible.
Hmmm... how did he convert the source code?
Is simple find/replace enough or does it need lots of editing?
By replace I mean :
'{' -- begin
'}' -- end
'-' -- '.'
param -- var param
*param -- var param (I guess)
Remove '*'
etc. direct syntax changes.
If that works then it could be implemented in a future version of Delphi
converter, making it Delphi / C++ Builder converter.
Ok, it needs some parsing for sure. Like:
bool myclass::myfunc(otherclass *param)
must be changed to:
function myclass.myfunc(param: otherclass): boolean;
which already needs a parser. But if it needs a full C++ parser then it
becomes complicated and may not be worth the effort.
Regards,
Juha Manninen
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
A lot of the translation was done manually in this case. But a lot of
it was as you describe - find and replace. Some of the direct Windows
API calls were a bit problematic, but nothing that an experienced
coder can't resolve quickly.
One interesting discovery he made was that it's possible to cut and
paste controls from forms in Rad Studio into lazarus! That saved a lot
of time ...
Another interesting issue was the fact that includes in C++ aren't
exactly uses in Pascal - placement matters, and some things had to
be manually fiddled to get them just right. Good unit design in C++
helped a lot, too.
It certainly wouldn't be impossible to get a C++ Builder to Lazarus
converter going - you'd never get it perfect, but hey - that's what
compiler errors are for, eh? ;) And with some 50 programs yet to
translate, we'll probably be doing something like that. If we do, I'll
be sure to put the script/source up somewhere and let you folks know.
If anybody else already has such a thing, by all means, feel free to
share!
Be well,
Dave H.
On Mar 7, 2010, at 9:28 AM, Juha Manninen wrote:
We've been using C++ Builder ...
[...]
Native compilation - check. Native look and feel - check. Similar
object structure to our existing code base - check.
and easier and clearer language syntax - check.
A colleague moved a rather complex software update tool from C++
Builder to Lazarus in 4 days - and we now have a Mac version as
well.
That, my friends, is nothing short of incredible.
Hmmm... how did he convert the source code?
Is simple find/replace enough or does it need lots of editing?
By replace I mean :
'{' -- begin
'}' -- end
'-' -- '.'
param -- var param
*param -- var param (I guess)
Remove '*'
etc. direct syntax changes.
If that works then it could be implemented in a future version of
Delphi converter, making it Delphi / C++ Builder converter.
Ok, it needs some parsing for sure. Like:
bool myclass::myfunc(otherclass *param)
must be changed to:
function myclass.myfunc(param: otherclass): boolean;
which already needs a parser. But if it needs a full C++ parser then
it becomes complicated and may not be worth the effort.
Regards,
Juha Manninen
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 07, 2010 at 11:17:56AM +0200, Graeme Geldenhuys wrote: I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate. Then I guess you hate the internet as well? :) Gmail, Facebook, Twiter, etc. all those little web apps that nobody uses an doesn't adhere to a single OS interface. Yes, I generally prefer real apps over webapps. The user experience (despite web2 propaganda) is poor. But the difference is there that I spend relative little time in them. Do you now see how ridiculous the native look and feel argument sounds? Just the above three web apps have probably over a billion users and nobody complains that it doesn't look like there favourite OS. Pick one: 1. Millions of sheep don't mind doing nothing but grazing either. 2. Then, logically, those millions of users spend less time on the computer than me( and that is probably true) 3. Painlevels may vary between people and experience levels. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Maxim Ganetsky schreef: 06.03.2010 1:06, Vincent Snijders пишет: Somebody with time can tell me what revisions to merge and it will be done. Did you find the revision to be cherry picked? Consider merging the following revisions: maybe 21839 maybe 21860 maybe 21863 maybe 21866 21875 21904 21927 21933 21934 maybe 22255 maybe 22260 maybe 22341 maybe 22487 maybe 22503 maybe 22515 maybe 22627 maybe 22628 maybe 22775 maybe 22795 maybe 22815 maybe 22817 maybe 22819 maybe 22829 maybe 22830 maybe 22833 maybe 22835 maybe 22841 maybe 22843 maybe 22844 maybe 22845 22846 maybe 22852 maybe 23023 23063 23082 23099 23100 maybe 23103 23133 23143 23173 maybe 23174 maybe 23177 maybe 23178 maybe 23234 I hope it will solve form designer issues and improve it. Thanks. This is helpful, I will look at it. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Michael Van Canneyt schrieb: I write all lowercase exactly because all lowercase has the best readability for me. With camelcase style a symbol breaks into sub-symbols for me which can't be recognised and processed as fast by my brain. I don't think that you can credit the lowercase letters for your increased productivity. Most of the compiler is lowercase due to Martin's reason :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Marco van de Voort schrieb: On Sun, Mar 07, 2010 at 11:17:56AM +0200, Graeme Geldenhuys wrote: I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate. Then I guess you hate the internet as well? :) Gmail, Facebook, Twiter, etc. all those little web apps that nobody uses an doesn't adhere to a single OS interface. Yes, I generally prefer real apps over webapps. The user experience (despite web2 propaganda) is poor. But the difference is there that I spend relative little time in them. Not forgetting the fact, that almost all lazarus and fpc development coordination is done through mailing list instead of web based forums. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Grids and DBgrids
Hello Lazarus-List, Sunday, March 7, 2010, 4:12:59 AM, you wrote: AK Although I have no particular need for this change, I support it AK on the general principle. I would go even further and call KeyPress AK _before_ built-in handler, so that user code could turn off AK default handling by setting the key code to zero. I'm not sure that I undertand your answer (my english is quite limited). The desired behavior is that if user handles KeyDown, KeyPress or KeyUp no default actions are taken ? I think that that behavior is only possible in OnKeyDown as the others are too late. Current problem is that the internal grid checks destroys key information so any key handled will not be reported in the KeyPress. I'll try to modify code to accept overriding by users handle, but without destroying Key value. I hope no unexpected side effects happend. -- Best regards, JoshyFun -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hi, It certainly wouldn't be impossible to get a C++ Builder to Lazarus converter going - you'd never get it perfect, but hey - that's what compiler errors are for, eh? ;) And with some 50 programs yet to translate, we'll probably be doing something like that. If we do, I'll be sure to put the script/source up somewhere and let you folks know. If anybody else already has such a thing, by all means, feel free to share! Thinking it more carefully, a C++ parser is needed if you want to make the conversion even nearly automatic. The languages have different contructs. There are C++ features which can't be (easily) converted, like pointer arithmetic and templates. VCL UI code may not have the most advanced C++ features but some other units may have them. I didn't find any C++ to object pascal (or Delphi) converters from internet by google search. If nobody has made it then it must be a difficult task. Regards, Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 07, 2010 at 01:21:37PM +0100, Michael Van Canneyt wrote: I would also have preferred the LCL to be a VCL 'without the windows calls' I think the VCL does a pretty good job of abstracting out the Windows API. You can program it pretty much without knowing anything about the windows API (some corner cases aside, such as keyboard key names). For me not. The current level of windowisms doesn't disturb me, and makes porting of Delphi code to Lazarus so much easier. As far as the planning goes, I think people should stop trying to manage version numbers, and just work. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] IDE search path for include file causes IDE hang
I wanted to know if anyone reported a bug that has to do with include files and the helper component that consistently crashes the IDE. I had dealt with this bug for the past few weeks. It wasn't until I ran ./startlazarus from command prompt that showed me that a unit referencing an include unit could not be found. I solved the problem by adding the path of the include file to the IDE paths in project options/paths but I wonder if a certain user segment is experiencing this issue. This was a trivial error that was easily solved once I knew what the problem was. The fact remains that the IDE should have displayed a dialog box telling me the path needed to be added to that path option so the IDE can function properly. I had to deal with this problem for a week and it was always crashing my Lazarus. Man... I kept doing svn updates for FPC and Lazarus and I think I'm a bit frustrated at the fact that the problem was so simple to solve, and the crash was totally avoidable. I'm thinking that if possible, we should re-think the logic of paths. It's ok to have a seperate option but for bare minimums, behind the scenes, perhaps we could use an aggregate or at least a dialog box saying project unit whatever.pas includes include.inc and cannot be located. Please set a path reference in the IDE path options for this project. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hello Lazarus-List, Sunday, March 7, 2010, 10:17:56 AM, you wrote: GG Then I guess you hate the internet as well? :) Gmail, Facebook, GG Twiter, etc. all those little web apps that nobody uses an doesn't GG adhere to a single OS interface. Do you now see how ridiculous the GG native look and feel argument sounds? Just the above three web apps GG have probably over a billion users and nobody complains that it GG doesn't look like there favourite OS. Plase excuse my interference, but most web applications are windows feel and the look is native to the browser in some cases. The usual example is the combobox selection in HTML. Most browsers try to mimic its native look in the non special CSSd elements. Even default fonts are different across platforms. Even there are pages that are render completly different being browsed from Windows or MacOS, setting elements in different possitions. I'm completly unable to understand this fight between native look and custom look. Special Windows application spend a lot of resources trying to look completly different that the native look (media player in example) and others spend resources trying to be as must native as possible. Each one of them is important in different context. It would be very difficult to explain to anybody why a notebook application in windows have big translucent buttons with a fancy glass effect, or why it is designed with a 12 or 13 pt font when in Windows most users have a 10 pt font. -- Best regards, JoshyFun -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Daithi Haxton schrieb: It certainly wouldn't be impossible to get a C++ Builder to Lazarus converter going - you'd never get it perfect, but hey - that's what compiler errors are for, eh? ;) And with some 50 programs yet to translate, we'll probably be doing something like that. If we do, I'll be sure to put the script/source up somewhere and let you folks know. If anybody else already has such a thing, by all means, feel free to share! I already made an C-to-Pascal converter http://sourceforge.net/projects/topas/, but then got stuck in handling #defines, which deserve translation into either constants or functions, or must be expanded. I never wanted it to handle C++ syntax, but if you have ideas how to make it usable for (partial) translation of C++ code, I'm willing to update it accordingly. BTW, the other direction is much easier to go, see http://www.texttransformer.com/Delphi2Cpp_en.html. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Maxim Ganetsky wrote: 06.03.2010 22:38, Thierry Coq пишет: As a user, I don't understand the team structure, now how can I report a bug or contribute to its correction? This should be clearer, in my opinion. That's really strange. Have a look at http://wiki.lazarus.freepascal.org/How_do_I_create_a_bug_report Thanks ;-) This doesn't solve the issue on when this bug will be corrected, what path will it take, who can correct or test the correction, etc. The casual (would-be) contributor such as myself seems excluded and not really wanted. This is a perception that I have, unwillingly. For the moment, Lazarus is enough for my prototyping, and I'm waiting for a stable, 1.0 version. Until then, there is no chance as a professional developer that I could recommend this tool, although it shows great promise. In the meantime, I develop a few components, testing such issues such as COM/DCOM and dynamic loading of libraries, and hoping my code has as few dependencies as possible. I just hope for the best, and that Lazarus 1.0, stable, will come out. Best regards, Thierry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 13:09, Hans-Peter Diettrich drdiettri...@aol.com wrote: Can you suggest another interface, that better fits the various widgetset APIs? Maybe take a look at a widgetset that was designed from the start to be cross platform enabled. There are many to choose from. Don't base you interface on a very Windows specific widgetset like VCL or the Win32 API. And just to be clear, when I say interface I mean the glue code between the LCL and backend widgetset (gtk, qt, cocoa, fpgui). As far as I understand, the initial Lazarus developers had all intention in designing a cross-platform LCL from the start, so common sense should have prevailed. So where did they go wrong and decided to re-implement the Win32 API and force that upon all other widgetsets? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 7, 2010 at 7:49 PM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: On 7 March 2010 13:09, Hans-Peter Diettrich drdiettri...@aol.com wrote: Can you suggest another interface, that better fits the various widgetset APIs? Maybe take a look at a widgetset that was designed from the start to be cross platform enabled. There are many to choose from. Don't base you interface on a very Windows specific widgetset like VCL or the Win32 API. And just to be clear, when I say interface I mean the glue code between the LCL and backend widgetset (gtk, qt, cocoa, fpgui). As far as I understand, the initial Lazarus developers had all intention in designing a cross-platform LCL from the start, so common sense should have prevailed. So where did they go wrong and decided to re-implement the Win32 API and force that upon all other widgetsets? Designing a cross-platform LCL from the start will take another long time, if we watch the Lazarus code you can feel it is changed to be as like we need, they deprecated the Handle of some objects for example. But i will translate your message, you dislike to see emulation Windows API functions. Thanks Zaher Dirkey -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 14:21, Michael Van Canneyt mich...@freepascal.org wrote: The downside to this is: there is also a lot less functionality. A simpler product is by definition easier to maintain. Being a one-man-band, things take a while to be implemented - especially if it's not the only thing you are working on. Looking at what v0.6 (last release of fpGUI) had and what v0.7 (soon to be released) will have, there is a huge amount of new components and features. v0.8 will have drag-n-drop, full clipboard support and MDI window type support, so fpGUI is becoming more feature complete. To give you an example of what I meant by easier to maintain. For the last 6 months I have pretty much 99% of my time developing under Linux - that included adding new features and components to fpGUI. Just the other day I though I better test my work under Windows. Fired up the VM session and even to my surprise, everything worked 100% like it did under Linux. That's the benefit I'm talking about - more common code reduces the amount of bugs and maintenance. And as soon as someone says 'I want native look and feel', you're That's what the themes are for. :) As for the feel - I haven't had a user complain yet. Most components (buttons, menus, comboboxes, grids etc.) all work like the users where used to under native Windows applications. So clearly it's just developers that have an issue with the feel, not the common user. If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL: See, now that is the type of thing I'm talking about. Have some goal for the LCL, and try and reach that goal. Currently, it's just from version to version, adding more features, introducing regression bugs and having no stable version of the IDE or LCL. Simply not ideal, and very hard to promote to others. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 14:30, Michael Van Canneyt wrote: For you, yes. I agree with Hans-Peter Diettrich... I thinking everybody (except for Martin) agrees with Hans-Peter. MSEgui code is very hard to read. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
07.03.2010 20:46, Thierry Coq пишет: Maxim Ganetsky wrote: 06.03.2010 22:38, Thierry Coq пишет: As a user, I don't understand the team structure, now how can I report a bug or contribute to its correction? This should be clearer, in my opinion. That's really strange. Have a look at http://wiki.lazarus.freepascal.org/How_do_I_create_a_bug_report Thanks ;-) This doesn't solve the issue on when this bug will be corrected, what path will it take, who can correct or test the correction, etc. This shouldn't be an issue for contributor. If he wants to have an influence on the path the fix will take he can always attach a patch or leave a comment in bugtracker. The casual (would-be) contributor such as myself seems excluded and not really wanted. This is a perception that I have, unwillingly. I don't see this problem and haven't ever had feelings like that. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Graeme Geldenhuys schreef: there is no stable version of Lazarus - this is my major concern. As I mentioned, we currently maintain our own stable version of Lazarus IDE, but this should come standard with the Lazarus project. It should not be the job of the end-users to make there own stable versions of the IDE. Do you want to be the maintainer of the stable version? Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 07, 2010 at 06:46:56PM +0100, Thierry Coq wrote: This doesn't solve the issue on when this bug will be corrected, what path will it take, who can correct or test the correction, etc. The casual (would-be) contributor such as myself seems excluded and not really wanted. This is a perception that I have, unwillingly. From? For the moment, Lazarus is enough for my prototyping, and I'm waiting for a stable, 1.0 version. Until then, there is no chance as a professional developer that I could recommend this tool, although it shows great promise. In the meantime, I develop a few components, testing such issues such as COM/DCOM and dynamic loading of libraries, COM is getting better, slowly (noticable in 2.5.1, but still not perfect, specially wrt exceptions. Will be in FPC 2.6 at the earliest). I don't see any big development (or interest from _contributing_ users) in dynamic libraries. (and there are many pitfalls and multiplatform gotcha's here. There is not even a good inventorisation what should work how). So unless somebody is going to invest major amounts of times, I don't see this happening in say the coming two years _AT LEAST_. More importantly though, most of this are FPC features, and not Lazarus so unrelated to Lazarus 1.0 or not. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Where is TDataSource registered
Joost van der Sluis schreef: Hi all, I want to add registration of the TBufDataset component. I thought it would be the best to do it in the same manner as TDataSource is registered, since TBufDataset is always available. But I can not find where/how TDataSource is registered?!? lazarus\packager\registerfcl.pas procedure RegisterDB; Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, 7 Mar 2010, Graeme Geldenhuys wrote: To give you an example of what I meant by easier to maintain. For the last 6 months I have pretty much 99% of my time developing under Linux - that included adding new features and components to fpGUI. Just the other day I though I better test my work under Windows. Fired up the VM session and even to my surprise, everything worked 100% like it did under Linux. That's the benefit I'm talking about - more common code reduces the amount of bugs and maintenance. Yes, but you disregard the native look and feel. As soon as you must introduce that, there will be less common code. And as soon as someone says 'I want native look and feel', you're That's what the themes are for. :) As for the feel - I haven't had a user complain yet. Most components (buttons, menus, comboboxes, grids etc.) all work like the users where used to under native Windows applications. So clearly it's just developers that have an issue with the feel, not the common user. This is manifestly uncorrect. Show your product and a competing product with roughly similar features but using 'standard' windows controls, and you can be assured that the user will choose for the standard one. I am not pulling this out of my hat, this is feedback from the sales manager after demos for potential clients. I can only guess, but I think the reason you are getting away with your path is that you're in a situation where there simply is no competing product. If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL: See, now that is the type of thing I'm talking about. Have some goal for the LCL, and try and reach that goal. Currently, it's just from version to version, adding more features, introducing regression bugs and having no stable version of the IDE or LCL. Simply not ideal, and very hard to promote to others. Personally, I don't have the impression that there are regressions, and I work with Lazarus daily. But that doesn't show much, it can be that I simply don't use the areas under development. I can only regret that this happens to you, but it is up to the Lazarus devels to declare a complete feature stop and work to 1.0. This is one of the benefits of commercial companies: there the pressure for a feature stop and enter a bug-fixing phase is simply larger. As a developer, one is paid for it, it is ones job. it probably shows in fpGUI. Lazarus is a hobby for most that work on it; so there is less pressure. And for the record: none of what I write is meant to diminish the achievements of fpGUI. I think it is a hell of a job to create a widgetset. But I do believe that if the same time had been spent on the LCL, Lazarus might have already been at 1.0. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, 7 Mar 2010, Florian Klaempfl wrote: Michael Van Canneyt schrieb: I write all lowercase exactly because all lowercase has the best readability for me. With camelcase style a symbol breaks into sub-symbols for me which can't be recognised and processed as fast by my brain. I don't think that you can credit the lowercase letters for your increased productivity. Most of the compiler is lowercase due to Martin's reason :) I know this, but my argument is that this is a personal preference, not an inherent benefit of lowercase code :-) Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, 7 Mar 2010, Daithi Haxton wrote: Hi! I've not posted here before, but I've been reading this list for about six months, and I've gotta weigh in on this one. By way of introduction, I'm the Sr. Software Engineer/Team Lead for a major consumer electronics company in the US. We've been using C++ Builder for several years as our PC compiler of choice. It's allowed us to develop robust applications in very short time spans with very limited resources. [ snip ] In summary, Lazarus is a fantastic product. It's usable TODAY for commercial development. We've found it (the IDE) more stable on Windows than it's commercial counterparts. RAD Studio will generally lock at least one of our development machines once a day Oh well, for me Delphi is no longer usable as a debugger since years. So much for commercial products sometimes :/ - so far we've had only one issue with Lazarus, and that was on a Mac (and I reported the bug to Mantis, and it was fixed in three days - try that with you-know-who ). These discussions are great, but please don't lose sight of what you've already got - a world class compiler and development tool that's being used right now to solve serious real world problems. Which is exactly why I think that the person who started this thread has tunnel-vision problems. The glass is half-full for me. Thank you for this supportive comment ! Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
About Mantis graph of the issues (discussed in the beginning of the thread). There's CSV export available: http://bugs.freepascal.org/csv_export.php for any user (login is not required). So lnet (or synapse) + gui (lcl, msegui, fplib) or any image processing lib and one can get the graph image localy :) thanks, dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hello Lazarus-List,
Sunday, March 7, 2010, 5:51:33 PM, you wrote:
HPD I already made an C-to-Pascal converter
HPD http://sourceforge.net/projects/topas/, but then got stuck in handling
HPD #defines, which deserve translation into either constants or functions,
HPD or must be expanded.
HPD I never wanted it to handle C++ syntax, but if you have ideas how to
HPD make it usable for (partial) translation of C++ code, I'm willing to
HPD update it accordingly.
I think that it would be great to have something that can sintax
traslate from C++ to Pascal, but not a whole code with defines,
macros, and other things, just a plain block syntax converter, that
could simplify manual conversion, like creating the var block,
handling the if {} conversion and always take the simple route, not
trying to be smarter than the user ;)
Integrating this in the IDE could help to convert function by
function, without too many changes.
--
Best regards,
JoshyFun
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Marco van de Voort wrote: On Sun, Mar 07, 2010 at 06:46:56PM +0100, Thierry Coq wrote: This doesn't solve the issue on when this bug will be corrected, what path will it take, who can correct or test the correction, etc. The casual (would-be) contributor such as myself seems excluded and not really wanted. This is a perception that I have, unwillingly. From? This list, for example. For the moment, Lazarus is enough for my prototyping, and I'm waiting for a stable, 1.0 version. Until then, there is no chance as a professional developer that I could recommend this tool, although it shows great promise. In the meantime, I develop a few components, testing such issues such as COM/DCOM and dynamic loading of libraries, COM is getting better, slowly (noticable in 2.5.1, but still not perfect, specially wrt exceptions. Will be in FPC 2.6 at the earliest). Yes, I'm very happy about that. It's already possible to work with COM, although the coding is a manual activity. I've done a COM interface to Excel which works quite nicely. I don't see any big development (or interest from _contributing_ users) in dynamic libraries. (and there are many pitfalls and multiplatform gotcha's here. There is not even a good inventorisation what should work how). So unless somebody is going to invest major amounts of times, I don't see this happening in say the coming two years _AT LEAST_. Yes, the effort is probably large. The Lazarus team has done the same multi-platform miracle for GUIs, so it could be done. I know for a fact dynamic loading can be done in some cases, as I have done preliminary testing on the subject and have demonstrated it can be done (manually) with the current environment. It could be possible at least to be able to load packages compiled with the same version (of FPC and Lazarus). The principle of one code, compiling for each platform could be applicable here, too. I completely agree that loading packages built with other compilers than FPC would much more arduous. So maybe there is a staged path to add this feature. So there would be limits and caveats, but it would still be a great feature of Lazarus in its effort to be compatible with Delphi. More importantly though, most of this are FPC features, and not Lazarus so unrelated to Lazarus 1.0 or not. No, I don't believe dynamic packages is only a FPC feature. Being able to dynamically load components in the IDE without recompiling would be a great improvement in FPC, as well as implementing one of the oldest features of Delphi. It would also allow people like me, users of Lazarus and builders of components to have a more external view away from the internals of Lazarus, and maybe create an ecosystem for lazarus components. Also being able to load dynamically packages would be a great benefit for creating easily configurable or extensible applications. Don't take my constructive wishes for Lazarus improvements for anything worse than what they are: I'm very happy that Lazarus exists, and I try to use it as much as possible. I wish to thank the core team for this great piece of work! -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
2010/3/7 Zaher Dirkey parm...@gmail.com: Designing a cross-platform LCL from the start will take another long time, Obviously it's a bit late now for such a large design changes. As Michael suggested, maybe make it a v2.0 goal. But that will be decades away. :) But i will translate your message, you dislike to see emulation Windows API functions. YES, there is no need for it! As far as I understand, there is/was two three goals for the Lazarus project. 1) Delphi compatible (we don't know which version though) 2) Cross platform 3) Native widgets to help the look and feel argument. All of the above is possible without emulating the Windows API, so why pollute the LCL with such Windows-ism (I don't know a real word for this). As I said, I was looking last night at how much work it will be to implement LCL-fpGUI widgets. Immediately I see two units named fpguiwinapi.inc and fpguiwinapih.inc, and I think to my self - what the fuck?? Why does LCL require all other widgetsets to implement the API of a single platform? Just look at Qt, GTK2, fpGUI, MSEgui - all cross platform widgetsets without the need of re-implementing the Windows API, so why does LCL require it. Bad design? Then take a look inside the winapih.inc and see all the methods that must be implemented by each backend widgets. Those methods uses Win32 API types like HDC, WHND, HBITMAP, GDIObject, HGDIOBJ, HHOOK etc... All those types mean nothing to Qt, GTK1, GTK2, Cocoa, Carbon, fpGUI - yet we are expected to somehow make sense of those and translate them so something relevant in each of the other non-Windows toolkits. Absurd design. And this probably contributes to the problems all other widgetset maintainers have and the cause of stability problems. Not only do they need to know their own widgetset, they need to have intricate knowledge of the Windows API before they can implement their widgetset backend (even though that backend has nothing to do with Windows). :-( -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 20:13, Vincent Snijders vsnijd...@vodafonevast.nl wrote:
Do you want to be the maintainer of the stable version?
I wouldn't know how using SVN - we use Git remember. Our method of
getting a stable version would also probably not be appropriate for
others. On a serious note, below is what we do, and I honestly can't
see how this would be done in SVN.
We try various revisions of Trunk until we hit a sweet spot revision
that seems quite workable. This is a trial and error test. Once we
found one, we tag that revision and create our stable branch off that
tag. As soon as we hit a issue, we do a quick search through the newer
trunk revisions to see if there was a fix, if so, we cherry-pick that
into our own branch based on the Tag we choose before. If there was no
fix, we create a feature branch off Trunk with the fix (and send the
patch to Mantis). We that merge that fix branch into our stable
branch. We also have various other feature branches that we can
merge in with our stable branch to give us our added (personal)
wishlist features. In my case I always merge in the tabs on right[1]
and file filters editor[2] branches.
[1] hack to get editor tabs on right side of editor
[2] http://bugs.freepascal.org/view.php?id=15679
o Fix A
/ o Fix B
/ /
---A---o---o---o---o Trunk
\ \
\ D Feature branch 1
\ \
B---C---o---E
A = tagged the sweet spot revision
B, C = cherry-picked 'Fix A' and 'Fix B' into new branch created from A
D = Some home grown feature branch like [1] or [2] above
E = My personal branch which has stable C and merged in feature D branch
Then periodically we will revise the Trunk branch and tag a new sweet
spot revision. We will then rebase our home grown feature branches
('git rebase' means it takes the patches in a feature branch and
replays them on a new Trunk revision so they always stay up to date
and can merge easily if needed because they are based on a newer trunk
revision). We then start the whole process again.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Hello Lazarus-List, Sunday, March 7, 2010, 10:20:33 PM, you wrote: GG Then take a look inside the winapih.inc and see all the methods GG that must be implemented by each backend widgets. Those methods uses GG Win32 API types like HDC, WHND, HBITMAP, GDIObject, HGDIOBJ, HHOOK GG etc... All those types mean nothing to Qt, GTK1, GTK2, Cocoa, Carbon, GG fpGUI - yet we are expected to somehow make sense of those and GG translate them so something relevant in each of the other non-Windows GG toolkits. Absurd design. That's just a bunch of names and defines, HANDLES in windows are GObject in GTK or any other identifier. The winapi names are IMHO to achieve two goals, one get a desired behavior compatible with delphi and a behavior well documented in MSDN, so FillRect is well defined in MSDN on how it should perform. Do you really think that FillRectangleWithBrushAndPen function name is better than FillRect ? It is the Lazarus graphic abstraction which is more or less compatible with Windows abstraction. -- Best regards, JoshyFun -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 7, 2010 at 9:21 AM, Michael Van Canneyt mich...@freepascal.org wrote: It has always pained me to see lazarus' LCL re-introducing the Windows API to such an extent. If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL: People need those routines to port component packages mostly. The Windows API routines are not an end in themselves and they are also not to be removed (without generating a lot of trouble for people that need them). The solution is much simpler and elegant: simply provide as well a native LCL class or extension of existing classes to also implement the functionality natively in the LCL as well. This can internally refer to the WinAPI routines, so we don't need 2 implementations of the same thing while exposing 2 APIs for it. I don't see why the mere existence of the WinAPI routines is an issue. While writing the book I used those APIs almost never, you can pretty much ignore them and if you find yourself in a situation where you can't ignore them it's just because we still miss some code to also implement them in LCL style. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 20:47, Michael Van Canneyt mich...@freepascal.org wrote: Yes, but you disregard the native look and feel. As soon as you must introduce that, there will be less common code. The benefits of a custom drawn toolkit - we can choose what features to support. :-) This is manifestly uncorrect. Show your product and a competing product with roughly similar features but using 'standard' windows controls, and you can be assured that the user will choose for the standard one. I can assure you that if I disable the gradient color selection, enable system color detection, then most common components are to the pixel accurate with Win2000 or WinXP un-themed look - default theme in fpGUI. I should probably mention that most of our clients are still running Win98 and Win2000, so this helps us too. I've spent many hours with 'xmag' observing Win98, Win2000 and WinXP screenshots so I can recreate the look - to the pixel. This year I'll be enabling the same for WinXP, Vista, Motif and Clearlooks. WinXP and Motif are each about 90% complete. This should be sufficient to fool most common end-users. I can only guess, but I think the reason you are getting away with your path is that you're in a situation where there simply is no competing product. The benefit of being the best in the market. :-) And for the record: none of what I write is meant to diminish the achievements of fpGUI. I have not taken any offence either - you are simply speaking of what you know. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Sun, Mar 7, 2010 at 6:20 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote Then take a look inside the winapih.inc and see all the methods that must be implemented by each backend widgets. Those methods uses Win32 API types like HDC, WHND, HBITMAP, GDIObject, HGDIOBJ, HHOOK etc... All those types mean nothing to Qt, GTK1, GTK2, Cocoa, Carbon, fpGUI You would need to map all those widgetsets to something anyway, so mapping a part of them to WinAPI routines is not a big difference. The winapi is very well documented and their docs can be easily found with google. While starting the qt widgetset these winapi routines weren't at all an obstacle, they were no problem for the port. The greatest problem I had was lack of documentation about how each thing needs to be implemented, but I started a guide on that here: http://wiki.lazarus.freepascal.org/LCL_Internals IMHO your objection to the design is based on a very superficial view. Just to reinforce: As I explained the user shouldn't have to care about that, all features should have LCL-style API offered as well, so the WinAPI are only for interface developers and for people porting from Delphi, and I don't see them as a problem for widgetset developers as you would need to map to something alien to the widgetset anyway. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On Mon, Mar 8, 2010 at 12:12 AM, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Sun, Mar 7, 2010 at 9:21 AM, Michael Van Canneyt mich...@freepascal.org wrote: It has always pained me to see lazarus' LCL re-introducing the Windows API to such an extent. If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL: People need those routines to port component packages mostly. The Windows API routines are not an end in themselves and they are also not to be removed (without generating a lot of trouble for people that need them). The solution is much simpler and elegant: simply provide as well a native LCL class or extension of existing classes to also implement the functionality natively in the LCL as well. This can internally refer to the WinAPI routines, so we don't need 2 implementations of the same thing while exposing 2 APIs for it. Yes that help me to port many component to Lazarus. But it can make spicial unit only for those porting components, and for who have more time can replace the function taht call API function to call LCL function API FillRect(DC: HDC; to LCL FillRect(Canvas: TCanvas; to Object Canvas.FillRect(R:TR...) Ok i am very slow writing in english :) -- Zaher Dirkey -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
On 7 March 2010 20:55, Michael Van Canneyt wrote: Which is exactly why I think that the person who started this thread has tunnel-vision problems. The glass is half-full for me. I now understand what you meant with that statement, and I think you are right. ;-) Lazarus is an impressive product, I'm not arguing that. And obviously, it is fantastic to hear stories like Daithi's one. This does make me take note of what Lazarus has already accomplished. I guess I have been too long around Lazarus and simply take the features for granted. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Problems with accented characters
Hi friends, I'm trying to create a function to replace accented characters by single characters, e.g: ã = a é = e ç = c ñ = n I'm trying to use OnKeyDown and OnUTF8KeyPress, but is not working, so I made some tests and saw that the problem is in the component: Code: - procedure TForm1.Button1Click(Sender: TObject); begin Edit2.Text := Edit1.text[1] end; - When: Edit1.Text = 'A', Edit2.Text = 'A'; When: Edit1.Text = 'Ã', Edit2.Text = '', empty; What can this be? I started a thread here: http://www.lazarus.freepascal.org/index.php/topic,8816.msg42665.html#msg42665 -- []'s Silvio Clécio -- programmer ObjectPascal - Blog: http://blog.silvioprog.com.br programmer ObjectPascal - Site: http://www.silvioprog.com.br programmer ObjectPascal - Twitter: http://twitter.com/silvioprog -- grupo Lazarus-BR no Google - http://groups.google.com/group/lazarus-br/ -- Mensagem assinada com PGP Public Key, Ver.: GnuPG v1.4.9 (GNU/Linux) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
On Sun, Mar 7, 2010 at 7:29 PM, Silvio Clecio silviop...@gmail.com wrote: I'm trying to create a function to replace accented characters by single characters, e.g: Maybe you should show how your code for this is. The easiest way is making a large if block. Code: - procedure TForm1.Button1Click(Sender: TObject); begin Edit2.Text := Edit1.text[1] end; - There is no problem here, Lazarus encodes strings using UTF-8. This code is simply completely flawed. The [] operator refers to bytes of the string, so you are only taking the first byte of the string and assigning it to the text of the TEdit, which obviously only works for single byte characters, but UTF-8 chars usually have 1, 2 or 3 bytes. I suggest that you read more on UTF-8: http://en.wikipedia.org/wiki/UTF-8 -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Hi Felipe I know this link on the wiki, but it did not really help you solve the problem in TCustomEdit. See this demo, I explain it better how to reproduce the error: http://groups.google.com.br/group/lazarus-brasil/web/be_bug_tests.zip?hl=pt-BR Thanks. Felipe Monteiro de Carvalho escreveu: On Sun, Mar 7, 2010 at 7:29 PM, Silvio Clecio silviop...@gmail.com wrote: I'm trying to create a function to replace accented characters by single characters, e.g: Maybe you should show how your code for this is. The easiest way is making a large if block. Code: - procedure TForm1.Button1Click(Sender: TObject); begin Edit2.Text := Edit1.text[1] end; - There is no problem here, Lazarus encodes strings using UTF-8. This code is simply completely flawed. The [] operator refers to bytes of the string, so you are only taking the first byte of the string and assigning it to the text of the TEdit, which obviously only works for single byte characters, but UTF-8 chars usually have 1, 2 or 3 bytes. I suggest that you read more on UTF-8: http://en.wikipedia.org/wiki/UTF-8 -- []'s Silvio Clécio -- programmer ObjectPascal - Blog: http://blog.silvioprog.com.br programmer ObjectPascal - Site: http://www.silvioprog.com.br programmer ObjectPascal - Twitter: http://twitter.com/silvioprog -- grupo Lazarus-BR no Google - http://groups.google.com/group/lazarus-br/ -- Mensagem assinada com PGP Public Key, Ver.: GnuPG v1.4.9 (GNU/Linux) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Hello Marco, thanks for the response :) I'll test it, I give a return in a moment. Will send the demos that I'm trying to do, please see how the error appears to be in TCustomEdit. Sending (WithoutAccent-pt_BR) in a moment... Marco Alvarado escreveu: Hello Silvio! On Sun, Mar 7, 2010 at 7:29 PM, Silvio Clecio silviop...@gmail.com wrote: I'm trying to create a function to replace accented characters by single characters, e.g: Try the UTF8-Tools units: http://wiki.lazarus.freepascal.org/Theodp At the end of the page there is an example Case demo on replacing accented characters. Best regards! -Marco -- []'s Silvio Clécio -- programmer ObjectPascal - Blog: http://blog.silvioprog.com.br programmer ObjectPascal - Site: http://www.silvioprog.com.br programmer ObjectPascal - Twitter: http://twitter.com/silvioprog -- grupo Lazarus-BR no Google - http://groups.google.com/group/lazarus-br/ -- Mensagem assinada com PGP Public Key, Ver.: GnuPG v1.4.9 (GNU/Linux) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Hello Lazarus-List, Sunday, March 7, 2010, 11:57:45 PM, you wrote: SC I know this link on the wiki, but it did not really help you solve the SC problem in TCustomEdit. SC See this demo, I explain it better how to reproduce the error: SC http://groups.google.com.br/group/lazarus-brasil/web/be_bug_tests.zip?hl=pt-BR So your problem is that UTF8Key is not realtime modificable as Key in KeyPress event ? As UTF8Key appears as var parameter it looks like a bug to me. Meanwhile you can use KeyPress to perform the task converting key to UTF8, perform the changes needed and them convert back to ansi mode. This way when UTF8KeyPress accepts changed UTF8Key (if it should do it) you should simply change the routine position and remove the 2 conversion lines. -- Best regards, JoshyFun -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Marco, I tested now, is really an very good package :) You have some example to replace the text in real time using this package? Please see this, I'm trying to do and only works right with OnChange: http://lazarus-brasil.googlegroups.com/web/be_bug_tests_II.zip (or: http://bit.ly/aknuUm) I need to avoid the OnChange; up of the 500 characters this function slows. Thanks again :) Marco Alvarado escreveu: Hello Silvio! On Sun, Mar 7, 2010 at 7:29 PM, Silvio Clecio silviop...@gmail.com wrote: I'm trying to create a function to replace accented characters by single characters, e.g: Try the UTF8-Tools units: http://wiki.lazarus.freepascal.org/Theodp At the end of the page there is an example Case demo on replacing accented characters. Best regards! -Marco -- []'s Silvio Clécio -- programmer ObjectPascal - Blog: http://blog.silvioprog.com.br programmer ObjectPascal - Site: http://www.silvioprog.com.br programmer ObjectPascal - Twitter: http://twitter.com/silvioprog -- grupo Lazarus-BR no Google - http://groups.google.com/group/lazarus-br/ -- Mensagem assinada com PGP Public Key, Ver.: GnuPG v1.4.9 (GNU/Linux) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE search path for include file causes IDE hang
On Sun, 7 Mar 2010 10:53:19 -0600 Andrew Brunner andrew.t.brun...@gmail.com wrote: I wanted to know if anyone reported a bug that has to do with include files and the helper component that consistently crashes the IDE. I had dealt with this bug for the past few weeks. It wasn't until I ran ./startlazarus from command prompt that showed me that a unit referencing an include unit could not be found. I'm not sure, what you mean with include unit. A unit is used (by the uses section), an include file is included (by the include directive). I guess, you mean an include file was not found? I solved the problem by adding the path of the include file to the IDE paths in project options/paths but I wonder if a certain user segment is experiencing this issue. This was a trivial error that was easily solved once I knew what the problem was. The fact remains that the IDE should have displayed a dialog box telling me the path needed to be added to that path option so the IDE can function properly. ok. I need some information how to reproduce the problem. Was there an error message? What was the error message? I can add a popup menu (quick fix item) for this message. I had to deal with this problem for a week and it was always crashing my Lazarus. Man... I kept doing svn updates for FPC and Lazarus and I think I'm a bit frustrated at the fact that the problem was so simple to solve, and the crash was totally avoidable. I'm thinking that if possible, we should re-think the logic of paths. Crash? It's ok to have a seperate option but for bare minimums, behind the scenes, perhaps we could use an aggregate or at least a dialog box saying project unit whatever.pas includes include.inc and cannot be located. Please set a path reference in the IDE path options for this project. And a button to get there. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
You have some example to replace the text in real time using this package?
Sorry, I don't have an example like that, but the example listed on
the page seems simple enough:
s := TUTF8Scanner.Create(Memo1.text);
s.FindChars := 'öäü';
repeat
case s.FindIndex(s.Next) of
{ö} 0: s.Replace('oe');
{ä} 1: s.Replace('ae');
{ü} 2: s.Replace('ue');
end;
until s.Done;
Memo1.Text := s.UTF8String;
s.free;
Hope it helps!
-Marco
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Hellow JoshyFun,
JoshyFun escreveu:
So your problem is that UTF8Key is not realtime modificable as Key
in KeyPress event ?
As UTF8Key appears as var parameter it looks like a bug to me.
Yes. For me too. And here em my PC, OnKeyPress works normal only for
Windows (XP). :(
Meanwhile you can use KeyPress to perform the task converting key to
UTF8, perform the changes needed and them convert back to ansi mode.
This way when UTF8KeyPress accepts changed UTF8Key (if it should do
it) you should simply change the routine position and remove the 2
conversion lines.
In a very simple test, I'm trying this:
[code]
const
CWithAccent: array [0..46] of string = ('à', 'á', 'â', 'ã', 'ä', 'è', 'é',
'ê', 'ë', 'ì', 'í', 'î', 'ï', 'ò', 'ó', 'ô', 'õ', 'ö', 'ù', 'ú',
'û', 'ü',
'À', 'Á', 'Â', 'Ã', 'Ä', 'È', 'É', 'Ê', 'Ë', 'Ì', 'Í', 'Î', 'Ò',
'Ó', 'Ô',
'Õ', 'Ö', 'Ù', 'Ú', 'Û', 'Ü', 'ç', 'Ç', 'ñ', 'Ñ');
CWithoutAccent: array [0..46] of string = ('a', 'a', 'a', 'a', 'a',
'e', 'e',
'e', 'e', 'i', 'i', 'i', 'i', 'o', 'o', 'o', 'o', 'o', 'u', 'u',
'u', 'u',
'A', 'A', 'A', 'A', 'A', 'E', 'E', 'E', 'E', 'I', 'I', 'I', 'O',
'O', 'O',
'O', 'O', 'U', 'U', 'U', 'U', 'c', 'C', 'n', 'N');
uses
StrUtils;
procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: char);
begin
Key := StringsReplace(AnsiToUtf8(Key), CWithAccent, CWithoutAccent,
[rfReplaceAll])[1];
end;
[/code]
(Please, see well here: http://pastebin.com/qmu80j74)
But unfortunately is working only on Windows. :(
--
[]'s
Silvio Clécio
--
programmer ObjectPascal - Blog: http://blog.silvioprog.com.br
programmer ObjectPascal - Site: http://www.silvioprog.com.br
programmer ObjectPascal - Twitter: http://twitter.com/silvioprog
--
grupo Lazarus-BR no Google - http://groups.google.com/group/lazarus-br/
--
Mensagem assinada com PGP Public Key, Ver.: GnuPG v1.4.9 (GNU/Linux)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
I agree with everything Tom has said. I hope everyone takes it to heart. I'm one of those who is lurking and waiting for a more stable project before jumping in and joining the team as a volunteer. I've tried both FPC and Lazarus and found them wanting for all the reasons that have already been mentioned. I have no immediate need to use them and therefore have the luxury of experimenting only but I would like to commit to using them full time. At the rate things are going I'll probably end up using Embarcadero's coming cross platform solution before using FPC/Lazarus. That would be a shame. A couple of further specific comments: I see a bunch of bugs reported and developers posting that those are fixed. But unless I wade in and install SVN and figure out how to use it to update my local source and figure out how to compile FPC and Lazarus I cannot make use of those bug fixes. So I'm stuck with the choice of installing a rather old stable version and living with the bugs it has (that I know have been fixed) or waiting until a new stable version is packaged up. I choose to wait (again, because I have no compelling reason not to). But that, in turn, keeps me away from the project so that I cannot learn more about it and cannot help out because I'm forever on the outside looking in. I have avoided CVS, and so far successfully avoided SVN, because I see them as rather old technology. In contrast, Git is an amazingly powerful and fresh look at the problem. I'd rather start out using Git. But when Git was proposed to the FPC/Laz projects it was rather soundly brushed aside. Another reason for me to stay on the sidelines. When 2.4.0 was released I thought, Ok, maybe I should start with that. So I went about installing and building and learning my way around. Then came to a crashing halt when I learned you could not build Lazarus using the 2.4.0 FPC. Huh? Made me wonder if these teams even talk to each other. Another reason to hold off diving in so I turned aside and got involved in other things. I've been to the web sites and looked for installation instructions and tutorial help but things are scattered and not easy to find. When this is mentioned on the mailing lists people respond with direct links to the items being sought. Yes, that is helpful, but the larger point seems to be missed. These web sites need to be improved specifically with an eye toward the new convert. There is some talk of doing that but it is rather piecemeal. I think a larger initiative is called for. I've read the testaments of those who have found FPC/Lazarus to be production ready. (In fact, those are the things that keep me interested!) But I get the impression that those testaments are being received by the core teams as evidence that all is well. If so, please re-read Tom's message and find some real answers to those questions because I think there are more people waiting for the big symbolic 1.0 than there are that have found a way to make the current code work for them. Reaching 1.0 is important not so much because a 1.0 release would contain major improvements to the code but more because it would mean the projects have matured organizationally. That is what I'd like to see. Doug C. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE search path for include file causes IDE hang
On Sun, Mar 7, 2010 at 5:51 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: I need some information how to reproduce the problem. Was there an error message? What was the error message? The error was from internal component that utilizes the IDE paths for scanning Lazarus only units. That unit was referencing another include located not in that unit's folder but somewhere else. Crash? Oh yes. Symptoms were on Windows 7 and Ubuntu x64 with latest kernel push. I'll see if I can generate a test case. By tomorrow morning. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Am Sonntag 07 März 2010 12:30:16 schrieb Hans-Peter Diettrich: Florian Klaempfl schrieb: Why should I waste time and change to a different program while I could do this in the file open/save dialog? Then the file dialogs must use the platform specific file managers. On Windows, the dialogs expose functionality of file explorer, on Linux that of the installed or preferred Nautilus, Konqueror or whatsoever. Please note that the dialogs shall *use* the managers, *not emulate* them. I'm not sure how this is feasable. It also would mean that eventual dialog customization differs for every platform. DoDi I think Pavel Kanzelsberger did it quite nice in Pixel: his open/save dialogs show lots of info and fit nicely into the interface, but you can choose (in the options) to have system default open/save dialogs instead. Just my two cents ... Best Regards, Andreas. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Am Montag 08 März 2010 01:58:22 schrieb Doug Chamberlin: [] A couple of further specific comments: I see a bunch of bugs reported and developers posting that those are fixed. But unless I wade in and install SVN and figure out how to use it to update my local source and figure out how to compile FPC and Lazarus I cannot make use of those bug fixes. So I'm stuck with the choice of installing a rather old stable version and living with the bugs it has (that I know have been fixed) or waiting until a new stable version is packaged up. I choose to wait (again, because I have no compelling reason not to). But that, in turn, keeps me away from the project so that I cannot learn more about it and cannot help out because I'm forever on the outside looking in. I have avoided CVS, and so far successfully avoided SVN, because I see them as rather old technology. In contrast, Git is an amazingly powerful and fresh look at the problem. I'd rather start out using Git. But when Git was proposed to the FPC/Laz projects it was rather soundly brushed aside. Another reason for me to stay on the sidelines. [...] You don't have to build FPC. Just building Lazarus is enough. And not even that is required, thanks to daily snapshots: (with installers!) http://www.hu.freepascal.org/lazarus/ Best Regards, Andreas. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Hello Marco, no problems friend :)
I'm trying with TUTF8Scanner + OnKeyPress, and TUTF8Scanner +
OnUTF8KeyPress, but not works. :(
Another test that fails:
procedure TForm1.Edit1UTF8KeyPress(Sender: TObject; var UTF8Key: TUTF8Char);
begin
UTF8Key := 'Ç';
end;
Appear the caracters of the current typing in Edit, and not 'Ç'. :(
Marco Alvarado escreveu:
You have some example to replace the text in real time using this package?
Sorry, I don't have an example like that, but the example listed on
the page seems simple enough:
s := TUTF8Scanner.Create(Memo1.text);
s.FindChars := 'öäü';
repeat
case s.FindIndex(s.Next) of
{ö} 0: s.Replace('oe');
{ä} 1: s.Replace('ae');
{ü} 2: s.Replace('ue');
end;
until s.Done;
Memo1.Text := s.UTF8String;
s.free;
Hope it helps!
-Marco
--
[]'s
Silvio Clécio
--
programmer ObjectPascal - Blog: http://blog.silvioprog.com.br
programmer ObjectPascal - Site: http://www.silvioprog.com.br
programmer ObjectPascal - Twitter: http://twitter.com/silvioprog
--
grupo Lazarus-BR no Google - http://groups.google.com/group/lazarus-br/
--
Mensagem assinada com PGP Public Key, Ver.: GnuPG v1.4.9 (GNU/Linux)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Doug Chamberlin schreef: I have avoided CVS, and so far successfully avoided SVN, because I see them as rather old technology. In contrast, Git is an amazingly powerful and fresh look at the problem. I'd rather start out using Git. But when Git was proposed to the FPC/Laz projects it was rather soundly brushed aside. You never used CVS and SVN, so you have a choice, which to learn to use. I rather spend my time bug fixing and general Lazarus support than learning yet another source control, especially since the SVN is doing its job reasonably well. Yet the community has provided alternatives for people who rather use git: http://wiki.lazarus.freepascal.org/git_mirrors Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] PageControl vs NoteBook vs TabControl
Andreas Schneider het geskryf: Here's a problem: TNotebook is _not_ a tab-type component (well, actually it shouldn't be a tab-type component). The Delphi implementation is more or less just a page manager so you can have several layers on one form that you can switch between. To me, that is exactly what a tab-type component is. That's why it would also be important to have no borders Well how hard can it no be to add a new with borders or without borders property to the TNotebook. This minor detail still doesn't justify a complete separate component. on it. IMHO it's a very useful component (if implemented like in Delphi) - at least for smaller self-contained dialogs where frames would be too much. Yes, another option that says: Show/Hide tabs. Again, no reason to have two components that do exactly the same. A TabControl in contrast to a PageControl has _no_ pages. It really only consists of tabs, so it isn't a container in any way. Fine, I can see the difference with a TabControl, but the difference between a PageControl and a Notebook control is stupid. The later two could be rolled into one single component. So a PageControl is essentially a TabControl+Notebook. OS/2 has Notebook control that displayed tabs. So does many X11 widgetsets. I believe so does the Delphi Notebook control. It's just a different name for the exact same thing. Rolled into one, they would reduce maintenance, increase stability (because everybody use the same component). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Florian Klaempfl het geskryf: ... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui, To my surprise, Gnome also supports dragdrop to the File Dialog. :) I never knew that. neither the context menu works, Gnome only allows show hidden files or add to bookmarks/favourites list. so one can not create folders, rename files etc. Not allowed by Gnome either. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Felipe Monteiro de Carvalho het geskryf: People need those routines to port component packages mostly. The Windows API routines are not an end in themselves and they are also So do I understand this correctly. The winapih.inc only needs to be implemented to help support for porting of Delphi components to Lazarus? So can I implement all the other interface classes and have a working LCL or better yet, a working Lazarus IDE (using LCL-fpGUI) without the need for implementing the fpguiwinapih.inc unit? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problems with accented characters
Silvio Clecio wrote: I'm trying with TUTF8Scanner + OnKeyPress, and TUTF8Scanner + OnUTF8KeyPress, but not works. :( Another test that fails: procedure TForm1.Edit1UTF8KeyPress(Sender: TObject; var UTF8Key: TUTF8Char); begin UTF8Key := 'Ç'; end; Appear the caracters of the current typing in Edit, and not 'Ç'. :( It seems to be a bug in OnUTF8KeyPress, the similar behaviour was reported at Russian Free Pascal forum. Would you please create a bug report? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Zaher Dirkey het geskryf: Yes that help me to port many component to Lazarus. But it can make spicial unit only for those porting components, and for who have more time can replace the function taht call API function to call LCL function API FillRect(DC: HDC; to LCL FillRect(Canvas: TCanvas; to Object Canvas.FillRect(R:TR...) Then clearly you guys porting component to Lazarus are lazy. :-) I have ported numerous components from Delphi to fpGUI. During the port, I only use the functions available in fpGUI (no Win API calls). Porting does not take that long, and fpGUI isn't even as compatible with VCL as LCL is with VCL. The end result is guaranteed to be 100% cross platform. This just highlights the point that the Win API cloning was a bad idea. If you want to make something truly cross platform, you implement it as such, using to top-level interface of the LCL classes. You don't use the hack idea of the Win API clone unit - that is inherently not cross platform. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Marco van de Voort het geskryf: I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate. [off-topic] I gather you are using Dia for UML diagrams? If so, I urge you to take a look at Umlet. A small Java based UML diagram tool. It is really powerful, allows extensions by end-users, uses a text box design (so no popup dialogs) which results in really fast designing! I am now using Umlet exclusively as my UML design tool under Windows and Linux. It is a brilliant open source product. Updates are also frequent and the developers are friendly people. http://www.umlet.com Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Graeme Geldenhuys schrieb: On 7 March 2010 20:13, Vincent Snijders vsnijd...@vodafonevast.nl wrote: Do you want to be the maintainer of the stable version? I wouldn't know how using SVN - we use Git remember. Our method of getting a stable version would also probably not be appropriate for others. On a serious note, below is what we do, and I honestly can't see how this would be done in SVN. Replace rebase by merge and it works exactly the same with svn: you branch a new fixes branch and merge all needed feature branches. Though I think just merging new revision from trunk to the fixes branch is more svn style. However I consider not merging a feature branch into trunk but into a fixes branch as a rather chaotic development modell: trunk should imo contain all working stuff. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is Lazarus project in a downward spiral?
Doug Chamberlin het geskryf: I have avoided CVS, and so far successfully avoided SVN, because I see them as rather old technology. In contrast, Git is an amazingly powerful and fresh look at the problem. I'd rather start out using Git. But when Compiling from source code is really not that hard. It sounds more scary than it really is. :-) I'v setup several scripts on my system to compile for example FPC to different targets. As for Lazarus. I normally use the old executable to compile the new executable. As for using Git. You are in luck. I maintain the Git mirrors for FPC and Lazarus projects. More information can be found here: http://wiki.lazarus.freepascal.org/git_mirrors Here are some of the scripts I use. Not I use an old stable binary to compile the new binaries. Start a new thread if you need more information, or email me in private: graemeg at gmail dot com [ stable32.sh ]--- #!/bin/bash #make clean git checkout fixes_2.4 make all CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386 make install INSTALL_PREFIX=/opt/fpc_2.4.1/i386-linux/ CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386 --- ---[ stable64.sh ]-- make clean git checkout fixes_2.4 make all PP=/opt/fpc_2.2.5/bin/ppcx64 OPT=-gl make install INSTALL_PREFIX=/opt/fpc_2.4.1/x86_64-linux/ PP=/opt/fpc_2.2.5/bin/ppcx64 OPT=-gl ---[ trunk32.sh ]-- make clean git checkout master make all CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386 make install INSTALL_PREFIX=/opt/fpc_2.5.1/i386-linux/ CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386 As you can see, they are all pretty similar. Converting them to Windows batch files will also be easy. Only the Linux style paths would need to changes to Windows style paths. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
