Hello Lazarus-List,

I wrote a little text induction feature to TCustomEdit, is is being done using LCL in Windows platform (without using Windows unit) where it works fine. The induction is the grayed text that appears in some textboxes like the attached one (taken from my windows code).

To work in Windows it overrides the EraseBackground to paint the induction and the WMPaint message to not paint anything if no text available in the textbox.

The problem is that in GTK2 this effect is not obtained as the EraseBackground is never called and message WMEraseBackground is never called also.

GTK2 is almost new to me so I'm lost on how to solve this and if is in fact possible to solve it with the current LCL/GTK2 interaction.

I hope somebody can give some hints or maybe simple says that "impossible with current LCL implementation".

Thank you.

EraseBackground message is only send for TCustomControl descendants. Therefore you get no message for TEdit.

Best regards,
Paul Ishenin.

why don't you override/change RealSetText (called by SetText).

If it's empty, supply the special text (and change the color). if it isn't empty, change the color back (only if it was changed; if the text was empty before)

Martin

Hello Lazarus-List,

Friday, February 5, 2010, 2:47:20 PM, you wrote:

M> why don't you override/change RealSetText (called by SetText). M> If it's empty, supply the special text (and change the color). if it M> isn't empty, change the color back (only if it was changed; if the text M> was empty before)

Because in that case you are "fooling" the text content and prone to errors because the control must handle every possible way to get the text content including windows messages from other applications and maybe other unknown modes from GTK2 or other widgetset. This code should alter the way a information is presented, not the information itself to avoid incompatibilities.

That was my first approach but I discard it due changing internal data.

Hello Lazarus-List,

you wrote

> The problem is that in GTK2 this effect is not obtained as the > EraseBackground is never called and message WMEraseBackground is never > called also.

PI> EraseBackground message is only send for TCustomControl descendants. PI> Therefore you get no message for TEdit.

Yes but in Windows the EraseBackground method is being called for TEdit, not the message.

I'll put some writelns here and there and perform a bit more checks, like painting everything in WMPaint :-?

JoshyFun wrote

Because in that case you are "fooling" the text content and prone to errors because the control must handle every possible way to get the

In fpGUI we introduced a new property called TfpgEdit.ExtraHint

That way it doesn't interfere with the actual text content - no matter how it is set. The ExtraHint text is painted directly onto the TfpgEdit background. But then again in fpGUI I have full control over all components design - I don't know the various LCL backends and there limitations on doing things.

Painting directly onto TEdit's background canvas - is that what you are having issues with under GTK2?

It's because ws paints such control (same like under qt), you can paint on it whatever, but at the end your changes won't be visible since ws theme painter do the job.
At the end of this page http://wiki.lazarus.freepascal.org/User:Zeljan you can find the way how to cheat qt (so maybe there's similar way with gtk2), and have own paintings, but LCL doesn't provide eg. OwnerDraw property for TCustomEdit, or some result from paint message, where ws should know how to paint control (does ws paint , or we cheat it and we made our custom painting).

zeljko

Yes, trying to change the painting of standard controls leads to problems because each widgetset will deal with it differently.

The most assured solution to work everywhere is to implement your own TEdit from scratch with just custom painting.

Hello Lazarus-List,

Friday, February 5, 2010, 4:35:18 PM, you wrote:

GG> In fpGUI we introduced a new property called TfpgEdit.ExtraHint GG> That way it doesn't interfere with the actual text content - no matter GG> how it is set. The ExtraHint text is painted directly onto the GG> TfpgEdit background. But then again in fpGUI I have full control over GG> all components design - I don't know the various LCL backends and GG> there limitations on doing things.

fpGUI is not a problem as they are not native, you can draw whichever you want, but lost other capabilities inherited from the native system like the syntetic read for impared people.

GG> Painting directly onto TEdit's background canvas - is that what you GG> are having issues with under GTK2?

More or less :) Mostly is tell to GTK2 that I'll paint something over TEdit and please GTK do not erase it :) or I "you" do it let me know to repaint my own content.

Hello Lazarus-List,

you wrote

> Painting directly onto TEdit's background canvas - is that what you > are having issues with under GTK2?

z> It's because ws paints such control (same like under qt), you can paint on it z> whatever, but at the end your changes won't be visible since ws theme painter z> do the job.

Yes that seems to be the cause, something out of my control is finally painting the content.

z> At the end of this page
z> http://wiki.lazarus.freepascal.org/User:Zeljan you can z> find the way how to cheat qt (so maybe there's similar way with gtk2), and z> have own paintings, but LCL doesn't provide eg. OwnerDraw property for z> TCustomEdit, or some result from paint message, where ws should know how to z> paint control (does ws paint , or we cheat it and we made our custom z> painting).

I do not wish to struggle GTK, I wish to do everything in "plain" LCL way, but seems to be not possible. Anyway I'll investigate a bit and get more familiar with GTK way of life.

JoshyFun wrote

I do not wish to struggle GTK, I wish to do everything in "plain" LCL way, but seems to be not possible. Anyway I'll investigate a bit and get more familiar with GTK way of life.

Yes, you need to mess with Gtk to do it. I would however recommend that you try it with Qt instead. The Qt API is much easier to use and the Qt interface is also much better organized. The downside is that you need the Pascal binding library if you use it.

2010/2/5 Felipe Monteiro de Carvalho :

What about licenses using of QT in commercial projects?

Kjow

zeljko wrote

It's because ws paints such control (same like under qt), you can paint on it whatever, but at the end your changes won't be visible since ws theme painter do the job.

OK, I understand the problem now. So background/theme painting is out of LCL's control - another negative point for wrapping external/native toolkits I guess.

find the way how to cheat qt (so maybe there's similar way with gtk2), and have own paintings, but LCL doesn't provide eg. OwnerDraw property for

I can only imagine such "hacks" will inevitably fail somewhere down the line - or is simply not supported by all widgetsets. Is it just my imagination, or is there more and more feature being added to LCL which only works on specific widgetsets (Restricted tab of Object Inspector). This is really not good news for LCL. :-(

Felipe Monteiro de Carvalho wrote

Yes, trying to change the painting of standard controls leads to problems because each widgetset will deal with it differently.

Ah, so you confirmed what I was thinking (in my reply to zeljko). No solution that works on all widgetsets.

The most assured solution to work everywhere is to implement your own TEdit from scratch with just custom painting.

But LCL doesn't want to go that way, because it's custom drawn (a la fpGUI). ;-)

Felipe Monteiro de Carvalho wrote

Yes, you need to mess with Gtk to do it. I would however recommend that you try it with Qt instead.

But that defeats the point of LCL then - not all features work in all widgetsets. So you end up having an application that looks or behaves different depending on widgetset used (Qt, GTK1, GTK2, Win32, Carbon etc.). Consistent cross-platform out the window. :-(

Kjow wrote

What about licenses using of QT in commercial projects?

You need to purchase a commercial license. $2500 US per developer - starting price (if I remember correctly).

Hello Lazarus-List,

Saturday, February 6, 2010, 12:01:38 AM, you wrote:

JoshyFun wrote

> More or less :) Mostly is tell to GTK2 that I'll paint something over > TEdit and please GTK do not erase it :) or I "you" do it let me know > to repaint my own content.

GG> I think you are fighting a 'no win' situation. Theme painting always GG> seems to take priority. Some years ago when I still used LCL I wanted [...]
GG> work up to a point with very limited customization - anything more and GG> you end up having to implement the whole component as custom drawn. GG> Hence fpGUI and MSEgui exist.

Every widgetset has its own pros/cons and most things can be done in all of them. The "problem" with LCL is that it inherits a lot of habits from Windows platforms which is not wrong it is simply a "as is as". GTK2 seems to me (I only know a bit of it) that does not perform a good abstraction between data and data representation, but I could be completly wrong. fpGUI and others are very useful for some tasks and very bad for others. QT seems to ambrace most of both worlds but it requieres a big runtime to be installed and has a poor presence en Windows environments.
From my point of view, the use of native widgets is the best choice but some "advanced" things could be a nightmare :(

GG> So maybe it's time you implement that TJoshyFunEdit component. :-)

Oh! no! for sure no, that's not the intention. My intention was to add a new facility to native TEdit, in fact I only need that facility for Win32 but as it is very simple I'm using it to investigate other widgetsets and try to resolve the same problem in different toys.

Kjow wrote

What about licenses using of QT in commercial projects?

This is a problem if you are using Qt 4.4 or previous.

But now Lazarus uses and requires Qt 4.5+ which is LGPL, the same license as Gtk, which means in short: no problems

Nokia changed the license.

I'm still dreaming of an LCL that also supports widgetsets natively. Please note *also*, not exclusively.

This model would cover an set of general controls, which map to compatible controls of every widgetset. This would make layouts compatible across widgetsets, with a chance to select one of multiple compatible controls for the controls in the general form descriptions (skeletons).

Then distinct GUIs can be created from a form skeleton, for specific widgetsets, where the code of the form interacts with the native controls, with regards to painting, event handling, and whatever is different across multiple widgetsets. Most configuration can be done in the Object Inspector, based on the properties of the concrete (native) controls. An XML or similar description of the form layouts could cover the specific settings of every component in dedicated widgetset sections.

A more general form designer would cover the different layout rules, resulting from according container controls or layout managers. As I already suggested, the TWinControl.DockManager then could be replaced by an LayoutManager hook, with all required methods to configure and resize the child controls of a container control. Then docked controls differ from other controls only in their DragMode property, and the DockSite property only is an alias for Parent. Regardless of how controls are inserted into a container control - by an form designer, in code or by docking - the Dock/LayoutManager of the container handles their placement within the container.

DoDi

It's not proposal for LCL, but hack (or tip) for qt users which need such thing.
It's not supported by all ws, and I'm against adding bunch of features which aren't supported on all widgetsets. This will never be in LCL, but hope that it'll help to some users.

zeljko

it's LGPL. But you can buy commercial version if you want :)

You missed up Felipe's point. He just want to say that qt is better organized and less buggy (just look at bug tracker, and compare number and type of qt bugs vs. gtk2 bugs), but of course with one minus that qt needs C bindings library.
My company live it's life on bussines apps (like yours afaik) and linux is primary target. Sorry, but gtk2 is crap in it's current state for serious bussiness applicaton.
I even come to idea to write gtk2ng from stratch, and organize it in a way qt and carbon are organized.It's an big mess divided into interfaces/gtk & interfaces/gtk2 dir with bunch of ifdef's.

zeljko

No, you not.You're completely wrong. Since qt-4.5 (officially lcl supported version) it's LGPL.

JoshyFun wrote

More or less :) Mostly is tell to GTK2 that I'll paint something over TEdit and please GTK do not erase it :) or I "you" do it let me know to repaint my own content.

Exact example is on my wiki page (but works with qt only :) ).

JoshyFun wrote

Every widgetset has its own pros/cons and most things can be done in all of them.

I can't argue that. :)

The "problem" with LCL is that it inherits a lot of habits from Windows platforms

This is something I have experienced as well, so am glad to see others are noticing the same thing. LCL is meant to be cross-platform, but very often things are implemented base on how Windows works. Sometimes that simply doesn't cut it for the other 5 widgetsets LCL also supports.

My other problem with LCL (and this is a BIG one), is that to implement anything new, you need to be well versed in ALL the widgetsets LCL supports. That is near impossible. With LCL you can't simply add a new feature/property to an existing component in pure LCL code and expect it to work on all platforms. As you experienced, you need to start learning about GTK1, GTK2, Qt, Carbon, Win32 etc., then start fighting the native behaviour of each widgetset etc. And it's not good enough just knowing something about the backend widgetsets, you need to pretty much be an "expert" to get things working. This to me is very counter productive.

Anyway, I'm getting totally off-topic here. Bottom line is, I don't think what you want is possible in all backend widgetsets. This is sad, because the "extra hint" / "inline hint" feature is very handy - I use it often in our company projects showing required fields in a data form etc.

Felipe Monteiro de Carvalho wrote

But now Lazarus uses and requires Qt 4.5+ which is LGPL, the same license as Gtk, which means in short: no problems

What does that mean? Can you now use Qt 4.5+ in commercial software without buying a Qt License? Why then do they still sell licenses? What must you be doing before you require a Qt License?

Note: I'm referring to writing commercial software, not free / open-source software. I already know you can use Qt with open-source software (KDE, Lazarus etc.).

zeljko wrote

and less buggy (just look at bug tracker, and compare number and type of qt bugs vs. gtk2 bugs),

But that could also be explain as follows... not as many people are using the LCL-Qt widgetset compared to the LCL-GTK2 widgetset. :-)

primary target. Sorry, but gtk2 is crap in it's current state for serious business application.

GTK2 on it's own (not LCL-GTK2) is crap too. I simply hate the inconsistent sizes of components, Combobox drop-down behaviour (size and can't limit dropdown count), shitty treeview etc. Sadly though, I'm running Ubuntu with stock standard Gnome desktop. :-( I thought of trying Kubuntu, but I'm just not sure if I like the new KDE though - I'm still very much used to 3.5 (the little bit that I used it).

I'll try Lazarus with LCL-Qt for the next week to see how it goes - I haven't tried LCL-Qt in a while.

well, over 3500 client machines happily runs LCL-Qt apps (our customers), and there's no arguing about anything (was CLX before LCL-Qt). I can confirm that quality of LCL-Qt and lazarus qt is better than K3 at this moment.I've used K3 two months ago for the last time. Now starts D7 Ent. sometimes just to see some component behaviour and compare it to LCL. Goodbye borland,codegear,embarcadero FOREVER.

Feedback is welcome :)

zeljko wrote

> But that could also be explain as follows... not as many people are > using the LCL-Qt widgetset compared to the LCL-GTK2 widgetset. :-) well, over 3500 client machines happily runs LCL-Qt apps

I meant, used by various developers, not a single app deployed to many. Either way, good to hear that your clients are happy. One more plus point to FPC & Lazarus. :)

there's no arguing about anything (was CLX before LCL-Qt). I can confirm that quality of LCL-Qt and lazarus qt is better than K3 at

Kylix 3 was crap from the day it was released. :) The only thing Kylix 3 still does better than Lazarus+FPC is debugging. I am still using log files (like I did in the early 90's) when debugging under FPC+Lazarus - that says a lot. FPC+Lazarus still have a long way to go in this regard, but they have made some nice improvements it the last couple of months.

Goodbye borland,codegear,embarcadero FOREVER.

I've done that 5 years ago, and haven't looked back since. :-)

Ok. Open lcl\interfaces\gtk\gtkcallback.inc search for LM_ERASEBKGND, comment then line:
if (TObject(Target) is TCustomControl)

and recompiler the LCL. Test after that - does this solves your problem?

Best regards,
Paul Ishenin.

2010/2/6 Graeme Geldenhuys :

WOW... really too much for me.
Well, I'll develop with QT only if I'll be a milionaire :(

Kjow

No, Graeme is wrong. Qt is LGPL-ed so you can create commercial apps without buying Qt commercial licenses.

zeljko

2010/2/6 zeljko :

No, Graeme is wrong. Qt is LGPL-ed so you can create commercial apps without buying Qt commercial licenses. zeljko

Oh, well this reevaluates the question. So if I use QT in my Lazarus projects I don't have to pay nothing to Nokia. And what about sources? Do I need to release it?

So, the difference between LGPL and commercial licenses is the official support? ( I found this:
http://qt.nokia.com/products/licensing )

Thanks,
Kjow

zeljko wrote

No, Graeme is wrong. Qt is LGPL-ed so you can create commercial apps without buying Qt commercial licenses.

So when do you need a Qt license then?

See my new message thread "Lazarus IDE + Qt annoyances".

no

So, the difference between LGPL and commercial licenses is the official support? ( I found this: http://qt.nokia.com/products/licensing )

yes

Hello Lazarus-List,

you wrote

> The "problem" with LCL is that it inherits a lot of > habits from Windows platforms

GG> This is something I have experienced as well, so am glad to see others GG> are noticing the same thing. LCL is meant to be cross-platform, but GG> very often things are implemented base on how Windows works. Sometimes GG> that simply doesn't cut it for the other 5 widgetsets LCL also GG> supports.

But that's how LCL is, we can not change it, or better we should not change it.

GG> My other problem with LCL (and this is a BIG one), is that to GG> implement anything new, you need to be well versed in ALL the GG> widgetsets LCL supports. That is near impossible. With LCL you can't

Hmmm, no I think you must have a good know of the widgetset and a good know of LCL and most of us fail in the last one, the know of the LCL. That answers that different widgetsets raises events in different order in example.

I never had serious problems using LCL for regular programs, only in the same troubles as when using Delphi (different problems but with similar roots).

Hello Lazarus-List,

Saturday, February 6, 2010, 10:39:45 AM, you wrote:

PI> Ok. Open lcl\interfaces\gtk\gtkcallback.inc search for LM_ERASEBKGND, PI> comment then line:
PI> if (TObject(Target) is TCustomControl)
PI> and recompiler the LCL. Test after that - does this solves your problem?

I'll check it this night... Thank you.

Hello Lazarus-List,

you wrote

> Oh! no! for sure no, that's not the intention. My intention was to add > a new facility to native TEdit, in fact I only need that facility for > Win32 but as it is very simple I'm using it to investigate other > widgetsets and try to resolve the same problem in different toys.

PI> Ok. Open lcl\interfaces\gtk\gtkcallback.inc search for LM_ERASEBKGND, PI> comment then line:
PI> if (TObject(Target) is TCustomControl)
PI> and recompiler the LCL. Test after that - does this solves your problem?

No "problem" is not solved because:

1) EraseBackground is now invoked, but calling "inherited EraseBackground" does not perform the default erasebackground procedure.

2) Now background is completly gone due (1)

3) WMPaint is invoked but the paint is always performed (whichever result is set in the message) so the inner rect in the TEdit is cleared always.

I think a deeper change in GTK is needed to handle this situation, maybe all controls must be APP_PAINTABLE and call some methods to perform the operations, but I'm not completly sure that it could be done in fact in GTK (following this logic).

Thank you for your time.

No, same thing is with qt. APP_PAINTABLE = HasPaint with qt lcl. This is how it goes:
1.Paint event comes to control.
2.If APP_PAINTABLE then LCL can do the job (usually forms,panels etc) 3.If not - ws paints control with current theme (always after your changes - so any of your changes via painting over such control are lost). So whatever you do in paint event over TEdit, it's painted again by ws. 4.The trick which can be done 1st call control paint from ws, do your changes and say that result of event = true.
In that case we must have the way to tell ws that we want to paint that control (eg. TEdit).

zeljko

Hello Lazarus-List,

you wrote

> I think a deeper change in GTK is needed to handle this situation, > maybe all controls must be APP_PAINTABLE and call some methods to > perform the operations, but I'm not completly sure that it could be > done in fact in GTK (following this logic).

z> No, same thing is with qt. APP_PAINTABLE = HasPaint with qt lcl. z> This is how it goes:
z> 1.Paint event comes to control.
z> 2.If APP_PAINTABLE then LCL can do the job (usually forms,panels etc) z> 3.If not - ws paints control with current theme (always after your changes - z> so any of your changes via painting over such control are lost). z> So whatever you do in paint event over TEdit, it's painted again by ws. z> 4.The trick which can be done 1st call control paint from ws, do your changes z> and say that result of event = true.
z> In that case we must have the way to tell ws that we want to paint that z> control (eg. TEdit).

Well the background border can be "personalized" which is painted by the theme engine, I think, but the inner text rect is always erased, so the problem seems to not be the theme engine (I have a nice textbox without any kind of border).