Re: [lazarus] Introduction - NOTE FOR GRAHAM
On 29/01/2008, A.J. Venter [EMAIL PROTECTED] wrote: Sorry for the late response, I am backreading a bit - but I thought you should know this is NOT needed. gtkproc unit has a call load_rc I think which you can call in your application to load a custom theme file in a sepperate location for the running app ONLY. Not ideal, but a work-around for gtk1 cases perhaps ? Thanks for the response AJ. The other factor that comes into play is that we had lots of IFDEF's in our old code when we used Delphi and Kylix. Moving over to Lazarus we had the intent of not needing IFDEF's again as we run on mixed platforms. The above is a possible solution, but not ideal. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tuesday 29 January 2008 10.45:47 A.J. Venter wrote: MSEide+MSEgui is designed with the goal to provide identical look and feel on Linux and win32: http://sourceforge.net/projects/mseide-msegui/ Another main focus of MSEide+MSEgui are database components. Does it support lazarus components however ? I wouldn't even THINK of using it if I couldn't use the custom components I developed for lazarus - the ones included in lazarus now as well as the ones I just use myself. No, MSEgui is a fresh approach of GUI toolkit design which does not aim to be VCL compatible. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 29/01/2008, A.J. Venter [EMAIL PROTECTED] wrote: Have a look on SourceForge. I have seen quite a few toolkits implemented in C/C++ and uses OpenGL or SDL or whatever hw acceleration they picked. Eeeek ! Components should NOT require hardware acceleration support ! There is still a significant number of computers without this feature. I think if you used SDL you should be safe... I don't know SDL much, but doesn't that auto detect hardware acceleration and if nothing is found, switch to software rendering. Either way, it's not by baby I don't use any SDL or OpenGL features in any of my applications. I simply commented on what I found in SF.net Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
Thanks for the response AJ. The other factor that comes into play is that we had lots of IFDEF's in our old code when we used Delphi and Kylix. Moving over to Lazarus we had the intent of not needing IFDEF's again as we run on mixed platforms. The above is a possible solution, but not ideal. ;-) Hiya Graham, Well I wasn't actually saying it would be the answer for you right now - but I wanted to fix the misconception - it is possible to use a custom theme for just your program, ship it with it etc. In fact in some earlier versions of direqcafe I did that. Nowadays I use gtk2 for it and that nowadays already has the features I need. As for the whole 'native-look' debate: One thing keeps coming up in usability studies - every app on the user's desktop should behave the same to the largest possible extent. So the user does not need to learn how to navigate 20 types of file open dialogs. More and more even disparate systems like Linux is pursuing this - a kde distro will ship as few gnome apps as it can get away with - so the apps will behave the same - ditto for a gnome one. Now lazarus here offers the ability to create multi-platform apps that NEVERTHELESS blend into the desktop the user is using - that is a good thing in 99% of the cases. In fact the ONLY use case where it breaks down is the mixed environment - where people use the same app on many systems in the same place as a major app. There consistency for the app across environments becomes a higher priority. This use-case remains however by far the minority one. This is YOUR use-case though, and at least one other person here has the same one. So for you - the current lazarus falls short. For the rest of us - it's doing exactly what OUR users actually DEMAND. But, FPgui is well on it's way to fully supporting your use-case - and once it's LCL linked, lazarus will be able to meet either use-case. My time is rather limited, but (although I don't need it myself) I would like to help make this happen - so that lazarus can have yet another major capability - native-look or app-consistent becomes a choice of the developer based on the needs of HIS user-base. Can you mail me offlist with some of the priority missing pieces ? Then if I have time, I can send you back some patches to help it along. Ciao A.J. -- Any sufficiently advanced technology is indistinguishable from magic - Clarke's law Any technology that is distinguishable from magic is insufficiently advanced -Gehm's corollary Any technologist that is distinguishable from a magician is insufficiently advanced - My corollary The worlds worst webcomic: http://silentcoder.co.za/scartoonz The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za begin:vcard fn:AJ Venter n:Venter;AJ org:Global Pact Trading Pty. Ltd.;OutKast Solutions email;internet:[EMAIL PROTECTED] title:Director of Product Development tel;work:+27 21 554 5059 tel;fax:+27 11 252 9197 tel;cell:+27 83 455 9978 url:http://www.outkastsolutions.co.za version:2.1 end:vcard
Re: [lazarus] Introduction
Have a look on SourceForge. I have seen quite a few toolkits implemented in C/C++ and uses OpenGL or SDL or whatever hw acceleration they picked. Eeeek ! Components should NOT require hardware acceleration support ! There is still a significant number of computers without this feature. The brand new AMD64 I bought at the beginning of the year had an onboard card with no acceleration support ! I did add an nvidia card of my own so it didn't bother me - but to limit lazarus applications to only those machines with accelerated 3D would simply be a massively stupid thing for at least another 5 years. If you want hardware accelerated rendering - do it (optionally) on the graphical system level - that's the direction that composition managers, VISTA etc. all went - because the alternative is to start making a very expensive piece of extra hardware a requirement to even running the programs, even if they do not actually DO anything three dimensional. A.J. -- Any sufficiently advanced technology is indistinguishable from magic - Clarke's law Any technology that is distinguishable from magic is insufficiently advanced -Gehm's corollary Any technologist that is distinguishable from a magician is insufficiently advanced - My corollary The worlds worst webcomic: http://silentcoder.co.za/scartoonz The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za begin:vcard fn:AJ Venter n:Venter;AJ org:Global Pact Trading Pty. Ltd.;OutKast Solutions email;internet:[EMAIL PROTECTED] title:Director of Product Development tel;work:+27 21 554 5059 tel;fax:+27 11 252 9197 tel;cell:+27 83 455 9978 url:http://www.outkastsolutions.co.za version:2.1 end:vcard
Re: [lazarus] Introduction
On 29/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Aha ! So, in the end, the problem solves itself, if they are all on linux ;-) It's a slow process though! :-) +-250 franchisees with avg 25+ computers and +-230 schools with a avg 30+ computers. That's around 13150 computers. We can't force everybody to switch to Linux because in places like schools, the computers get used for other things as well. And you get the huge factor which slows things down - people are scared of something they are unfamiliar with. So we introduce new equipment with Linux so they can get a feel for things and see that it isn't that different (from a GUI point of view). This is where the side-by-side OS's come in play. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 29/01/2008, Alexsander Rosa [EMAIL PROTECTED] wrote: with mixed environments complained about the visual differences. They demanded a standard, consistent look and feel, regardless of the OS. A few This is exactly what our clients said. And more so when they ran a mixed environment - Linux and Windows side-by-side (which is becoming more and more so as they move to Linux). Rave Reports. We still plan to migrate to a binary-native solution and Lazarus is a top candidate -- however, the current LCL approach of using multiple widget sets may bring us back the same visual differences. That's why we started working on fpGUI. I think you have few options available though: * Wait a few months for the LCL-fpGUI widgetset * Help implement it, to have it done quicker. ;-) * Or use fpGUI directly without the LCL layer. For obvious reasons (no LCL-fpGUI yet) we opted for the last option. We still use Lazarus as our IDE and we (fpGUI) do have our own visual form designer. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 29 Jan 2008, Graeme Geldenhuys wrote: On 29/01/2008, Alexsander Rosa [EMAIL PROTECTED] wrote: with mixed environments complained about the visual differences. They demanded a standard, consistent look and feel, regardless of the OS. A few This is exactly what our clients said. And more so when they ran a mixed environment - Linux and Windows side-by-side (which is becoming more and more so as they move to Linux). Aha ! So, in the end, the problem solves itself, if they are all on linux ;-) Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
I remember I was told to use a custom theme file, but that would change it for all application, and I needed to change colors based on data entered in forms (validation things), so that solution was totally useless. Sorry for the late response, I am backreading a bit - but I thought you should know this is NOT needed. gtkproc unit has a call load_rc I think which you can call in your application to load a custom theme file in a sepperate location for the running app ONLY. Not ideal, but a work-around for gtk1 cases perhaps ? A.J. -- Any sufficiently advanced technology is indistinguishable from magic - Clarke's law Any technology that is distinguishable from magic is insufficiently advanced -Gehm's corollary Any technologist that is distinguishable from a magician is insufficiently advanced - My corollary The worlds worst webcomic: http://silentcoder.co.za/scartoonz The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za begin:vcard fn:AJ Venter n:Venter;AJ org:Global Pact Trading Pty. Ltd.;OutKast Solutions email;internet:[EMAIL PROTECTED] title:Director of Product Development tel;work:+27 21 554 5059 tel;fax:+27 11 252 9197 tel;cell:+27 83 455 9978 url:http://www.outkastsolutions.co.za version:2.1 end:vcard
Re: [lazarus] Introduction
On Tue, 29 Jan 2008, Martin Schreiber wrote: On Tuesday 29 January 2008 04.13:31 Alexsander Rosa wrote: The OPF is ported to Lazarus (with IFDEF's). We removed most of the 3rd-party components, the only remaining are Colrcal (TMonthCalendar does not work under Wine), AlignEdit (a simple TEdit with Alignment property) and Rave Reports. We still plan to migrate to a binary-native solution and Lazarus is a top candidate -- however, the current LCL approach of using multiple widget sets may bring us back the same visual differences. MSEide+MSEgui is designed with the goal to provide identical look and feel on Linux and win32: http://sourceforge.net/projects/mseide-msegui/ Another main focus of MSEide+MSEgui are database components. ... but it is i386 only. No 64-bit, meaning it is unusable for me, since I work on 64-bit only... All projects have their advantages and disadvantages... Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
On 29/01/2008, A.J. Venter [EMAIL PROTECTED] wrote: Well I wasn't actually saying it would be the answer for you right now - but I wanted to fix the misconception - it is possible to use a custom theme for just your program, ship it with it etc. I understand that you can ship a custom theme (rc file or whatever) for GTK with your application. Somebody else told me that before. But I needed more flexibility by changing the appearance of a _single_ component on-demand (eg: TEdit's background to clError [yellow] when there was a validation issue). All this is water under the bridge for me now - we are already 2.5 years into development. Why to late to change GUI toolkits again. It would be nice if what you said was documented on the Lazarus wiki though (if it's not already there). It might be handy for other users. One thing keeps coming up in usability studies - every app on the user's desktop should behave the same to the largest possible extent. So the user does not need to learn how to navigate 20 types of file open fpGUI's designs like the File Open dialog are based on Windows look, so any user should be able to use it. The Font dialog (not used much in general apps) have a slightly different look, but that's because it has some unique features. Still very simple to use. Oh, fpGUI's Buttons work similar to Windows to point and click. ;-) But, FPgui is well on it's way to fully supporting your use-case - and once it's LCL linked, lazarus will be able to meet either use-case. That is what I am hoping for and why I'll justify spending time working on the LCL-fpGUI integration. Can you mail me offlist with some of the priority missing pieces ? Then if I have time, I can send you back some patches to help it along. Thanks AJ, I'll send you a mail... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tuesday 29 January 2008 04.13:31 Alexsander Rosa wrote: The OPF is ported to Lazarus (with IFDEF's). We removed most of the 3rd-party components, the only remaining are Colrcal (TMonthCalendar does not work under Wine), AlignEdit (a simple TEdit with Alignment property) and Rave Reports. We still plan to migrate to a binary-native solution and Lazarus is a top candidate -- however, the current LCL approach of using multiple widget sets may bring us back the same visual differences. MSEide+MSEgui is designed with the goal to provide identical look and feel on Linux and win32: http://sourceforge.net/projects/mseide-msegui/ Another main focus of MSEide+MSEgui are database components. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
MSEide+MSEgui is designed with the goal to provide identical look and feel on Linux and win32: http://sourceforge.net/projects/mseide-msegui/ Another main focus of MSEide+MSEgui are database components. Does it support lazarus components however ? I wouldn't even THINK of using it if I couldn't use the custom components I developed for lazarus - the ones included in lazarus now as well as the ones I just use myself. A.J. -- Any sufficiently advanced technology is indistinguishable from magic - Clarke's law Any technology that is distinguishable from magic is insufficiently advanced -Gehm's corollary Any technologist that is distinguishable from a magician is insufficiently advanced - My corollary The worlds worst webcomic: http://silentcoder.co.za/scartoonz The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za begin:vcard fn:AJ Venter n:Venter;AJ org:Global Pact Trading Pty. Ltd.;OutKast Solutions email;internet:[EMAIL PROTECTED] title:Director of Product Development tel;work:+27 21 554 5059 tel;fax:+27 11 252 9197 tel;cell:+27 83 455 9978 url:http://www.outkastsolutions.co.za version:2.1 end:vcard
Re: [lazarus] Introduction
On Tuesday 29 January 2008 10.59:57 Michael Van Canneyt wrote: ... but it is i386 only. No 64-bit, meaning it is unusable for me, since I work on 64-bit only... All projects have their advantages and disadvantages... I have no need for 64 bit so I didn't port it to 64 bit up to now. What did you gain from switch to 64 bit? Can't you run 32 bit applications on your Systems? Martin _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 29 Jan 2008, Martin Schreiber wrote: On Tuesday 29 January 2008 10.59:57 Michael Van Canneyt wrote: ... but it is i386 only. No 64-bit, meaning it is unusable for me, since I work on 64-bit only... All projects have their advantages and disadvantages... I have no need for 64 bit so I didn't port it to 64 bit up to now. What did you gain from switch to 64 bit? Memory space 2GB. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys wrote: On 29/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Aha ! So, in the end, the problem solves itself, if they are all on linux ;-) It's a slow process though! :-) +-250 franchisees with avg 25+ computers and +-230 schools with a avg 30+ computers. That's around 13150 computers. We can't force everybody to switch to Linux because in places like schools, the computers get used for other things as well. And you get the huge factor which slows things down - people are scared of something they are unfamiliar with. So we introduce new equipment with Linux so they can get a feel for things and see that it isn't that different (from a GUI point of view). This is where the side-by-side OS's come in play. Regards, - Graeme - Well I am running Kubuntu but also virtualbox , in which I can run windows XP. Maybe that is a solution regards Wim _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys wrote: For obvious reasons (no LCL-fpGUI yet) we opted for the last option. We still use Lazarus as our IDE and we (fpGUI) do have our own visual form designer. Graeme, Will fpGUI/LCL still support theming later when theming is implemented? For me, using the native widget set is OK 95% of the time, but sometimes you need to put a theme on it. But sometimes its necessary to create applications that are very different from traditional widget sets as you have found. The be-all-end-all of widget sets IMO, would be one that supports native look and behavior as well as custom themes when required. My company has a pos application for restaurants that consists primarily of 2 separate applications. The back office, looks and works like most traditional desktop applications. The POS portion however, is like night and day. Not just because navigation is primarily through touch screen taps, but in terms of the UI itself which I think any programmer would be hard pressed to guess which language it was written in just by looking at the application itself. http://www.datatrakpos.com/pos/screenshots.aspx Many hours of photoshop and writing TImage descendents to get that look. I've tried (and purchased 2 of) 3 theming engines for Delphi I've found and not one could offer the speed and flicker free rendering we achieved from using simple TImage descendents. This was especially important in a POS app where the UI really has to snap and keep up with the users who eventually operate the POS blindfolded. I'm curious to see how fpGUI theming shapes up in terms of this kind of theme rendering and speed. -- Warm Regards, Lee Everything I needed to learn in life, I learned selling encyclopedias door to door. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 29/01/2008, Lee Jenkins [EMAIL PROTECTED] wrote: Will fpGUI/LCL still support theming later when theming is implemented? To be honest, I'm not sure how it's going to work. I still need to do a lot of work on theming support in fpGUI and I don't know what the other LCL widgetsets do in such a case? I would guess fpGUI would loose some of it's features when used as LCL-fpGUI widgetset - or maybe I just don't understand the LCL backend fully. Could others comment here? The POS portion however, is like night and day. Not just because navigation is primarily through touch screen taps, but in terms of the UI itself which I think any programmer would be hard pressed to guess which language it was written in We also have an application in our suite of software that has a very unique interface because it always runs fullscreen (kiosk mode). We haven't ported that to fpGUI yet, because it uses Flash OCX for the main part of the screen. I still need to complete the Mozilla Plugin Panel component [*1] before we can port that app, but it will be done. [*1]: http://opensoft.homeip.net/wiki/wiki.cgi?p=mozilla-plugin-panel TImage descendents. This was especially important in a POS app where the UI really has to snap and keep up with the users who eventually operate the POS blindfolded. fpGUI uses double buffering for all painting (GDI and X11). It's pretty good, but I am sure it can be tweaked for even better performance. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
Open Office will have all sorts of users, many of them are individuals with different tastes. They have favorite OS, theme, etc. Some of them are old, some have disabilities. It's a vastly heterogeneous population with very different needs. Each user has his own Desktop Environment and the software needs to appear right in each and every computer. The look and feel may influence the buying decision. On the other hand, SAP R/3 is an ERP used by companies. The company does not want to waste time and money training people for different widget sets. They want a single, consistent look across the entire company, it's an homogeneous userbase. Even if there are many OSes, the ERP must look exactly the same everywhere. The company may even need an odd widget like this one (from FLTK): http://www.fltk.org/documentation.php/doc-1.1/Fl_Dial.html That's my point. Different types of users, different needs. A software with a diverse userbase, like Open Office, needs to comply to every standard possible -- even if this costs a few features. A software with a specific user base, specially an enterprise core application, needs to implement every feature the user wants, even if this costs a few standards. 2008/1/29, Marco van de Voort [EMAIL PROTECTED]: On Tue, Jan 29, 2008 at 09:50:11AM -0300, Alexsander Rosa wrote: OpenOffice needs to blend in the user's interface. SAP R/3 does not. Why not? They might get a way with it, but is it a hard requirement that SAP does not blend in? Different users, different needs. _IS_ it a need? Or something convenient for the programmers they cna get away with ? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Atenciosamente, Alexsander da Rosa Linux User #113925
Re: [lazarus] Introduction - NOTE FOR GRAHAM
On Tue, Jan 29, 2008 at 02:35:56PM +0200, Graeme Geldenhuys wrote: It's more than look and basic behaviour: - keyboard handling - disability support - internationalisation support - behaviour when scaling - following future extensions a bit. (See e.g. the site how to update Delphi apps to vista look. A overrides pertaining font changes here and there, a property there, and done. Try that with a widget set that paints itself) I'm not trying to recreate every possible OS to the tee, but I am trying to implement enough so users will feel comfortable and not alienated. Take Pixel (the image editor) as an example - It looks like Windows XP default theme, but at closer inspection it's not (file dialogs are very different, no keyboard focus support, no mouse over/down states on buttons and scrollbars etc..) but it seems to be enough to fool the average user and make them feel okay with the application. For me it is simple. Despite that I'm multiplatform oriented, I can't wipeout that Windows is still dominant. Anything substandard on Windows is thus IMHO a dead horse except in certain niches. When trying to improve the behaviour when totally gets into the swamp of details, differences of approach, customizability etc. And with dead horse I mean the technique (the widget set), not necessarily the application (like Pixel), since that can have additional features going for it that make up for it. So unless I have a very strong reason I'll go for the native set. I'm trying the same with fpGUI - getting them to feel comfortable, even though some things might be a bit different. fpGUI's goal is consistency across platforms with the addition that anything can be customized if the developer needs it. And whatever I missed and somebody else needs - hopefully it will be fairly straight forward to implement. That is indeed a different vision. So you are more targeting the same user working on multiple platforms, then delivering an app to multiple users on different platforms. As for bleeding edge looks like Vista - 99% of ours clients use Win98 and WinXP (and yes I know I shouldn't generalize only on our experience). Only now (the beginning of this year) we finally stopped supporting Win95! People don't upgrade nearly as quick as Microsoft wishes! There is a lot of old hardware still being used with Win98. Yes I know. I've been in the same position. But those machines were dedicated to that hardware, and no new stuff was bought for that market. So we gave up on pre 2000. (in my last job) In my current job, we deliver a complete or partial machine that happens to contain a PC installed with XP. So the situation here is totally different (and licensing costs are negiable compared to even one bit of the non PC hardware) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
OpenOffice needs to blend in the user's interface. SAP R/3 does not. Different users, different needs. 2008/1/29, Marco van de Voort [EMAIL PROTECTED]: On Tue, Jan 29, 2008 at 12:04:11PM +0200, Graeme Geldenhuys wrote: It would be nice if what you said was documented on the Lazarus wiki though (if it's not already there). It might be handy for other users. Agree. It was a nice post. One thing keeps coming up in usability studies - every app on the user's desktop should behave the same to the largest possible extent. So the user does not need to learn how to navigate 20 types of file open fpGUI's designs like the File Open dialog are based on Windows look, so any user should be able to use it. The Font dialog (not used much in general apps) have a slightly different look, but that's because it has some unique features. Still very simple to use. Oh, fpGUI's Buttons work similar to Windows to point and click. ;-) It's more than look and basic behaviour: - keyboard handling - disability support - internationalisation support - behaviour when scaling - following future extensions a bit. (See e.g. the site how to update Delphi apps to vista look. A overrides pertaining font changes here and there, a property there, and done. Try that with a widget set that paints itself) etc etc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Atenciosamente, Alexsander da Rosa Linux User #113925
Re: [lazarus] Introduction - NOTE FOR GRAHAM
On Tue, Jan 29, 2008 at 12:04:11PM +0200, Graeme Geldenhuys wrote: It would be nice if what you said was documented on the Lazarus wiki though (if it's not already there). It might be handy for other users. Agree. It was a nice post. One thing keeps coming up in usability studies - every app on the user's desktop should behave the same to the largest possible extent. So the user does not need to learn how to navigate 20 types of file open fpGUI's designs like the File Open dialog are based on Windows look, so any user should be able to use it. The Font dialog (not used much in general apps) have a slightly different look, but that's because it has some unique features. Still very simple to use. Oh, fpGUI's Buttons work similar to Windows to point and click. ;-) It's more than look and basic behaviour: - keyboard handling - disability support - internationalisation support - behaviour when scaling - following future extensions a bit. (See e.g. the site how to update Delphi apps to vista look. A overrides pertaining font changes here and there, a property there, and done. Try that with a widget set that paints itself) etc etc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
On 29/01/2008, Marco van de Voort [EMAIL PROTECTED] wrote: It's more than look and basic behaviour: - keyboard handling - disability support - internationalisation support - behaviour when scaling - following future extensions a bit. (See e.g. the site how to update Delphi apps to vista look. A overrides pertaining font changes here and there, a property there, and done. Try that with a widget set that paints itself) I'm not trying to recreate every possible OS to the tee, but I am trying to implement enough so users will feel comfortable and not alienated. Take Pixel (the image editor) as an example - It looks like Windows XP default theme, but at closer inspection it's not (file dialogs are very different, no keyboard focus support, no mouse over/down states on buttons and scrollbars etc..) but it seems to be enough to fool the average user and make them feel okay with the application. I'm trying the same with fpGUI - getting them to feel comfortable, even though some things might be a bit different. fpGUI's goal is consistency across platforms with the addition that anything can be customized if the developer needs it. And whatever I missed and somebody else needs - hopefully it will be fairly straight forward to implement. As for bleeding edge looks like Vista - 99% of ours clients use Win98 and WinXP (and yes I know I shouldn't generalize only on our experience). Only now (the beginning of this year) we finally stopped supporting Win95! People don't upgrade nearly as quick as Microsoft wishes! There is a lot of old hardware still being used with Win98. Also, I am working on fpGUI's theme engine and theme designer, but it's not priority yet. In the end graphics artists will be able to create themes with easy, freeing up the developers to do what they do best - code! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
Graeme Geldenhuys rašė: On 29/01/2008, A.J. Venter [EMAIL PROTECTED] wrote: Well I wasn't actually saying it would be the answer for you right now - but I wanted to fix the misconception - it is possible to use a custom theme for just your program, ship it with it etc. I understand that you can ship a custom theme (rc file or whatever) for GTK with your application. Somebody else told me that before. But I needed more flexibility by changing the appearance of a _single_ component on-demand (eg: TEdit's background to clError [yellow] when there was a validation issue). All this is water under the bridge for me now - we are already 2.5 years into development. Why to late to change GUI toolkits again. I implemented this in another way: when i need to show where user entered invalid data (f.e. TEdit) i simply draw animated frame around that control (for this i writted component error shower: at startup they collect all TControl's with error showing feature, and at runtime i tell for him where need error to show). P.S. sorry for bad English. -- Valdas Jankūnas _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction - NOTE FOR GRAHAM
On Tue, Jan 29, 2008 at 09:50:11AM -0300, Alexsander Rosa wrote: OpenOffice needs to blend in the user's interface. SAP R/3 does not. Why not? They might get a way with it, but is it a hard requirement that SAP does not blend in? Different users, different needs. _IS_ it a need? Or something convenient for the programmers they cna get away with ? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys ha scritto: On 29/01/2008, Lee Jenkins [EMAIL PROTECTED] wrote: Will fpGUI/LCL still support theming later when theming is implemented? To be honest, I'm not sure how it's going to work. I still need to do a lot of work on theming support in fpGUI and I don't know what the other LCL widgetsets do in such a case? I would guess fpGUI would loose some of it's features when used as LCL-fpGUI widgetset - or maybe I just don't understand the LCL backend fully. Could others comment here? I wouldn't be much in favor of an LCL-fpGUI widgetset, considered the amount of work it requires. LCL is aimed to provide native support for ready made widgeset, which were not originally intended to be handled that way. This, besides being a core developers decision, fulfills a requirement for a number of applications, but also creates a number of constraints. It also makes dealing with LCL backend much more difficult than strictly necessary, because LCL interfaces with different high level functions each one conceived it's way, and is forced to includes workarounds for different philosophies of widgeset designers, widgetset whims, and widgeset bugs. If the aim isn't that of supporting existing widgesets, but to have a Lazarus native widgetset, I'd see more efficient, both in terms of development time, and in terms of final result, to think of fpGUI as an *alternative* to LCL. IOW: a) You want/need GTK, WIN, Qt, Carbon, etc. widgetsets providing platform dependent native look'n feel? Then use LCL. b) You want/need native fpc widgetset providing identical look and behavior on different platforms? Then use fpGUI, fpCL, or whatever you want to call it, *in place of LCL*. It would be a higher level choice: LCL or fpGUI. Then next choice: in case of LCL the widgeset choice, in case of fpGUI the graphic interface choice (nobody forbids to use e.g. X in Windows or Mac environment. A bit harder to use GDI in Linux environment ;-) ) I've started my own experiment to verify if this road is viable, by attempting a port of Delphi clx to Lazarus. I.e replacing LCL with something else. The first results are quite promising. Just some compatibility problems between Delphi and fpc implementation, which demand many days to be located, and a couple of hours to be fixed. In my test case I'm using something which is very roughly LCL compatible, while the native approach could not only be much more LCL compatible, but also profit of a great amount of LCL code, without being hampered by the constraints LCL developers must live with. This would also make the fpGUI development line more integrated with Lazarus development line, so that each branch could profit from whatever comes from the other branch. Just my 2 cents. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
My 2 cents: Our company develops a 400+ KLOC software, and ERP-like package. We have customers running it under Windows and Linux, sometimes both in the same environment side-by-side. We used Kylix at first, but some of our customers with mixed environments complained about the visual differences. They demanded a standard, consistent look and feel, regardless of the OS. A few of them are using the Windows version under Wine. Back in 2005 we started to port from CLX to VCL in order to port to Lazarus. We wrote a blog on this effort: http://port2laz.blogspot.com/2005_12_01_archive.html The OPF is ported to Lazarus (with IFDEF's). We removed most of the 3rd-party components, the only remaining are Colrcal (TMonthCalendar does not work under Wine), AlignEdit (a simple TEdit with Alignment property) and Rave Reports. We still plan to migrate to a binary-native solution and Lazarus is a top candidate -- however, the current LCL approach of using multiple widget sets may bring us back the same visual differences. 2008/1/22, Michael Van Canneyt [EMAIL PROTECTED]: On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). Well, I develop major database projects (in Delphi), and none of our customers has ever asked for a specific look. So I would be the last to ask this from lazarus. The thing I am looking for is portability. Most of our users hardly understand windows, let alone that they would require a specific (and hence more confusing) look for our application. By keeping it close to the windows standards, we make the application less frightful for them. And we have many thousands of such users. As in all things, it is dangerous to generalize your own experience. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Atenciosamente, Alexsander da Rosa Linux User #113925
Re: [lazarus] Introduction
En/na Giuliano Colla ha escrit: I can't say. I read that someone is *using* gtk2. I tried to make a form with a button, and the lower half of the caption was lost. I tried to put a panel with a memo on the form, and I could see the panel through the memo (or the opposite, I don't remember). From time to time I recover my test form, retry it and the situation hasn't changed. I would never think that it's usable. But someone claims to use it. What for is a mystery for me. I've just done a project with gtk2 (disclaimer: it's not in production yet). It manages a simple sqlite database (using zeos, a handful of forms with TDBgrid and TDBNavigator) and communicates with the control process (which is a console mode daemon, so no gtk*) via dbus (it was fun using dbus with fpc, well, if you are a masochist :-D ) It seems to be working well. The biggest problem is the gtk2 memory leak, however these programs aren't meant to work 24/7 (only the control process is working 24/7) so I don't worry too much. When the graphical part has to run 24/7 I have no other option than use gtk1 (due to the above mentioned memory leak). Oh, the ide is compiled with gtk2. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 23/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: If the bug is annoying you, then *you* should do something about it =) If all users use the approach: Oh, I'll test now and wait 3 months and test again, then they are all risking that in 3 months there won't be any change to what they wanted changed. If you don't plan on doing anything about it, then I say it's not that annoying for you, because it's not annoying enougth to make you do something about it =) I'm in the same boat. I have a lot of (paying) work and other open source projects I contribute to. Learning the internals of GTK2 and as always getting lost in the LCL widgetset backend, it's like looking for a needle in a very big haystack. Even for the simplest bugs. At which point I give up on GTK2 and move back to GTK1 where things normally work better (for me). Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Felipe Monteiro de Carvalho ha scritto: On Jan 23, 2008 2:08 AM, Giuliano Colla [EMAIL PROTECTED] wrote: The test isn't by me, but by someone who complained about z-order in gtk2 not being correct. A lot of time ago. I know, it's voluntary work, everybody does its best. We take what's available, and thank. But please don't tell me that gtk2 can be taken in consideration for anything else than a specific project carried on by a Lazarus developer, who knows enough the internals to fix the widgets he needs. And what do you plan to do about it? Try and convince Lazarus developers to follow a route which makes it possible for a lot of people like me to actively contribute instead of just feeling helpless and whine. What I mean is very simple: I have to get to work at 7:30 and come back at 21:00. Why would I use my spare time to hunt for the endless, arbitrary bugs in the gtk2 interface? And my experience with the gtk/gtk2 interface is enougth to say it ain't particularly fun to work endless hours to fix small bugs on that spaguetti code, which often ends up without any fix. That's the point. Attempting to fix z-order in GTK2, which is a minimum requirement in order to make a real world application work, requires to study gtk2 in detail. Moreover you may be forced to modify something in LCL, which will doubtless break gtk1, Qt, Carbon, windows, WINCE etc. (I see it happen every day) So you must study gtk1 in detail (loss of time because gtk1 is long dead), Qt, Carbon (I don't have a Mac), windows API's etc. It's above me. And apparently above Lazarus team. That's why I claim that the native widget route is a dead end. If the bug is annoying you, then *you* should do something about it =) If all users use the approach: Oh, I'll test now and wait 3 months and test again, then they are all risking that in 3 months there won't be any change to what they wanted changed. See above. If something is within my reach, I attempt to fix it. If it's above my reach I can only whine. If you don't plan on doing anything about it, then I say it's not that annoying for you, because it's not annoying enougth to make you do something about it =) What *I* plan to do is to take alternative, more viable routes, but it's a pity. I just hopr that my alternatives can somehow fit into Lazarus, so that I can contribute them. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme, BTW, I can't access to http://opensoft.homeip.net/fpgui/ can you check this out? Thanks in advance, Leonardo M. Ramé http://leonardorame.blogspot.com _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: Felipe Monteiro de Carvalho ha scritto: On Jan 23, 2008 2:08 AM, Giuliano Colla [EMAIL PROTECTED] wrote: The test isn't by me, but by someone who complained about z-order in gtk2 not being correct. A lot of time ago. I know, it's voluntary work, everybody does its best. We take what's available, and thank. But please don't tell me that gtk2 can be taken in consideration for anything else than a specific project carried on by a Lazarus developer, who knows enough the internals to fix the widgets he needs. And what do you plan to do about it? Try and convince Lazarus developers to follow a route which makes it possible for a lot of people like me to actively contribute instead of just feeling helpless and whine. What route do you suggest ? What I mean is very simple: I have to get to work at 7:30 and come back at 21:00. Why would I use my spare time to hunt for the endless, arbitrary bugs in the gtk2 interface? And my experience with the gtk/gtk2 interface is enougth to say it ain't particularly fun to work endless hours to fix small bugs on that spaguetti code, which often ends up without any fix. That's the point. Attempting to fix z-order in GTK2, which is a minimum requirement in order to make a real world application work, requires to study gtk2 in detail. Whatever model you come up with, be it native contols or customdrawn controls, as soon as there is a bug on OS/widget level, you need to understand that level. Moreover you may be forced to modify something in LCL, which will doubtless break gtk1, Qt, Carbon, windows, WINCE etc. (I see it happen every day) So you must study gtk1 in detail (loss of time because gtk1 is long dead), Qt, Carbon (I don't have a Mac), windows API's etc. It's above me. And apparently above Lazarus team. Now you're taking the extreme route, this doesn't happen that often. However if there is a bug in the LCL it needs to be fixed. It's to noones advantage that every widgetset has to work around tose bugs. Still we are happy to receive patches aginst gtk2+lcl in this case. It may only take longer before things are applied since more ppl are involved to fix other widgetsets. That's why I claim that the native widget route is a dead end. That's your claim, not ours. If the bug is annoying you, then *you* should do something about it =) If all users use the approach: Oh, I'll test now and wait 3 months and test again, then they are all risking that in 3 months there won't be any change to what they wanted changed. See above. If something is within my reach, I attempt to fix it. If it's above my reach I can only whine. You can also help with small testcases and such exactly pinpointing the problem. Whining won't help anyone, only you loose. (I will certainly not inspire me to help you) If you don't plan on doing anything about it, then I say it's not that annoying for you, because it's not annoying enougth to make you do something about it =) What *I* plan to do is to take alternative, more viable routes, but it's a pity. I just hopr that my alternatives can somehow fit into Lazarus, so that I can contribute them. Thank you. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Marc Weustink ha scritto: Giuliano Colla wrote: Felipe Monteiro de Carvalho ha scritto: Try and convince Lazarus developers to follow a route which makes it possible for a lot of people like me to actively contribute instead of just feeling helpless and whine. What route do you suggest ? I understand that using a ready made widgetset is a good way to start a project which otherwise would appear a titanic task. But once the project has started consolidating, as it has, I believe it should be wise to reconsider the initial choices. I see that work is being done to remove functions from LCL and move them to widgesets. The route I suggest is the opposite: the maximum of functionalities should be in LCL, and widgetset should provide the bare minimum. The advantages are: One code base to maintain instead of many. A cleaner code organization. Widgetset just paints, LCL does the work. Cleaner code, free of bug prone callbacks from widgetset. Code more readable, encouraging contribution from Pascal-addict users not deep enough in each widgetset C++ intricacies, whims and bugs. Consistent behavior in different platforms. A code base ready for Lazarus native widgets, getting rid of GTK, QT, etc. heavy and buggy libraries. It appears that this is not the way core developers want to go, but I can always suggest it. Then it's up to them to drop the matter or give it a second thought. That's the point. Attempting to fix z-order in GTK2, which is a minimum requirement in order to make a real world application work, requires to study gtk2 in detail. Whatever model you come up with, be it native contols or customdrawn controls, as soon as there is a bug on OS/widget level, you need to understand that level. You're right, but the more intricate is the pattern, the more difficult is the approach. I've fixed a number of Kylix bugs in a fraction of the time it just took me just to locate in Lazarus the gkt functions involved in a bug. Moreover you may be forced to modify something in LCL, which will doubtless break gtk1, Qt, Carbon, windows, WINCE etc. (I see it happen every day) So you must study gtk1 in detail (loss of time because gtk1 is long dead), Qt, Carbon (I don't have a Mac), windows API's etc. It's above me. And apparently above Lazarus team. Now you're taking the extreme route, this doesn't happen that often. However if there is a bug in the LCL it needs to be fixed. It's to noones advantage that every widgetset has to work around tose bugs. The problem isn't a bug in LCL. The problem is a bug (or just a poorly implemented feature) in the widgetset which can't be solved at widgetset level, and therefore requires an LCL workaround, which in turn breaks other things. I've seen that happen quite often. Still we are happy to receive patches aginst gtk2+lcl in this case. It may only take longer before things are applied since more ppl are involved to fix other widgetsets. I perfectly understand that GTK2 is a low priority, and I can see from svn logs that nobody is actively working on it. I raised the question only because Felipe appeared to believe that gtk2 is usable, which in my opinion isn't. I can live without gtk2 so I just check it from time to time. That's why I claim that the native widget route is a dead end. That's your claim, not ours. I know, and I tried to support my claim with arguments. Whenever a feature is moved from LCL to widgetset, all widgetset related portions must be updated, and this multiplies the problems given the limited resources available. See above. If something is within my reach, I attempt to fix it. If it's above my reach I can only whine. You can also help with small testcases and such exactly pinpointing the problem. Whining won't help anyone, only you loose. (I will certainly not inspire me to help you) Most of the times, when I point a problem is just to help Lazarus to be a better product. If it's something I really need, I try to locate the cause and either fix it myself, or give the developers all useful information to fix it with minimum loss of time. Back about GTK2, I don't need it, I don't need help on it, but I feel it right to let you know the impression one gets when trying to use it. And it seems to me that it's one more argument in favor of my point of view. However, that's just my point of view. Lazarus team has made an excellent work with an amazing IDE, and therefore deserves all my respect, whatever they decide to do, and I'll continue to contribute, within the limits of my time and my skills. Thanks Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 23, 2008 7:45 PM, Giuliano Colla [EMAIL PROTECTED] wrote: I understand that using a ready made widgetset is a good way to start a project which otherwise would appear a titanic task. But once the project has started consolidating, as it has, I believe it should be wise to reconsider the initial choices. I think that the LCL model is flexible enougth: Those that think we shouldn't use native widgets can work on a fpgui or a msegui interface for lazarus. You're right, but the more intricate is the pattern, the more difficult is the approach. I've fixed a number of Kylix bugs in a fraction of the time it just took me just to locate in Lazarus the gkt functions involved in a bug. I don't think this can be generalized to LCL as a whole. If you try to develop the Qt or Win32 interface you'll see it's much easier. I already said my oppinion on gtk and the gtk interface many times, so I won't repeat myself. regards, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Michael Van Canneyt ha scritto: On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. It provides properties and methods which are in most cases self-explanatory. The Color Property of a Form or of a Button dictates its color. Well, try just to set this property to clRed, or clButtonFace with different widgesets, and compare the behavior. This is a question of priority. Some widgetset developers and some lazarus developers think that changing the 'color' is seldom a good solution and so they don't invest time on this. So it is up to those who think, that this property is useful to implement and maintain it. If the implementation breaks other features then the developers have to decide what is more important. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Or they could achieve native look just by using a Bitmap, and consistent behavior with code in LCL, with less duplicated work, less bugs, and better results. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. When you're told that the feature can't be implemented because the widgetset doesn't support it, you stop reporting. When you see that the development line is to move the implementation from LCL to widgetset, instead of the opposite, (and breaking what was already working in the process), you stop providing patches, and start whining. :-( Breaking is bad, but sometimes inevitable. For example Drag and Drop was improved in the LCL/gtk, but without a proper threshold, so treeviews become unusable on some machines. I will not complain, because the general direction is right and if no one fixes it I will fix it myself. Even though I already fixed it in the past. About: move from LCL to widgetset That was the goal of lazarus from the beginning. If you want a visual component library with a minimal backend, then use fpGUI or msegui. Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). So basically every drawing should be avoided in the LCL or at least use only high level drawing functions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Op dinsdag 22-01-2008 om 15:03 uur [tijdzone +0200], schreef Graeme Geldenhuys: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? Hindsight is a awesome thing. :-) For me: if Lazarus woudn't use native widgets, I woudn't use it. It's one of the most important features for me. Else I could also use Java, for example. for me the main issue with Java is that it doesn't 'feel' native for most users. Joost _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Damien Gerard ha scritto: On Jan 21, 2008, at 10:03 PM, Graeme Geldenhuys wrote: On 21/01/2008, Den Jean [EMAIL PROTECTED] wrote: On Monday 21 January 2008 01:18:56 pm Giuliano Colla wrote: Either one takes the Qt way, i.e. using style to *mimic* the native *look*, without actually using it, and provides a consistent behavior, this does not honour the huge Qt effort. Qt DOES use the native widget when necessary do have native look for XP, Vista and Mac OS X style. This is why these styles are not available on the other platforms because the lack of the native widget set library. Nope, it's like I explained before. Qt does all custom painting, it does not required the underlying 'native' widgets. They used to copy the look of OS's by manually drawing all controls. Since late 3.x or starting with 4.x (not sure which version) Qt under XP, Vista, MacOS X and GTK asks the corresponding component (via native API) to draw itself on a memory bitmap. Qt then paints that bitmap to the correct location on the form. This overcomes the issue when user install there own custom themes. Qt does not create a instance of the native widget. For others I don't know but for Carbon I have a big doubt. It's virtually impossible to support styles (which can be changed at run-time, don't forget) and actually use native widgetsets. This would mean dynamically readjust all dependencies, taking into account the different implementation whims. They would be fools, and they aren't. From Qt4 sources (Qtstyle.cpp): /quote Qt contains a set of QStyle subclasses that emulate the styles of the different platforms supported by Qt (QWindowsStyle, QMacStyle, QMotifStyle, etc.). By default, these styles are built into the QtGui library. Styles can also be made available as plugins. Qt's built-in widgets use QStyle to perform nearly all of their drawing, ensuring that they look exactly like the equivalent native widgets. The diagram below shows a QComboBox in eight different styles. quote/ Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? Hindsight is a awesome thing. :-) Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. As I mentioned before. This is very easy to achieve - Trolltech has proved this. Simply ask the native widget to draw itself on a memory bitmap. All native toolkits send out a message when the theme changes, so it's very easy to detect that as well. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). All this can be implemented in a custom drawn toolkit. At least that way all platforms will have these features. Currently only GTK Notebook has tab menu for example. LCL now needs to support a basic set of features which are common to all widget sets - nothing more otherwise it's not compatible across widget sets. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? I would optimize it for smart linking and a console widgetset. Hindsight is a awesome thing. :-) Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. As I mentioned before. This is very easy to achieve - Trolltech has proved this. Simply ask the native widget to draw itself on a memory bitmap. All native toolkits send out a message when the theme changes, so it's very easy to detect that as well. Why should qt render a native button, if they can draw a qt button with a 'native' looking theme? Are you sure, that qt uses native widgets? - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). All this can be implemented in a custom drawn toolkit. Yes, by reinventing the wheel. At least that way all platforms will have these features. Currently only GTK Notebook has tab menu for example. A Mac user will be confused if she sees this menu. A disabled person wants to use his OS features and not setup this for each program. LCL now needs to support a basic set of features which are common to all widget sets - nothing more otherwise it's not compatible across widget sets. Only the API is limited to the common features. The program is not limited. As said above: You get extra features of the widgetset. And if a programmer needs uncommon things, he can write a specific control. See for example the printers4lazarus or the lazopenglcontext package. They started on one platform and nowadays they run on all majors. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Everything has its ups and downs. But the nice thing about Lazarus is that it can use for instance FPGUI, which will work on all platforms, hence rendering the whole discussion moot. I was waiting for another 50 or so replies before mentioning that ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Mattias Gärtner ha scritto: Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Michael Van Canneyt ha scritto: On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. It provides properties and methods which are in most cases self-explanatory. The Color Property of a Form or of a Button dictates its color. Well, try just to set this property to clRed, or clButtonFace with different widgesets, and compare the behavior. This is a question of priority. Some widgetset developers and some lazarus developers think that changing the 'color' is seldom a good solution and so they don't invest time on this. So it is up to those who think, that this property is useful to implement and maintain it. If the implementation breaks other features then the developers have to decide what is more important. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Or they could achieve native look just by using a Bitmap, and consistent behavior with code in LCL, with less duplicated work, less bugs, and better results. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. When you're told that the feature can't be implemented because the widgetset doesn't support it, you stop reporting. When you see that the development line is to move the implementation from LCL to widgetset, instead of the opposite, (and breaking what was already working in the process), you stop providing patches, and start whining. :-( Breaking is bad, but sometimes inevitable. For example Drag and Drop was improved in the LCL/gtk, but without a proper threshold, so treeviews become unusable on some machines. I will not complain, because the general direction is right and if no one fixes it I will fix it myself. Even though I already fixed it in the past. About: move from LCL to widgetset That was the goal of lazarus from the beginning. If you want a visual component library with a minimal backend, then use fpGUI or msegui. Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). So basically every drawing should be avoided in the LCL or at least use only high level drawing functions. Well, I can't claim that I only hold the truth, and everybody else is wrong. But I can claim to represent a part of the outside world, those who are USING Delphi,Lazarus, etc. to develop applications, and who make a living out of it. I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) I presume i didn't do it so badly, because I never missed a meal, and the only customers I've ever lost are those who died of old age (sadly too many, now that I think of it). I could happily retire now, weren't that I still have fun doing what I'm doing. Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Recently I've visited a customer which has still an old text-style implementation (sort of custom ncurses) and when I proposed a GUI interface, he reacted: Provided it's not Windows-like. We have already had this bad experience. We want something user oriented, not Windows oriented!. Then I showed him some samples and he
Re: [lazarus] Introduction
On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: Why should qt render a native button, if they can draw a qt button with a 'native' looking theme? Are you sure, that qt uses native widgets? Qt has built-in themes (custom coded) and also allows for hooking into the native widgets theme manager. Take Windows XP for example: By simply hooking into the UxTheme API, your custom toolkit can look like any Windows XP theme. Trolltech does similar. All this can be implemented in a custom drawn toolkit. Yes, by reinventing the wheel. Yeah but it would be a 'super' wheel that fits and works on all cars! :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Lord Satan [EMAIL PROTECTED] wrote: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. Have a look on SourceForge. I have seen quite a few toolkits implemented in C/C++ and uses OpenGL or SDL or whatever hw acceleration they picked. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). I only develop commercial applications with Lazarus and from judging by all these conversations, it seems like we are the only two. Also we seem to experience the same issues - coincidence? What does everyone else use Lazarus for? Console apps maybe? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 16:20:57 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 22/01/2008, Lord Satan [EMAIL PROTECTED] wrote: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. Have a look on SourceForge. I have seen quite a few toolkits implemented in C/C++ and uses OpenGL or SDL or whatever hw acceleration they picked. SDL is no acceleration, only if you use its OpenGL wrapper functionality you get hw acceleration. I know a lot of those 'widgetsets', too, but they are meant for OpenGL apps and they are not general purpose widgetsets like WIN API, GTK, QT, etc. Most of them are very basic tools to provide GUIs for 3D apps. So I would really like to know of at least one specific one. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 15:28:15 +0100 Mattias Gärtner [EMAIL PROTECTED] wrote: Zitat von Lord Satan [EMAIL PROTECTED]: @Mattias: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. For example: -gtk on embedded devices can render directly to the framebuffer. -trolltech advertises hardware accelerations on their website, but I don't know if this available for free. -afaik carbon uses some opengl hw acceleration -And all widgetsets use some hand tuned graphic libs using vector libs or sse instructions. Looks like we have different definitions of hw acceleration. If it is not D3D/OpenGL/OpenES it is not accelerated in my book (hw acceleration = gfx card does the job, and no the standard 2D acceleration from 20 years ago does not count). Perhaps carbon qualifies but I don't know enough about its interiors or better I don't how the textures are created that they pass to OpenGL. And would you please stop talking about SSE. ASM _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Lord Satan [EMAIL PROTECTED]: [..] - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). @Mattias: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. For example: -gtk on embedded devices can render directly to the framebuffer. -trolltech advertises hardware accelerations on their website, but I don't know if this available for free. -afaik carbon uses some opengl hw acceleration -And all widgetsets use some hand tuned graphic libs using vector libs or sse instructions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). Well, I develop major database projects (in Delphi), and none of our customers has ever asked for a specific look. So I would be the last to ask this from lazarus. The thing I am looking for is portability. Most of our users hardly understand windows, let alone that they would require a specific (and hence more confusing) look for our application. By keeping it close to the windows standards, we make the application less frightful for them. And we have many thousands of such users. As in all things, it is dangerous to generalize your own experience. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 17:02:08 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: No, the ones I looked at was for creating standard applications (not games). They just used shadow events under menus, dropdown animation, etc... On my system the composition manager does this work not the widgetset. Sometimes people have strange ideas. I'll see if I can find them again. This would be nice. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 14:50:16 +0100 Mattias Gärtner [EMAIL PROTECTED] wrote: And if a programmer needs uncommon things, he can write a specific control. See for example the printers4lazarus or the lazopenglcontext package. They started on one platform and nowadays they run on all majors. More or less. I just can't hunt down the lazopenglcontext GTK2 resize bug. But I keep trying. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Well, Lazarus is intended to develop commercial applications, not GPL utilities to be added to Gnome desktop. Oops. Sorry, I didn't know. Commercial applications take care to provide their own specific look. If we look at some widely known multiplatform applications, we find that Red Hat created it's specific Bluecurve style, in order to avoid the native look of gtk, and provide uniform RedHat style to Gnome and Kde desktops. ... and RedHat achieved that, because the programs follow the system settings. OpenOffice, Mozilla, Gimp, Acrobat Reader (to some extent), Qt Designer, not to speak of players like Winamp or XMMS provide the same look in all platforms, with OpenOffice and Acrobat going to the point of using only their own fonts. Mozilla is using gtk under linux. OpenOffice descended from StarOffice, which look much more the same on all platforms. With every new version OO is becoming more native looking on all platforms. Gimp - it invented gtk. ... Moreover multiplatform doesn't mean adding up all limitations of the supported platforms, but rather providing a consistent look and behavior in different platforms, with minimal programmer extra work. We are trying to improve the LCL to minimize the programmer work. But we don't have the man power of Graeme and Martin, so either be patient or use fpGUI/msegui/qt/gtk/wxWidgets/... . Of course, I can take a different path for myself (fpGUI, msegui, MyOwnGui), but I feel belonging to Lazarus community, I see a lot of work being done, a lot of impressing achievements whenever the sacred cows of Delphi compatibility and widgetset compliance are forgotten, such as in component anchoring or in IDE conception. Therefore, backed by my personal experience, I feel it right to raise doubts on the priorities you clearly indicated, and humbly suggest that it could be the time to reconsider them with open mind. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Lord Satan [EMAIL PROTECTED] wrote: SDL is no acceleration, only if you use its OpenGL wrapper functionality you get hw acceleration. That's what I meant with SDL. I know a lot of those 'widgetsets', too, but they are meant for OpenGL apps and they are not general purpose widgetsets like WIN API, GTK, QT, etc. Most of them are very basic tools to provide GUIs for 3D apps. So I would really like to know of at least one specific one. No, the ones I looked at was for creating standard applications (not games). They just used shadow events under menus, dropdown animation, etc... I'll see if I can find them again. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tue, 22 Jan 2008 16:30:48 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: What does everyone else use Lazarus for? Console apps maybe? For me it is just a hobby (at work there is only C++ and no chance to ever change this). As I do graphics programming I don't need a lot of GUI elements. Some Buttons, Labels, Edits, Memos, etc. The IDE is the main reason to use lazarus for me and the IDE should use native widgets to be visually pleasing to my eyes. Since I have the freedom of ignoring Windows, I am satisfied if I can get the native Linux (GTK for Gnome and QT for KDE would be nice) and OSX look. It is just my choice and another good reason to use Lazarus. And it is really ugly to have shiny 3D graphics and Motif Buttons. I really can't care less what commercial developers need and I doubt that whining on the mailing list really impresses the Lazarus developers. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Which one is the best? How does OOP affect development (pros/cons)? Is there a better dev-approach than OOP? What has OOP missing? When is it wrong to use OOP? How can OOP be misused? Thanks for shedding some light! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Well, I develop major database projects (in Delphi), and none of our customers has ever asked for a specific look. So I would be the last to ask this from lazarus. The thing I am looking for is portability. Our clients normally don't want way-out looking apps. They simply want some customizations using various colors for example. Validation screens must change background colors of components to indication an error state or missing input, Label colors indicating some or other business status etc... As you can see, I'm not talking about triangular buttons or odd shaped forms - just subtle customizations. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Al Boldi ha scritto: Giuliano Colla wrote: I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Compiled languages: 1) Assembler from HP minicomputers to IBM mainframes (including an incredible Siemens computer, which at start-up was typing an obscure message in german: if you just typed return, it would take the default action, i.e. assume a new installation and reformat its hard disks! :-) ) , and then micros for all the Intel Family, from 4004 (it was a nightmare, three instructions to read a memory location but with good macros you could get away) to nowadays Pentium 2) Fortran (different flavors in time) 3) Algol 60 4) Intel's PLM's: PLM48 PLM51 PLM80 PLM86 PLM386 5) C 6) C++ 7) Delphi Pascal 8) Free Pascal Interpreted Languages: 9) Basic 10) Visual Basic 11) Python 12) Tcl/Tk Possibly I've left out some, but that's more or less the picture. Which one is the best? Among non OOPL PLM was certainly the best, both in terms of code efficiency and in clean syntax, with the best way I've ever met to deal cleanly with typed pointers (nothing to do with the C mess). It made almost possible to make it become an OOPL, with a minimal extra work. Among OOPL doubtlessly Pascal. However it's a matter of goal. You always end up with native computer instructions: the best language is the one which gives you the best compromise in terms of development costs, maintenance costs, and performance. If the language is good, but the compiler fails to provide efficient code, then it's not the right choice. That's why IBM's PL1 was a failure. How does OOP affect development (pros/cons)? Well designed objects provide the two features of reusability and hidden implementation, which strongly reduces development/debug time. But you must be careful. The clean syntax of Pascal, the clean separation between Interface and implementation encourages to provide good objects. Can't say the same for C++. Bad C habit of making public whatever isn't declared static, or to let through implicit declarations can lead to strange bugs very hard to detect. The con's are that it may encourage lazyness. You may end up using an object because it's ready made, taking advantage of a minimal part of its features, and making your code bigger and slower, and maybe harder to debug, when a small subroutine could have served the same purpose. Is there a better dev-approach than OOP? There's never a best for all approach. If I need to test a formula, Basic is still the best language. If I need a device driver, I may find out that I get the required efficiency only by assembler. Each problem requires the appropriate tools. Tombstones are made of stone. It's a stone-age technology, but it's the most appropriate to cover a grave. What has OOP missing? Well, standard C++ misses the property assignement, unless you go through the chore of overloading the '=' operator. For the rest I'm quite happy with it. When is it wrong to use OOP? Whenever it's not appropriate. How can OOP be misused? Using it when not appropriate. Thanks for shedding some light! Go and be content, my young friend. Study, when you've learned start coding, and don't sin any more. (I can detect sarcasm at least since as long as I have been programming, but your questions deserved a reply nonetheless). Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys ha scritto: On 22/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: Well in all that time I've never met a single customer requiring a native look. On the contrary what I've always been asked for is a specific look, and specific behavior. Amazingly, I have had the exact same experience. They want their product to stand out and not blend in and be unnoticed. Corporate colors in the application is also a big hit (and where LCL fell over). I only develop commercial applications with Lazarus and from judging by all these conversations, it seems like we are the only two. Also we seem to experience the same issues - coincidence? It's the two of us against the rest of the world, one would say! :-) What does everyone else use Lazarus for? Console apps maybe? I can't say. I read that someone is *using* gtk2. I tried to make a form with a button, and the lower half of the caption was lost. I tried to put a panel with a memo on the form, and I could see the panel through the memo (or the opposite, I don't remember). From time to time I recover my test form, retry it and the situation hasn't changed. I would never think that it's usable. But someone claims to use it. What for is a mystery for me. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 22, 2008 8:35 PM, Giuliano Colla [EMAIL PROTECTED] wrote: I can't say. I read that someone is *using* gtk2. I tried to make a form with a button I suppose you meant the gtk2 Lazarus interface. Well, I use it for: http://magnifier.sourceforge.net/ And works pretty well. The magnifier can't actually run in gtk1 at all: it doesn't support screenshot taking. (I tryed to implement it once, didn't work, gave up) And also use it for Lazarus under Linux since more then 1 year and it's quite stable. I think this is another case that generalizing one's experience doesn't work =) I probably never used the things you mentioned on gtk2, so I never noticed they don't work and never had the need to find out why they don't work. The magnifier uses buttons, a TPageControl, a tray icon, some menus, etc, all those things work well in Gtk 2 since more then 1 year at least. At least in the way I used them on the project. My idea of open source is that if everyone fixes the small issues they find. Just enougth to make their apps work. We will eventually have a perfect/bug-free project =) Today I don't see any reason why I would use gtk 1 anymore. Even if the gtk2 interface has bugs, gtk1 has catastrophical failures for me: * Horrible look * Bad/inconsistent internationalization support * Not developed anymore, long time ago obsoleted thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Joost van der Sluis ha scritto: Op dinsdag 22-01-2008 om 15:03 uur [tijdzone +0200], schreef Graeme Geldenhuys: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? Hindsight is a awesome thing. :-) For me: if Lazarus woudn't use native widgets, I woudn't use it. It's one of the most important features for me. You mean that someone is eager to see gtk1 style widgets? Or someone is prepared to pay to get a dialog Cancel - Retry -Abort if something goes wrong, instead of a dialog telling something meaningful? Else I could also use Java, for example. for me the main issue with Java is that it doesn't 'feel' native for most users. Well Java is simply ugly, unless you make a lot of work on it. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: Al Boldi ha scritto: Giuliano Colla wrote: I've been earning my bread and butter developing computer applications for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Compiled languages: 1) Assembler from HP minicomputers to IBM mainframes (including an incredible Siemens computer, which at start-up was typing an obscure message in german: if you just typed return, it would take the default action, i.e. assume a new installation and reformat its hard disks! :-) ) , and then micros for all the Intel Family, from 4004 (it was a nightmare, three instructions to read a memory location but with good macros you could get away) to nowadays Pentium 2) Fortran (different flavors in time) 3) Algol 60 4) Intel's PLM's: PLM48 PLM51 PLM80 PLM86 PLM386 5) C 6) C++ 7) Delphi Pascal 8) Free Pascal Interpreted Languages: 9) Basic 10) Visual Basic 11) Python 12) Tcl/Tk Possibly I've left out some, but that's more or less the picture. Which one is the best? : : Among OOPL doubtlessly Pascal. Why? How does OOP affect development (pros/cons)? : : The con's are that it may encourage lazyness. You may end up using an object because it's ready made, taking advantage of a minimal part of its features, and making your code bigger and slower, and maybe harder to debug, when a small subroutine could have served the same purpose. Good point. (I can detect sarcasm at least since as long as I have been programming, but your questions deserved a reply nonetheless). Actually, there should be nothing sarcastic about trying to learn from somebody more experienced. Just one more question: In another thread you said Java is ugly, what about the language, and how does it compare to pascal? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 22/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: I probably never used the things you mentioned on gtk2, so I never noticed they don't work and never had the need to find out why they Maybe we should create a 'universal' widget set test application... Remember the old one in fpGUI v0.4 (widgetdemo)? That really helped to debug issue between X11 and GDI implementation? I think one can create a much better / in depth toolkit test application for Lazarus. It can test the firing of event orders, runtime (life) component property changes to see the effect, etc... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys schreef: On 22/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: I probably never used the things you mentioned on gtk2, so I never noticed they don't work and never had the need to find out why they Maybe we should create a 'universal' widget set test application... Remember the old one in fpGUI v0.4 (widgetdemo)? That really helped to debug issue between X11 and GDI implementation? I think one can create a much better / in depth toolkit test application for Lazarus. It can test the firing of event orders, runtime (life) component property changes to see the effect, etc... I have been thinking about that too, even started part of it. One of the problems is that X11 and GDI and MacOSX all have different way of triggering events. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Al Boldi ha scritto: Giuliano Colla wrote: Which one is the best? : : Among OOPL doubtlessly Pascal. Why? Well, Pascal syntax is much cleaner. It's been planned. C syntax appears to have been made on the way. C (and C++) try to avoid typing as much as possible, and this makes code much less readable. This means in the long run more errors. Pointer arithmetic of C is simply a way to encourage programmer errors. In Pascal you have one Interface section and an Implementation section. They can't be inconsistent because the compiler will tell you, and the Interface is what is used by all other units. In C you have a source file and header files. Your program is the source, but other units will use the header file. If they're inconsistent you'll learn when debugging the program. If you fail to detect inconsistencies, it'll be the end users to experience the trouble. We have our main line of application which is made by some tens of thousands lines in Delphi Pascal, and by a few thousand lines in C. It's a code base we're using for a line of industrial controls, and the C portion is required for the real-time part, which interacts with the Linux kernel. We make a new version for each new control, roughly two a month. Each time, during debug, there are many more errors in the C portion, than in the Pascal portion, although the Pascal portion is ten times larger. But Pascal errors are detected by the compiler, C error by testers. I'm trying to see if the C section could be written in Pascal. Just one more question: In another thread you said Java is ugly, what about the language, and how does it compare to pascal? I don't know enough about Java language to formulate a judgment. I've never used it, and a casual glance to some source code isn't enough to draw conclusions. I seldom used interpreters, because I've always been looking in need of fast response. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Felipe Monteiro de Carvalho ha scritto: On Jan 22, 2008 8:35 PM, Giuliano Colla [EMAIL PROTECTED] wrote: I can't say. I read that someone is *using* gtk2. I tried to make a form with a button I suppose you meant the gtk2 Lazarus interface. Well, I use it for: http://magnifier.sourceforge.net/ And works pretty well. The magnifier can't actually run in gtk1 at all: it doesn't support screenshot taking. (I tryed to implement it once, didn't work, gave up) Please give a look to the attached screenshots. Design form, and result with gtk2 r13823. The test isn't by me, but by someone who complained about z-order in gtk2 not being correct. A lot of time ago. I know, it's voluntary work, everybody does its best. We take what's available, and thank. But please don't tell me that gtk2 can be taken in consideration for anything else than a specific project carried on by a Lazarus developer, who knows enough the internals to fix the widgets he needs. Today I don't see any reason why I would use gtk 1 anymore. Even if the gtk2 interface has bugs, gtk1 has catastrophical failures for me: * Horrible look I agree, but it's *native look* ;-) * Bad/inconsistent internationalization support I agree. * Not developed anymore, long time ago obsoleted I agree. But an average user can complain about a few well delimited bugs. Gtk2 doesn't require bug fixes, require implementing. It's not ready. Qt, which still is not usable, is more advanced at the moment. What works works, what isn't there doesn't. The priority, for Lazarus 1.0, if I understand properly, was to have at least one widgeset (gtk1) complete. So I don't complain about gtk2, but I can't use it either. Giuliano inline: TestForm0.pnginline: TestForm1.png
Re: [lazarus] Introduction
Le mardi 22 janvier 2008 à 15:12 +0100, Giuliano Colla a écrit : Well, Lazarus is intended to develop commercial applications, not GPL utilities to be added to Gnome desktop. Commercial applications take Clic paste from the about box, today's svn: 'License: GPL/LGPL' IMO Lazarus is (not so far to be) the best tool to develop GPL utilities to be added to Gnome desktop. But not only utilities. Not only Gnome. 'can be LGPL libraries, and so on... Lazarus can be used in order to develop professional apps. One can make a living thanks to fpc/lazarus. Fine! care to provide their own specific look. Sometimes, Free Softwares have to provide specific look too. For example, multimedia softwares... Actually, I love fpc and lazarus because they're intended to develop... so many kind of apps. And they're free. I hope ;-) -- Linuxeries http://linuxeries.blogspot.com Toraka Bilaogy http://torakabilaogy.blogspot.com _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Le mardi 22 janvier 2008 à 16:30 +0200, Graeme Geldenhuys a écrit : I only develop commercial applications with Lazarus and from judging by all these conversations, it seems like we are the only two. Also we seem to experience the same issues - coincidence? What does everyone else use Lazarus for? Console apps maybe? From time to time, I needed some specific looks. And I'm still needing them, in fact. But, guys, I'm really thankful to you guys who have done the amazing efforts (and good priority choice) in native look stuffs (especialy GTK2 ;-)) I can be wrong, but IMO most developers just need to be able to build softwares that just 'fit' into the user's graphical environment. Softwares that have the same behaviours defined by the window manager that their users choosed to use... and are used to use ;-) Actually, as of today I haven't use Lazarus to build apps for customers (not the Lazarus/fpc's fault), but most users and customers I met just want standardized apps (look, and... feel!) so they don't have to learn how to use this flashy and unusual open file dlg. Nor this 'metalic' and so particular java thing. I understand and I know that some customer need specific look feel. More than their logo in a splash-screen. But, hey guys... IMO both point of view are ok! both lookfeel useful. It depends of your user's needs. And as a developer, the more choice the better. Thanks to FPC, Lazarus... to you! So, native lookfeel as the very first priority is a good choice. Specific ones are welcome, as they can be very usefull in some contexts. Lazarus... what a rich and wonderful world!! keep on... -- Linuxeries http://linuxeries.blogspot.com Toraka Bilaogy http://torakabilaogy.blogspot.com _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 23, 2008 2:08 AM, Giuliano Colla [EMAIL PROTECTED] wrote: The test isn't by me, but by someone who complained about z-order in gtk2 not being correct. A lot of time ago. I know, it's voluntary work, everybody does its best. We take what's available, and thank. But please don't tell me that gtk2 can be taken in consideration for anything else than a specific project carried on by a Lazarus developer, who knows enough the internals to fix the widgets he needs. And what do you plan to do about it? What I mean is very simple: I have to get to work at 7:30 and come back at 21:00. Why would I use my spare time to hunt for the endless, arbitrary bugs in the gtk2 interface? And my experience with the gtk/gtk2 interface is enougth to say it ain't particularly fun to work endless hours to fix small bugs on that spaguetti code, which often ends up without any fix. If the bug is annoying you, then *you* should do something about it =) If all users use the approach: Oh, I'll test now and wait 3 months and test again, then they are all risking that in 3 months there won't be any change to what they wanted changed. If you don't plan on doing anything about it, then I say it's not that annoying for you, because it's not annoying enougth to make you do something about it =) regards, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Mon, 21 Jan 2008 08:39:54 +0100 Florian Klaempfl [EMAIL PROTECTED] wrote: Lord Satan schrieb: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the point. fpGUI may be a nice idea but I got a little tired about reading how great it is over and over again (because it is really, really ugly, not the native gui for the different supported plattforms and native gui support has always been the aim of lazarus development - no offence Graeme). So if any lazarus developer is offended, I apologize and instead of calling them stupid thank them for their great work. P.S.: Perhaps I should have used the ASM keyword to suppress any mails (bonus points for everyone who understands this statement) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 21/01/2008, Lord Satan [EMAIL PROTECTED] wrote: That's the point. fpGUI may be a nice idea but I got a little tired about reading how great it is over and over again (because it is really, really ugly, not the native gui for the different supported plattforms and native gui support has always been the aim of lazarus development - no offence Graeme). No offence taken. fpGUI is a young project and making it look native is on the todo list. It simply hasn't been a priority yet (I have lots of other things to do first). As for looking native... everybody keeps raving about how great Pixel (image editor) looks like! Did you know that's not native components either! :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Mon, 21 Jan 2008 11:45:16 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: No offence taken. fpGUI is a young project and making it look native is on the todo list. It simply hasn't been a priority yet (I have lots of other things to do first). As for looking native... everybody keeps raving about how great Pixel (image editor) looks like! Did you know that's not native components either! :) Of course. It tries really hard to emulate my theme settings but fails miserably. Starting Pixel is like getting poked in the eye. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The result is that vcl compatibility is reduced to the minimal subset of coincident specs between native widgetset and vcl. Which is very often unsatisfactory. For my range of applications this makes LCL completely useless. I find one feature supported by gtk1, one supported by gtk2, another one by Qt, but nowhere all the required features supported. Either one takes the Qt way, i.e. using style to *mimic* the native *look*, without actually using it, and provides a consistent behavior, regardless of the widget appearance, or a cross-platform application is unable to provide consistent behavior without loads of IFDEF's, which defeat the very cross-platform idea. The current trend of moving implementation from LCL to widgetset goes exactly in the opposite direction: it becomes more *native*, and loses vcl specs. There's also something to say about *native* widgetsets: show me someone really requesting a GTK1 native look, and which doesn't believe at the same time to be Napoleon, and I'll change my opinion. -:) The initial coding for fpGUI was done at the same time as lazarus starts (1999). However, nobody was interested in contributing to it so it went into hibernation. Without a mature IDE to work with, fpGUI isn't worth the trouble. It becomes much easier to learn C++ and use Qt Designer, or whatever. But a mature IDE is the real achievement of Lazarus team. Not being hampered by *native* considerations, or other impossible constraints, they've achieved an impressive work. It's Lazarus IDE which makes fpGUI worth considering today, and which could make worth seriously considering fgGUI way, i.e. an alternative to the buggy and inconsistent *native* widgetsets, for all the range of applications which require it. Just my two cents. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 21/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The result is that vcl compatibility is reduced to the minimal subset of coincident specs between native widgetset and vcl. Which is very often unsatisfactory. For my range of applications this makes LCL completely useless. I find one feature supported by gtk1, one supported by gtk2, another one by Qt, but nowhere all the required features supported. Exactly my point. All the different GUI toolkits have different features. LCL can only implement the features that are common across toolkits. Hence the issue with setting a Form or Components background color when compiled against GTK (sorry, I had to mention that one again smile). VCL had it easy. They built their interface according to _one_ GUI toolkit, the Win32 API. And as soon as you used Delphi (VCL) and Kylix (CLX) on the same source code with native components in mind, you would have noticed how quickly you need to start adding IFDEF's. LCL is in the same boat, but the Lazarus team did improve on Borland's idea. Without a mature IDE to work with, fpGUI isn't worth the trouble. It becomes much easier to learn C++ and use Qt Designer, or whatever. Umm... I don't know how I should take this! :-) fpGUI is by no means tied to Lazarus. I often build my apps on test machines using 'gedit' or 'mcedit' via the command line. Also, fpGUI has it's own visual forms designer. Saying all this, I still prefer to use Lazarus as my editor - with all the add-ons, source code navigation and keyboard shortcuts, I'll be hard pressed to find any other editor that comes close to it. Just my two cents. ;-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 21/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report Yeah, I can't even remember what the original post was about? :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Michael Van Canneyt ha scritto: On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. It provides properties and methods which are in most cases self-explanatory. The Color Property of a Form or of a Button dictates its color. Well, try just to set this property to clRed, or clButtonFace with different widgesets, and compare the behavior. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Or they could achieve native look just by using a Bitmap, and consistent behavior with code in LCL, with less duplicated work, less bugs, and better results. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. When you're told that the feature can't be implemented because the widgetset doesn't support it, you stop reporting. When you see that the development line is to move the implementation from LCL to widgetset, instead of the opposite, (and breaking what was already working in the process), you stop providing patches, and start whining. :-( Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Monday 21 January 2008 01:18:56 pm Giuliano Colla wrote: Either one takes the Qt way, i.e. using style to *mimic* the native *look*, without actually using it, and provides a consistent behavior, this does not honour the huge Qt effort. Qt DOES use the native widget when necessary do have native look for XP, Vista and Mac OS X style. This is why these styles are not available on the other platforms because the lack of the native widget set library. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: However, if you're so kind to tell me: 1) What is the irc channel (do I need a life jacket to join it? :-) ) 2) How to join it I'll gladly join the irc channel, because, from a user standpoint, I've Server irc.freenode.net, join #lazarus-ide. See you there ;-) Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Micha Nelissen ha scritto: Giuliano Colla wrote: However, if you're so kind to tell me: 1) What is the irc channel (do I need a life jacket to join it? :-) ) 2) How to join it I'll gladly join the irc channel, because, from a user standpoint, I've Server irc.freenode.net, join #lazarus-ide. See you there ;-) Thanks a lot, I'll try right away. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 21, 2008, at 10:03 PM, Graeme Geldenhuys wrote: On 21/01/2008, Den Jean [EMAIL PROTECTED] wrote: On Monday 21 January 2008 01:18:56 pm Giuliano Colla wrote: Either one takes the Qt way, i.e. using style to *mimic* the native *look*, without actually using it, and provides a consistent behavior, this does not honour the huge Qt effort. Qt DOES use the native widget when necessary do have native look for XP, Vista and Mac OS X style. This is why these styles are not available on the other platforms because the lack of the native widget set library. Nope, it's like I explained before. Qt does all custom painting, it does not required the underlying 'native' widgets. They used to copy the look of OS's by manually drawing all controls. Since late 3.x or starting with 4.x (not sure which version) Qt under XP, Vista, MacOS X and GTK asks the corresponding component (via native API) to draw itself on a memory bitmap. Qt then paints that bitmap to the correct location on the form. This overcomes the issue when user install there own custom themes. Qt does not create a instance of the native widget. For others I don't know but for Carbon I have a big doubt. -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 20, 2008, at 8:00 AM, Graeme Geldenhuys wrote: On 20/01/2008, Damien Gerard [EMAIL PROTECTED] wrote: I better understand with all these explanations. Thanks to all ! Again, I disagree. ;-) I did a study on this. I opened a random set of applications that have things like File Dialogs and Font Dialogs. You will be amazed at the amount of different dialogs being used. They are not all the same - some look similar though. Some dialogs in applications don't have the shortcut bar on the left etc... This was true for Windows and Gnome. KDE was the most consistent of them all. I've already put some thought into adding a shortcut feature in File Open and File Save dialogs. fpGUI's font dialog is much better (or will be) than Windows or GTKx's ones. It has a Collections column sorting fonts by All fonts, Recently Used, Favourites, Fixed Width, Sans, Serif and Font Aliases. Other improvement to any dialog type could easily be added if needed. Overall they work similar to all other 'native' dialogs, so the user will have no difficulty in using them. I don't think the Font dialog matters under win and Unix (for now). But for Open and Save dialogs it was a criteria for my clients when they saw the different prototypes, the same for integration for the OS (that means a version for Ubuntu and a version for KDE and a Windows version with the good themes) -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Am Sonntag, den 20.01.2008, 09:00 +0200 schrieb Graeme Geldenhuys: Always speaking about GTK-bugs but what about fpGUI bugs ? When using Lazarus and the LCL, the underlying toolkits are not under your control. It's quick and easy to fix fpGUI bugs. You can't fix Win32 native component bugs and how long until you see GTK1 or GTK2 bug fixes come through. Only one additional note: fpGUI is actively developed, GTK1 is long time abandoned in favour of GTK2. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 20/01/2008, Marco van de Voort [EMAIL PROTECTED] wrote: Apparantly the only person with skills to run into that started his own widgetset :-) It didn't even take a lot of effort to hit those problems... Just write commercial software. :-) Good news is that some day Lazarus will benefit from my work with fpGUI. I would like to try and complete the LCL-fpGUI integration to have it as another working widgetset choice for developers using Lazarus and LCL. Obviously this is all time permitting so I have no time frame set. I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Lord Satan wrote: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. Now we only get this sucking Win API, GTK1, GTK2, Carbon and QT. Nothing really works and all is full of bugs. Take easy. If you are not help with it you have three options: - Don't use anymore - Make patches - Do a fork For myself i have some differences with Lazarus developers vision, but i will never call them stupid. Instead, i make patches. Luiz _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Lord Satan wrote: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. Now we only get this sucking Win API, GTK1, GTK2, Carbon and QT. Nothing really works and all is full of bugs. If we had used OpenGL, then we had to create out component framework first. Keep in mind, Lazarus is primarely focused in using *native* components and I repeat it again *native* components. OpenGL is *not* native. EOD. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Lord Satan schrieb: On Sun, 20 Jan 2008 22:33:53 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: I still think having a custom Object Pascal written toolkit for Lazarus is the way to go. The LCL would have progressed and stabilized much faster if the Lazarus developers did that from the start. That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. The initial coding for fpGUI was done at the same time as lazarus starts (1999). However, nobody was interested in contributing to it so it went into hibernation. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 21/01/2008, Lord Satan [EMAIL PROTECTED] wrote: Stupid Lazarus developers. Now we only get this sucking Win API, GTK1, GTK2, Carbon and QT. Nothing really works and all is full of bugs. I agree with Luiz. Lazarus developers are *not* stupid. They have done an amazing job so far in getting the LCL to wrap so many toolkits - it just wasn't the right fit for our company. They simply followed a different path to what I would have taken, but I am sure at the time they thought it to be the best solution. Hindsight is always great! ;-) Plus, if it wasn't for them, I wouldn't have such a cool IDE to work with! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Lee Jenkins [EMAIL PROTECTED] wrote: I think for me, the biggest challenge was re-thinking the GUI widgets that I use. Windows development seems to be centered around the sizzle of GUI components where everyone is trying to have their apps look like the latest version of MS Office and I have been on that bandwagon a bit myself until recently. We didn't want to go that way out. We simply wanted to use different background colors (corporate colors) for Forms, Labels and Buttons. Such a simple thing, yet the LCL didn't allow us to change those. That was 2 years ago, I don't know if things have improved since then. A quick search in Mantis reveals that nothing has changed... http://bugs.freepascal.org/view.php?id=7555 (dated 2006) http://bugs.freepascal.org/view.php?id=1006 (dated 2005) http://bugs.freepascal.org/view.php?id=9293 (dated 2007) http://bugs.freepascal.org/view.php?id=10483 (dated 2006) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Martin Schreiber [EMAIL PROTECTED] wrote: 1. Start cranking out LCL patches to fix the issues. ;-) 2. Ditch the LCL, but continue using Lazarus with a different GUI toolkit. I've had great success with option 2. 3. MSEide+MSEgui ;-) Has anybody actually tried to use MSEgui with Lazarus IDE? Or is MSEgui tide to much to MSEide? I guess it could be possible, but due to MSEgui having such a huge amount of options (enum properties etc..), it would be a daunting task. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Jan 19, 2008 9:39 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: We didn't want to go that way out. We simply wanted to use different background colors (corporate colors) for Forms, Labels and Buttons. Such a simple thing, yet the LCL didn't allow us to change those. That was 2 years ago, I don't know if things have improved since then. Well, the fault isn't Lazarus or it's developers. The problem is GTK!! (all bug reports you mentioned are Gtk specific) I tryed very hard to solve the window color problem some time ago, but GTK just doesn't cohoperate. It's a rather problematic toolkit. On Jan 19, 2008 9:44 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Has anybody actually tried to use MSEgui with Lazarus IDE? Or is MSEgui tide to much to MSEide? I guess it could be possible, but due to MSEgui having such a huge amount of options (enum properties etc..), it would be a daunting task. You mean like a new widgetset? I took a quick look some time ago, I think that the greatest problems are: * Having a stable API, otherwise the work is almost useless * Having examples which don't use the form designer thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: Well, the fault isn't Lazarus or it's developers. The problem is GTK!! (all bug reports you mentioned are Gtk specific) Ah yes, now I remember someone mentioning something like that I tryed very hard to solve the window color problem some time ago, but GTK just doesn't cohoperate. It's a rather problematic toolkit. I remember I was told to use a custom theme file, but that would change it for all application, and I needed to change colors based on data entered in forms (validation things), so that solution was totally useless. You mean like a new widgetset? No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). * Having examples which don't use the form designer Oh yeah, that could be a problem with MSEgui I think. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Felipe Monteiro de Carvalho schreef: On Jan 19, 2008 9:44 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Has anybody actually tried to use MSEgui with Lazarus IDE? Or is MSEgui tide to much to MSEide? I guess it could be possible, but due to MSEgui having such a huge amount of options (enum properties etc..), it would be a daunting task. You mean like a new widgetset? I guess Graeme means as a replacement of the LCL. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Sat, 19 Jan 2008 11:53:17 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 19/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: Well, the fault isn't Lazarus or it's developers. The problem is GTK!! (all bug reports you mentioned are Gtk specific) Ah yes, now I remember someone mentioning something like that I tryed very hard to solve the window color problem some time ago, but GTK just doesn't cohoperate. It's a rather problematic toolkit. I remember I was told to use a custom theme file, but that would change it for all application, and I needed to change colors based on data entered in forms (validation things), so that solution was totally useless. Did you know http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_my_gtk_programs_use_custom_rc_files.3F ? You mean like a new widgetset? No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). Is it possible to design fpGUI apps with the same trick as he KOL package? * Having examples which don't use the form designer Oh yeah, that could be a problem with MSEgui I think. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Mattias Gaertner [EMAIL PROTECTED] wrote: Did you know http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_my_gtk_programs_use_custom_rc_files.3F ? That's exactly what I was refering to. But as far as I understood it, you can change for example TEdit's background on demand. For example, it a edit form the user might have left out some required details. Those edit forms will have their background colors set to yellow. As they enter information, the TEdit's background color gets reset (which is also a issue still active on Mantis if I remember correctly). The reason I said it's useless for what I want to do. No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). Is it possible to design fpGUI apps with the same trick as he KOL package? I don't know KOL, could you explain more...? A quick look on the Lazarus wiki site, it sounds like KOL is something used for WindowsCE applications. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Mattias Gaertner [EMAIL PROTECTED] wrote: No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). Is it possible to design fpGUI apps with the same trick as he KOL package? I read some more on KOL at [http://kolmck.net/]. As I understand it, it's a miniture GUI toolkit used instead of VCL (under Delphi). fpGUI is small, but not as small as KOL (their example showing 20k executables). For example the fpGUI Visual Form Designer (which uses all available fpGUI components) is 600kb in size (debug information stipped). So yes, it's much smaller that LCL in that sense As for the same trick as KOL package statement - could you explain this further? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Sat, 19 Jan 2008 19:17:37 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: On 19/01/2008, Mattias Gaertner [EMAIL PROTECTED] wrote: No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). Is it possible to design fpGUI apps with the same trick as he KOL package? I read some more on KOL at [http://kolmck.net/]. As I understand it, it's a miniture GUI toolkit used instead of VCL (under Delphi). fpGUI is small, but not as small as KOL (their example showing 20k executables). For example the fpGUI Visual Form Designer (which uses all available fpGUI components) is 600kb in size (debug information stipped). So yes, it's much smaller that LCL in that sense As for the same trick as KOL package statement - could you explain this further? You can design KOL apps and forms visually in Lazarus. The trick is that KOL is quite LCL compatible and tells the IDE to be treated like the LCL. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Graeme Geldenhuys schreef: On 19/01/2008, Mattias Gaertner [EMAIL PROTECTED] wrote: No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). Is it possible to design fpGUI apps with the same trick as he KOL package? I read some more on KOL at [http://kolmck.net/]. As I understand it, it's a miniture GUI toolkit used instead of VCL (under Delphi). fpGUI is small, but not as small as KOL (their example showing 20k executables). For example the fpGUI Visual Form Designer (which uses all available fpGUI components) is 600kb in size (debug information stipped). So yes, it's much smaller that LCL in that sense As for the same trick as KOL package statement - could you explain this further? Read more about it in this thread: http://www.mail-archive.com/lazarus@miraclec.com/msg21410.html Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Am Samstag, den 19.01.2008, 19:09 +0200 schrieb Graeme Geldenhuys: For example, it a edit form the user might have left out some required details. Those edit forms will have their background colors set to yellow. As they enter information, the TEdit's background color gets reset (which is also a issue still active on Mantis if I remember correctly). Something like that can be done. I remember posting some code here or on the fpc users list. If this still is an issue I can post a snippet switching the bar color of a slider, which is done at runtime. That was a rather nasty experience, because some theming engines interfere with this bar color (not implementing all kinds of stuff or not respecting properties set from the program), but for TEdit I think it'll be straight forward. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
From: Vincent Snijders [EMAIL PROTECTED] Graeme Geldenhuys schreef: On 19/01/2008, Mattias Gaertner [EMAIL PROTECTED] wrote: No, I mean like I am using fpGUI. I use Lazarus IDE as my editor and manage the fpGUI packages. Lazarus simply thinks I'm creating a Free Pascal application (not a Lazarus Application). Is it possible to design fpGUI apps with the same trick as he KOL package? I read some more on KOL at [http://kolmck.net/]. As I understand it, it's a miniture GUI toolkit used instead of VCL (under Delphi). fpGUI is small, but not as small as KOL (their example showing 20k executables). For example the fpGUI Visual Form Designer (which uses all available fpGUI components) is 600kb in size (debug information stipped). So yes, it's much smaller that LCL in that sense As for the same trick as KOL package statement - could you explain this further? Read more about it in this thread: http://www.mail-archive.com/lazarus@miraclec.com/msg21410.html KOL has separate library of mirror classes named MCK. MCK installed into Lazarus as package. MCK components are regular visual or non-visual LCL components which have the same properties as corresponding KOL components. You can design your application using Lazarus IDE and MCK components, but as result you get pure KOL project which not depends on LCL and even SysUtils and Classes. MCK library works as IDE expert and modifies form's unit code on fly by inserting needed defines and other modifications. It also generates runtime form creation using code and KOL controls. Form streaming and RTTI are not used at all. It is better to install KOL-CE into Lazarus to see how it works... Yury. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Marc Santhoff [EMAIL PROTECTED] wrote: That was a rather nasty experience, because some theming engines interfere with this bar color (not implementing all kinds of stuff or not respecting properties set from the program), but for TEdit I think it'll be straight forward. The other problem was that we needed our application to work under Windows and Linux. The whole point of moving over to Free Pascal and Lazarus was not to have IFDEF's in our code, like we had between Delphi and Kylix. fpGUI has solved all those issue for us. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On 19/01/2008, Mattias Gaertner [EMAIL PROTECTED] wrote: You can design KOL apps and forms visually in Lazarus. The trick is that KOL is quite LCL compatible and tells the IDE to be treated like the LCL. No, fpGUI is not that compatible with LCL. It's different, but not way different like MSEgui. fpGUI has it's own visual form designer. The really nice thing is that Lazarus detects file changes when it gets focus so it's pretty much like pressing F12. I switch between the UI Designer and Lazarus with ease. The other difference in fpGUI is that the UI Designer writes the GUI as Object Pascal code, directly in the .pas unit. It doesn't use a external .lfm file like Lazarus. The designer inserts comment markers in the code to know what code to manage and _only_ changes that code. One set of comment markers in the interface section (for field variables) and one set in the implementation section. I actually spoke to Michael about this recently. The UI Designer also has another very nice feature. It can handle unknown components or properties as well. Unknown components are draw in the designer as green rectangle with the name and type of the component. The component palette also has a Unkown component you can drop on a form. The Object Inspector has a text memo with holds all unknown properties. Whatever is written in there gets added as is in the implementation section of that component. This works very nice. The designer also supports Property Editors - eg: the column editor for StringGrid. See the following for a image of the designer at work. The screenshot is a bit dated (new components have been added), but it gives you an idea. http://opensoft.homeip.net/fpgui/images/form_designer.png Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
