Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-06

Color setup of the Form1: TForm1

41 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Paul Csanyi

Hello!

System: Debian GNU/Linux Etch.

Lazarus version 0.9.24 beta Date: 5-11-07 SVN Revision: exported i386-linux-gtk.

In a new application created with Lazarus I setup Color for the Form1: TForm1, but in the Form1 Window there the color don't change.

I run the application with F9 but the Color don't change.

Why don't change the Color that was setup in the Object Inspector?

Any advices will be appreciated!

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Graeme Geldenhuys
to Paul Csanyi
Paul Csanyi wrote 13 lines
Hello! System: Debian GNU/Linux Etch. Lazarus version 0.9.24 beta Date: 5-11-07 SVN Revision: exported i386-linux-gtk. In a new application created with Lazarus I setup Color for the Form1: TForm1, but in the Form1 Window there the color don't change. I run the application with F9 but the Color don't change. Why don't change the Color that was setup in the Object Inspector? Any advices will be appreciated!

See the url below. It's what I call a major flaw in LCL. What you (and I a year ago) are trying to do, only works under Windows. On other platforms, such a 'supposed to be simple' feature will not be implemented.

http://wiki.lazarus.freepascal.org/Lazarus_known_issues_%28things_that_will_never_be_fixed%29

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Graeme Geldenhuys
Graeme Geldenhuys wrote
http://wiki.lazarus.freepascal.org/Lazarus_known_issues_%28things_that_will_never_be_fixed%29

Umm, this issues use to be mentioned on that page (I'm pretty sure), but can't see it now. Anyway, here is a thread all about the issue.

http://thread.gmane.org/gmane.comp.ide.lazarus.general/14348

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Vincent Snijders
to Graeme Geldenhuys: See the url below. It's what I call a major flaw in LCL. What you (and I a year ago) are…
Graeme Geldenhuys wrote 16 lines
> In a new application created with Lazarus I setup Color for the Form1: > TForm1, but in the Form1 Window there the color don't change. > > I run the application with F9 but the Color don't change. > Why don't change the Color that was setup in the Object Inspector? > Any advices will be appreciated! See the url below. It's what I call a major flaw in LCL. What you (and I a year ago) are trying to do, only works under Windows. On other platforms, such a 'supposed to be simple' feature will not be implemented. http://wiki.lazarus.freepascal.org/Lazarus_known_issues_%28things_that_will_never_be_fixed%29

I am sorry, but I cannot find the mentioned feature on that page. On what section is it?

All I know is http://bugs.freepascal.org/view.php?id=8197, which is still an open bug.

Vincent

Reply by email

Graeme Geldenhuys
to Vincent Snijders
Vincent Snijders wrote
I am sorry, but I cannot find the mentioned feature on that page. On what section is it?

See my second post. I got confirmation from somebody that it was not native Linux behaviour and was not going to be fixed. And as I mentioned in a previous thread - beats me what 'native Linux behaviour' is! Most Linux apps do what they want as there is NO standard.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Henry Vermaak
to Graeme Geldenhuys

2008/6/17 Graeme Geldenhuys :

Show quoted text 10 lines
On 17/06/2008, Vincent Snijders wrote: > > I am sorry, but I cannot find the mentioned feature on that page. On what section is it? > See my second post. I got confirmation from somebody that it was not native Linux behaviour and was not going to be fixed. And as I mentioned in a previous thread - beats me what 'native Linux behaviour' is! Most Linux apps do what they want as there is NO standard.

the themes in linux control everything about the widgets, that means everything on my desktop looks the same (not in terms of application design, but buttons, scrollbars, borders, colours of active/inactive titlebars, shades, translucency, etc).

if you need a custom look, you either need to build a themeing engine into lazarus, or write a gtkrc file for your app (the right way, imo). then you can control everything. if you just need a colour for your form, doesn't a panel work? (coloured panels work for me in gtk2, at least).

henry

Reply by email

Paul Csanyi
to Henry Vermaak
"Henry Vermaak" wrote 22 lines
2008/6/17 Graeme Geldenhuys : > On 17/06/2008, Vincent Snijders wrote: >> >> I am sorry, but I cannot find the mentioned feature on that page. On what section is it? >> > > See my second post. I got confirmation from somebody that it was not > native Linux behaviour and was not going to be fixed. And as I > mentioned in a previous thread - beats me what 'native Linux > behaviour' is! Most Linux apps do what they want as there is NO > standard. the themes in linux control everything about the widgets, that means everything on my desktop looks the same (not in terms of application design, but buttons, scrollbars, borders, colours of active/inactive titlebars, shades, translucency, etc). if you need a custom look, you either need to build a themeing engine into lazarus, or write a gtkrc file for your app (the right way, imo). then you can control everything. if you just need a colour for your form, doesn't a panel work? (coloured panels work for me in gtk2, at least).

I read now the GTK Tutorial at:
http://www.gtk.org/tutorial1.2/gtk_tut-21.html

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Kostas Michalopoulos
to Henry Vermaak: 2008/6/17 Graeme Geldenhuys : the themes in linux control everything about the widgets,…
Show quoted text 10 lines
the themes in linux control everything about the widgets, that means everything on my desktop looks the same (not in terms of application design, but buttons, scrollbars, borders, colours of active/inactive titlebars, shades, translucency, etc). if you need a custom look, you either need to build a themeing engine into lazarus, or write a gtkrc file for your app (the right way, imo). then you can control everything. if you just need a colour for your form, doesn't a panel work? (coloured panels work for me in gtk2, at least).

First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which have their own theming stuff. However X11, the windowing system that is mostly used in Linux and other UNIX environments (which is *NOT* even guarranteed that it will be the one used - i've seen some other UIs which use the framebuffer directly) does not dictate a specific window look or behavior. While GTK+ came to be a well known and widely used toolkit (which is something that can be said about Qt too), it doesn't make it "the way Linux looks like".

While you can restrain yourself to not use anything non-GTK, if you open a non-GTK program (like a Qt program, a FLTK program, a Motif/Lesstif program, a Tcl/Tk program, etc) it will not look the same as the rest. This is because there is no universally acceptable theme engine that applies to all toolkits. I'm not going to argue if this is good or bad, but thats the fact.

Secondly, even if there was a "Linux theme engine", the same applies to Windows programs. Windows in fact *have* a theme engine and even since Windows 3.0 (i think) you were able to change the current theme to something else. However as i see, the Win32 backend allows you to change colors, while GTK+ does not. While i can accept that doing such a thing in GTK+ is a very low priority (which would imply, however, that GTK+ is not finished and if 1.0 has to have GTK+ 1.2 finished then it has to provide this functionality too), i find the answer of not doing it because the theme engine dictates look as a cheap excuse (because otherwise if you really believe this, then rip off the code that changes colors in Win32 from LCL too - there is a theme engine there much older and widely used than GTK+'s).

And third, what you propose here is a platform-specific solution. Lazarus is supposed to be "write once, compile everywhere" not "write once (while praying that your code will work in other interface), compile everywhere (to find bugs and missing features in other interfaces and platforms)". In the very worst case (which is a hack) Lazarus should create the gtkrc file transparently from the user/programmer.

Of course i think the best solution for all these problems would be a crossplatform toolkit that sits below LCL and has a constant behavior no matter what the system is. fpGUI seems to be such a kit, but setting Lazarus to compile with this toolkit is failing due to some missing unit.

Kostas

Reply by email

Henry Vermaak
to Henry Vermaak: 2008/6/17 Paul Csanyi : this is a good place to get info:…

2008/6/17 Henry Vermaak :

Show quoted text 12 lines
2008/6/17 Paul Csanyi : > > I read now the GTK Tutorial at: > http://www.gtk.org/tutorial1.2/gtk_tut-21.html > this is a good place to get info: http://developer.gnome.org/arch/gtk/themes.html with the section "Resource Files" most relevant to you.

or you can try this patch (can a lazarus dev please review?).

the result: http://imagebin.org/21183

henry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtk2-colour.patch
Type: text/x-patch
Size: 1320 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080617/c187073c/attachment.bin

Reply by email

Henry Vermaak
to Kostas Michalopoulos: First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which…

2008/6/17 Kostas Michalopoulos :

Show quoted text 12 lines
> the themes in linux control everything about the widgets, that means > everything on my desktop looks the same (not in terms of application > design, but buttons, scrollbars, borders, colours of active/inactive > titlebars, shades, translucency, etc). > > if you need a custom look, you either need to build a themeing engine > into lazarus, or write a gtkrc file for your app (the right way, imo). > then you can control everything. if you just need a colour for your > form, doesn't a panel work? (coloured panels work for me in gtk2, at > least). First of all, Linux is not GTK+. There are other toolkits around, like Qt

my mistake, please replace linux with gtk2 in my first sentence.

--8<--

Show quoted text 6 lines
Secondly, even if there was a "Linux theme engine", the same applies to Windows programs. Windows in fact *have* a theme engine and even since Windows 3.0 (i think) you were able to change the current theme to something else. However as i see, the Win32 backend allows you to change colors, while GTK+ does not. While i can accept that doing such a thing in GTK+ is a very

that's incorrect. gtk does allow you to change colours, please see http://ometer.com/gtk-colors.html.

--8<--
--8<--
--8<--

lazarus tries to follow the native behaviour of the widget set used, which makes it look like most other apps written for the same widget set. customising everything is a bonus and takes a lot of effort to implement.

i guess in time all these nice things will be implemented (and a lot of them are already). this will happen a lot quicker if we can all jump in and help instead of whining on about it.

Show quoted text 5 lines
Of course i think the best solution for all these problems would be a crossplatform toolkit that sits below LCL and has a constant behavior no matter what the system is. fpGUI seems to be such a kit, but setting Lazarus to compile with this toolkit is failing due to some missing unit.

that's because fpgui isn't that well integrated with lcl, let. people are working on this, afaik. maybe graham can comment.

henry

Reply by email

Mattias Gaertner
to Graeme Geldenhuys: See the url below. It's what I call a major flaw in LCL. What you (and I a year ago) are…
Show quoted text 22 lines
On 17/06/2008, Paul Csanyi wrote: > Hello! > > System: Debian GNU/Linux Etch. > > Lazarus version 0.9.24 beta Date: 5-11-07 SVN Revision: exported > i386-linux-gtk. > > In a new application created with Lazarus I setup Color for the > Form1: TForm1, but in the Form1 Window there the color don't change. > > I run the application with F9 but the Color don't change. > Why don't change the Color that was setup in the Object Inspector? > Any advices will be appreciated! See the url below. It's what I call a major flaw in LCL. What you (and I a year ago) are trying to do, only works under Windows. On other platforms, such a 'supposed to be simple' feature will not be implemented. http://wiki.lazarus.freepascal.org/Lazarus_known_issues_%28things_that_will_never_be_fixed%29

I don't see TForm.Color on that page, only TButton.Color and TBitBtn.Color. And for good reason.

Fact is that TForm.Color is difficult to implement. For example there were at least 3 tries for the gtk interface, none worked good. The fourth try comes today - we will see.

And it's true that many developers think, that TForm.Color should be avoided in almost all cases for one reason or the other and therefore implementing TForm.Color has low priority.

But afaik no one said, that it will never or should not be implemented (except for some people on the gtk lists).

Mattias

Reply by email

Vincent Snijders
to Kostas Michalopoulos: First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which…
Kostas Michalopoulos wrote 39 lines
First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which have their own theming stuff. However X11, the windowing system that is mostly used in Linux and other UNIX environments (which is *NOT* even guarranteed that it will be the one used - i've seen some other UIs which use the framebuffer directly) does not dictate a specific window look or behavior. While GTK+ came to be a well known and widely used toolkit (which is something that can be said about Qt too), it doesn't make it "the way Linux looks like". While you can restrain yourself to not use anything non-GTK, if you open a non-GTK program (like a Qt program, a FLTK program, a Motif/Lesstif program, a Tcl/Tk program, etc) it will not look the same as the rest. This is because there is no universally acceptable theme engine that applies to all toolkits. I'm not going to argue if this is good or bad, but thats the fact. Secondly, even if there was a "Linux theme engine", the same applies to Windows programs. Windows in fact *have* a theme engine and even since Windows 3.0 (i think) you were able to change the current theme to something else. However as i see, the Win32 backend allows you to change colors, while GTK+ does not. While i can accept that doing such a thing in GTK+ is a very low priority (which would imply, however, that GTK+ is not finished and if 1.0 has to have GTK+ 1.2 finished then it has to provide this functionality too), i find the answer of not doing it because the theme engine dictates look as a cheap excuse (because otherwise if you really believe this, then rip off the code that changes colors in Win32 from LCL too - there is a theme engine there much older and widely used than GTK+'s). And third, what you propose here is a platform-specific solution. Lazarus is supposed to be "write once, compile everywhere" not "write once (while praying that your code will work in other interface), compile everywhere (to find bugs and missing features in other interfaces and platforms)". In the very worst case (which is a hack) Lazarus should create the gtkrc file transparently from the user/programmer. Of course i think the best solution for all these problems would be a crossplatform toolkit that sits below LCL and has a constant behavior no matter what the system is. fpGUI seems to be such a kit, but setting Lazarus to compile with this toolkit is failing due to some missing unit.

Seems like a good idea. Although I have no right of speaking, I am just focussing on the win32 widget set, the major thing missing seems to be patches to implement all this, please send them.

Vincent

Reply by email

Paul Csanyi
to Henry Vermaak: 2008/6/17 Henry Vermaak : err, it seems to work already for gtk2, so please ignore this...
"Henry Vermaak" wrote 6 lines
2008/6/17 Henry Vermaak : > > or you can try this patch (can a lazarus dev please review?). > err, it seems to work already for gtk2, so please ignore this...

OK so I can to change Form1 Color when I setup in the Compiler Options the LCL Widget Type to 'gtk 2' for a project?

I setup this but still can't to change Form1 Color in Object Inspector.

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Henry Vermaak
to Paul Csanyi

2008/6/17 Paul Csanyi :

Show quoted text 7 lines
OK so I can to change Form1 Color when I setup in the Compiler Options the LCL Widget Type to 'gtk 2' for a project? I setup this but still can't to change Form1 Color in Object Inspector.

you'll have to recompile your lazarus (or at least lcl) for gtk2.

make clean all LCL_PLATFORM=gtk2

will give you a full gtk2 lazarus. you might have to install some of the gtk devel libs.

see: http://wiki.lazarus.freepascal.org/GTK2_Interface

henry

Reply by email

Paul Csanyi
to Henry Vermaak
"Henry Vermaak" wrote 17 lines
2008/6/17 Paul Csanyi : > > OK so I can to change Form1 Color when I setup in the Compiler Options > the LCL Widget Type to 'gtk 2' for a project? > > I setup this but still can't to change Form1 Color in Object > Inspector. > you'll have to recompile your lazarus (or at least lcl) for gtk2. make clean all LCL_PLATFORM=gtk2 will give you a full gtk2 lazarus. you might have to install some of the gtk devel libs. see: http://wiki.lazarus.freepascal.org/GTK2_Interface

I follow this howto and have recompiled LCL for GTK2.

I have installed libgtk2.0-dev.

The Lazarus restarted after Recompilation.

Still I can't to change Form1 Color. Why?

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Henry Vermaak
to Paul Csanyi

2008/6/17 Paul Csanyi :

Show quoted text 9 lines
I follow this howto and have recompiled LCL for GTK2. I have installed libgtk2.0-dev. The Lazarus restarted after Recompilation. Still I can't to change Form1 Color. Why?

maybe you haven't compiled your app for gtk2 widgetset? works here...

henry

Reply by email

Paul Csanyi
to Henry Vermaak
"Henry Vermaak" wrote 12 lines
2008/6/17 Paul Csanyi : > > I follow this howto and have recompiled LCL for GTK2. > > I have installed libgtk2.0-dev. > > The Lazarus restarted after Recompilation. > > Still I can't to change Form1 Color. Why? > maybe you haven't compiled your app for gtk2 widgetset? works here...

But yes, I setup in the 'Compiler Options' the LCL Widget Type to gtk2.

I tested the Compiler Options, here are the outputs:

Test:

/usr/bin/ppc386 -S2cgi -OG1 -TLinux -Pi386 -gl -WG -va -l \ -Fu../lcl/units/i386-linux/ -Fu../lcl/units/i386-linux/gtk2/ \ -Fu../packager/units/i386-linux/ -Fu. -dLCL -dLCLgtk2 \ /tmp/testcompileroptions.pas

Results:

WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.0/httpd.ppu, /usr/lib/fpc/2.2.0/units/i386-linux/httpd-1.3/httpd.ppu WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.2/apr.ppu, /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.0/apr.ppu WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.2/apriconv.ppu, /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.0/apriconv.ppu WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.2/aprutil.ppu, /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.0/aprutil.ppu WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.2/httpd.ppu, /usr/lib/fpc/2.2.0/units/i386-linux/httpd-2.0/httpd.ppu WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/fv/dialogs.ppu, /usr/share/lazarus/lcl/units/i386-linux/dialogs.ppu WARNING: ppu exists twice: /usr/lib/fpc/2.2.0/units/i386-linux/fv/menus.ppu, /usr/share/lazarus/lcl/units/i386-linux/menus.ppu

Any advices?

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Paul Csanyi
to Paul Csanyi
Paul Csanyi wrote 17 lines
"Henry Vermaak" writes: > 2008/6/17 Paul Csanyi : >> >> I follow this howto and have recompiled LCL for GTK2. >> >> I have installed libgtk2.0-dev. >> >> The Lazarus restarted after Recompilation. >> >> Still I can't to change Form1 Color. Why? >> > > maybe you haven't compiled your app for gtk2 widgetset? works here... But yes, I setup in the 'Compiler Options' the LCL Widget Type to gtk2.

OK I tried with lazarus that I downloaded with SVN, and it works here too.

Only don't works with lazarus installed with aptitude from debian package.

Thank you all for the help! :)

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Felipe Monteiro de Carvalho
to Kostas Michalopoulos: First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which…
Answering to all the comments from Kostas Michalopoulos

The greatest problem is that we don't have a perfect toolkit under Linux to be based on. Because Lazarus is cross-platform we could allow ourselves to go into a multiply choice solution. gtk1, gtk2, qt and fpgui are implemented at different levels.

Qt is commercial for non-GPL software and fpgui is only maturing today, so the only existing solution that could be implemented in the last years was gtk, and that brings a huge amount of flaws from the Gtk APIs and their problems and bugs.

About having a fixed looks solution, it was discussed and the solution is to use another widgetset that implements it under LCL, which could be fpgui and the lcl-fpgui projects.

But, because we are in a open source world here, just coming to the mailling list and saying that you think way X is excelent and people should implement it has absolutely no value. If you think way X is very good, then send patches implementing it!!!

or in more concrete terms:

Of course i think the best solution for all these problems would be a crossplatform toolkit that sits below LCL and has a constant behavior no matter what the system is. fpGUI seems to be such a kit, but setting Lazarus to compile with this toolkit is failing due to some missing unit.

Then why don't you send a patch that fixes the compilation? Supposing you have actually read the instructions on the wiki and you have set it up correctly.

Felipe Monteiro de Carvalho

Reply by email

Kostas Michalopoulos
to Felipe Monteiro de Carvalho
But, because we are in a open source world here, just coming to the mailling list and saying that you think way X is excelent and people should implement it has absolutely no value. If you think way X is very good, then send patches implementing it!!!

I'm expressing my opinion about a topic that was under discussion. When i was sure that something was good and it wouldn't be wasted time for me to code them (as was the case with other opensource project to which i contributed at the past), i wrote and submitted a few patches to Lazarus. However in this case not everyone seems to think the same about overriding the theme, so i said my opinion. Writing a patch that does what i'm talking about and having it rejected because i haven't stated why i think this is a good idea (this applies to most things, not just this particular issue) is not something i like to do.

Discussing is a good thing.

Show quoted text 9 lines
> Of course i think the best solution for all these problems would be a > crossplatform toolkit that sits below LCL and has a constant behavior no > matter what the system is. fpGUI seems to be such a kit, but setting > Lazarus > to compile with this toolkit is failing due to some missing unit. Then why don't you send a patch that fixes the compilation? Supposing you have actually read the instructions on the wiki and you have set it up correctly.

I didn't tried that much, that was only a small comment not a complaint about fpGUI. I was just curious to see if it works, the only thing i did was to make a form with a button, set the target interface to fpGUI and try to compile it. What i wrote above could end with "...so i haven't really checked it out to be sure that it really is".

Kostas

Reply by email

Paul Csanyi
to Henry Vermaak: 2008/6/17 Graeme Geldenhuys : the themes in linux control everything about the widgets,…
"Henry Vermaak" wrote 24 lines
2008/6/17 Graeme Geldenhuys : > On 17/06/2008, Vincent Snijders wrote: >> >> I am sorry, but I cannot find the mentioned feature on that page. On what section is it? >> > > See my second post. I got confirmation from somebody that it was not > native Linux behaviour and was not going to be fixed. And as I > mentioned in a previous thread - beats me what 'native Linux > behaviour' is! Most Linux apps do what they want as there is NO > standard. the themes in linux control everything about the widgets, that means everything on my desktop looks the same (not in terms of application design, but buttons, scrollbars, borders, colours of active/inactive titlebars, shades, translucency, etc). if you need a custom look, you either need to build a themeing engine into lazarus, or write a gtkrc file for your app (the right way, imo). then you can control everything. if you just need a colour for your form, doesn't a panel work? (coloured panels work for me in gtk2, at least). henry

I think that that for my Form a coloured panel works just fine! :)

Regards, Paul Csanyi http://www.freewebs.com/csanyi-pal/index.htm

Reply by email

Graeme Geldenhuys
to Henry Vermaak: 2008/6/17 Graeme Geldenhuys : the themes in linux control everything about the widgets,…

2008/6/17 Henry Vermaak :

Show quoted text 5 lines
the themes in linux control everything about the widgets, that means everything on my desktop looks the same (not in terms of application design, but buttons, scrollbars, borders, colours of active/inactive titlebars, shades, translucency, etc).

The X Toolkit does not adhere to the GTK or Qt themes. Neither does FVWM window manager applications or many others for that matter. eg: Run 'xfontsel' or 'xmag' or 'xcalc' or the well know font creation tool 'fontforge'. They look nothing like GTK or Qt.

Show quoted text 5 lines
if you need a custom look, you either need to build a themeing engine into lazarus, or write a gtkrc file for your app (the right way, imo). then you can control everything. if you just need a colour for your form, doesn't a panel work? (coloured panels work for me in gtk2, at least).

Why must I create a complete theme engine simple to customize the look of my application. Applications like WinAmp Windows Media Player or even the little application called Microsoft Office create there own looks without adhering to the current window managers themes. I (and a few others) simply tried to do the same, but the LCL under Linux doesn't allow for that.

eg: One of our products are designed for kids, so it has bigger buttons, colorful display etc... That worked fine under Delphi and Windows, but we can't port that to Linux using the LCL.

Form Validation Feedback is another use of non-standard look. We often change the color of a EditBox or some other control if the user entered incorrect or missing required information. At one point this was also not possible under Linux with LCL.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Kostas Michalopoulos: First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which…

2008/6/17 Kostas Michalopoulos :

Show quoted text 5 lines
First of all, Linux is not GTK+. There are other toolkits around, like Qt and FLTK which have their own theming stuff. However X11, the windowing system that is mostly used in Linux and other UNIX environments (which is *NOT* even guarranteed that it will be the one used - i've seen some other

I can't agree more! :)

Show quoted text 11 lines
Secondly, even if there was a "Linux theme engine", the same applies to Windows programs. Windows in fact *have* a theme engine and even since Windows 3.0 (i think) you were able to change the current theme to something else. However as i see, the Win32 backend allows you to change colors, while GTK+ does not. While i can accept that doing such a thing in GTK+ is a very low priority (which would imply, however, that GTK+ is not finished and if 1.0 has to have GTK+ 1.2 finished then it has to provide this functionality too), i find the answer of not doing it because the theme engine dictates look as a cheap excuse (because otherwise if you really believe this, then rip off the code that changes colors in Win32 from LCL too - there is a theme engine there much older and widely used than GTK+'s).

Spot on! It seems to me that Win32 is the primary toolkit being used to design LCL (hence all the winapi fake methods in each widget set). For LCL to ever reach v1, all primary widget sets should support the same functionality. If not, remove it from the LCL.

Of course i think the best solution for all these problems would be a crossplatform toolkit that sits below LCL and has a constant behavior no matter what the system is. fpGUI seems to be such a kit, but setting Lazarus to compile with this toolkit is failing due to some missing unit.

Hence the reason I develop fpGUI. The LCL-fpGUI widget set is not actively being developed due to fpGUI still growing. But yes, I think this will be the ideal solution for Lazarus. If the Lazarus developers took this route from the start (create their own custom drawn toolkit), I think they would have 70% less bug reports compared to now and Lazarus would long ago have reached v1 status. But again, that is the benefit of hindsight and it was their design choice at the time and I'm not going to argue that now. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho: The greatest problem is that we don't have a perfect toolkit under Linux to be based on.…

2008/6/17 Felipe Monteiro de Carvalho :

But, because we are in a open source world here, just coming to the mailling list and saying that you think way X is excelent and people should implement it has absolutely no value. If you think way X is very good, then send patches implementing it!!!

I agree fully. :)

Show quoted text 6 lines
> matter what the system is. fpGUI seems to be such a kit, but setting Lazarus > to compile with this toolkit is failing due to some missing unit. Then why don't you send a patch that fixes the compilation? Supposing you have actually read the instructions on the wiki and you have set it up correctly.

It seems I need to try and split my time between improving fpGUI itself and starting work on LCL-fpGUI. Why, oh why is there only 24 hours in a day!?!?! :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Kostas Michalopoulos: I'm expressing my opinion about a topic that was under discussion. When i was sure that…

2008/6/18 Kostas Michalopoulos :

Show quoted text 6 lines
I didn't tried that much, that was only a small comment not a complaint about fpGUI. I was just curious to see if it works, the only thing i did was to make a form with a button, set the target interface to fpGUI and try to compile it. What i wrote above could end with "...so i haven't really checked it out to be sure that it really is".

As far as I know (I haven't tried LCL-fpGUI in a while), the LCL-fpGUI widget set is still unusable. The last time I checked the code that was there, was simply to see how difficult it would be to integrate fpGUI and LCL. Like someone famous said: "Stay tuned..."

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Henry Vermaak
to Graeme Geldenhuys: 2008/6/17 Henry Vermaak : The X Toolkit does not adhere to the GTK or Qt themes. Neither…

2008/6/18 Graeme Geldenhuys :

Show quoted text 7 lines
Why must I create a complete theme engine simple to customize the look of my application. Applications like WinAmp Windows Media Player or even the little application called Microsoft Office create there own looks without adhering to the current window managers themes. I (and a few others) simply tried to do the same, but the LCL under Linux doesn't allow for that.

well it does now (as far as i can see). the only thing that's not working is the form colour, which is a gtk limitation, i think (and i won't blame gtk if they dont fix it, since gtk1 isn't really used much). and all of this works in gtk2. all i'm trying to say is that even if the lcl hasn't implemented it, you can always do this in code with the gtk_widget_modify_style function (for example), and there's an even easier way with gtk2, where it takes only one line. i don't even see the relevance of this discussion any more.

henry

Reply by email

Graeme Geldenhuys
to Mattias Gärtner

2008/6/18 Mattias G?rtner :

> For LCL to ever reach v1, all primary widget sets should support the > same functionality. If not, remove it from the LCL. Define 'same functionality'.

OK, lets use the example of this thread. If you have a Form.Color property working in Win32, that same functionality should work for all 'official' widget sets, before Lazarus can reach v1 status. Consistency is key!

What's the point in having a property available in a widgetset when it does nothing. That's kind of my point.

Show quoted text 5 lines
> took this route from the start (create their own custom drawn > toolkit), I think they would have 70% less bug reports compared to now > and Lazarus would long ago have reached v1 status. I doubt that.

I scan through all the mantis bug reports as they land in my inbox. A hell of a lot of them are regression bugs. Implement something new (new event due to a message or something) for a specific widget set (eg: Treeview under Win32), and it breaks the treeview under other widget sets. Or the behaviour (features) of the Treeview is now out of sync between all supported widget sets. Such errors/issues do not occur in fpGUI because there is only one set of GUI components and a platform neutral messaging system - all platforms use the same component code. Implement something under Linux and it's available under Windows too.

As for how components look... I spent a lot of time testing canvas painting routines in fpGUI. The canvas painting routines are now identical (to the pixel) under Windows and Linux. I can now develop a new component 100% under Linux and have the knowledge and trust that it works and looks identical under Windows. And yes I know the old argument of "Look and Feel", but trust me, users are not that fussy (Windows Media Player, MS Office etc..). It's very easy to fool 90% of the users out there in thinking it's native!

All I'm saying is that it's *much* easier to maintain a single set of components, than trying to make all different toolkits from various vendors act the same. You guys have done a great job trying, but it's been a huge battle and a lot of time to get there. Time I think could have been better spent on something else if LCL was based on it's own custom drawn toolkit.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Felipe Monteiro de Carvalho
to Graeme Geldenhuys

Native toolkits versus custom drawing was already extensively discussed, a consensus was reached and there is little reason to further discuss that.

LCL is flexible enougth to have both solutions, so there is no reason that one excludes the other. Those that beliave that gtk is the way to go on linux can implement lcl-gtk. Those that think differently can implement our custom drawn toolkit, which is lcl-fpgui (with the drawing tercerized to Graeme =) ).

My advice for supporters of custom drawing: Send patches to implement lcl-fpgui =)

bye,

Felipe Monteiro de Carvalho

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho

2008/6/18 Felipe Monteiro de Carvalho :

Native toolkits versus custom drawing was already extensively discussed, a consensus was reached and there is little reason to further discuss that.

I agree...

My advice for supporters of custom drawing: Send patches to implement lcl-fpgui =)

I agree! :-)
Maybe we should arrange a toolkit implementation marathon (something like Firefox Download Day). Lets see how much of LCL-fpGUI we can implement in a weekend. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Felipe Monteiro de Carvalho
to Graeme Geldenhuys
Graeme Geldenhuys wrote
I agree! :-) Maybe we should arrange a toolkit implementation marathon (something like Firefox Download Day). Lets see how much of LCL-fpGUI we can implement in a weekend. ;-)

Well, I don't have time in the next 2 months, but it can be done in a assynchronous way =)

You do as much as you can in the weekend that you have free, and I do the same when I have time =P

Maybe Kostas would also like to join?

Felipe Monteiro de Carvalho

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho

2008/6/18 Felipe Monteiro de Carvalho :

You do as much as you can in the weekend that you have free, and I do the same when I have time =P

Now I just need to find out when the wife has a 'ladies weekend' again. :-) If not, the WAF percentage is going to be very low!

ps:
WAF = Wife Acceptance Factor
http://en.wikipedia.org/wiki/Woman_acceptance_factor

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Mattias Gaertner
to Graeme Geldenhuys: 2008/6/18 Mattias G?rtner : OK, lets use the example of this thread. If you have a…
Show quoted text 13 lines
2008/6/18 Mattias G?rtner : >> For LCL to ever reach v1, all primary widget sets should support >> the same functionality. If not, remove it from the LCL. > > Define 'same functionality'. OK, lets use the example of this thread. If you have a Form.Color property working in Win32, that same functionality should work for all 'official' widget sets, before Lazarus can reach v1 status. Consistency is key! What's the point in having a property available in a widgetset when it does nothing. That's kind of my point.

The program does not crash.

The problem of the widgetset specific properties is known. A first step is the 'restricted' page in the object inspector.

A second step is document all widgetset specifics.

For the v1 I agree, that we need to IFDEF some features.

Show quoted text 17 lines
>> took this route from the start (create their own custom drawn >> toolkit), I think they would have 70% less bug reports compared to >> now and Lazarus would long ago have reached v1 status. > > I doubt that. I scan through all the mantis bug reports as they land in my inbox. A hell of a lot of them are regression bugs. Implement something new (new event due to a message or something) for a specific widget set (eg: Treeview under Win32), and it breaks the treeview under other widget sets. Or the behaviour (features) of the Treeview is now out of sync between all supported widget sets. Such errors/issues do not occur in fpGUI because there is only one set of GUI components and a platform neutral messaging system - all platforms use the same component code. Implement something under Linux and it's available under Windows too.

True.
But:
- is it VCL compatible?
- What about file dialogs, icons, clipboard, sub pixel rendering, unicode support, accessibility features, all that stuff that gtk/qt/carbon has already implemented and more important: is maintaining?

Show quoted text 8 lines
As for how components look... I spent a lot of time testing canvas painting routines in fpGUI. The canvas painting routines are now identical (to the pixel) under Windows and Linux. I can now develop a new component 100% under Linux and have the knowledge and trust that it works and looks identical under Windows. And yes I know the old argument of "Look and Feel", but trust me, users are not that fussy (Windows Media Player, MS Office etc..). It's very easy to fool 90% of the users out there in thinking it's native!

Does that mean fpgui's theme engine is finally good enough to create native looking apps?

Show quoted text 6 lines
All I'm saying is that it's *much* easier to maintain a single set of components, than trying to make all different toolkits from various vendors act the same. You guys have done a great job trying, but it's been a huge battle and a lot of time to get there. Time I think could have been better spent on something else if LCL was based on it's own custom drawn toolkit.

Have you ever wondered, why lazarus has more than 3 widgetsets? Technically windows/gtk/carbon would be enough for Windows, WinCE, linux, BSD and OS X. Apparently people don't like the same look&feel. They like a native look so much, that they spent quite a lot of time into specializing instead of working on the base set.

Mattias

Reply by email

Graeme Geldenhuys
to Mattias Gaertner

2008/6/20 Mattias Gaertner :

But: - is it VCL compatible?

fpGUI was not designed be VCL compatible, but it is close in some place. I don't mean for Lazarus to use fpGUI. I meant if the Lazarus developers used a custom written toolkit from the beginning it could very easily been designed to be VCL compatible.

- What about file dialogs, icons, clipboard, sub pixel rendering, unicode support, accessibility features, all that stuff that

dialogs - done
clipboard - 80% done
sub pixel rending - done where needed, but not optimized for speed yet. unicode support - done, it uses UTF8 for all text and supports locale dependant file system access.

gtk/qt/carbon has already implemented and more important: is maintaining?

The initial code was the hard part, but maintaining and improving is much easier. Lazarus is not immune to maintenance. LCL needs to be maintained as well because GTK2, Qt, Cocoa and Win32 continuesly evolves. LCL plays catch-up way more than fpGUI ever will.

Does that mean fpgui's theme engine is finally good enough to create native looking apps?

The implementation is not 100% complete yet, but most of the design work is done. I already did some performance tests. If the theme is complex with many 50+ components, performance starts degrading, but that's purely down to one function Canvas.StretchDraw that hasn't been optimized yet. I'm also busy working on improving the amount of refreshes required.

linux, BSD and OS X. Apparently people don't like the same look&feel. They like a native look so much, that they spent quite a lot of time into specializing instead of working on the base set.

Like I said, it's fairly easy to fool 90% of the people out there and many high profile applications like MS Office, Windows Media Player don't adhere to the OS look & feel and nobody complains about them! A custom toolkit can be design to fake the native look depending on which platform it runs under. Qt is a case in point.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Felipe Monteiro de Carvalho
to Graeme Geldenhuys
Show quoted text 5 lines
Like I said, it's fairly easy to fool 90% of the people out there and many high profile applications like MS Office, Windows Media Player don't adhere to the OS look & feel and nobody complains about them! A custom toolkit can be design to fake the native look depending on which platform it runs under. Qt is a case in point.

Honestly I think that Windows Media Player and MS Office look crap, and their wierd looks just confuse me and make their use problematic.

But there do is a point here. If Microsoft openly ignores all their GUI guidelines, why should we follow them?

But not everything is Windows. When you go to Mac OS X you will see that you will sudenly need native menus, immitating the native look will get much harder, and custormers will actually pay attention to it.

Under Windows CE you also need native menus, which are very hard to implement. Here I can see some advantages of non-native looks. Some native controls under Windows CE look crap. TPageControl has almost no border ...

Under Linux there is no guideline at all, so that's the best place for fpgui.

Further, there is one advantage of native gui: accessibility. The user changes it's Windows settings and all software adjusts to it, colors change, fonts get bigger, etc. Does fpgui respect that?

thanks,

Felipe Monteiro de Carvalho

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho

2008/6/21 Felipe Monteiro de Carvalho :

Honestly I think that Windows Media Player and MS Office look crap, and their wierd looks just confuse me and make their use problematic.

I agree on both counts. :) Though it was just an example, not what I'm striving for. ;)

But there do is a point here. If Microsoft openly ignores all their GUI guidelines, why should we follow them?

Go figure that! Breaking there own rules. I wonder if those products ever received Windows certification. :)

But not everything is Windows. When you go to Mac OS X you will see that you will sudenly need native menus, immitating the native look will get much harder, and custormers will actually pay attention to it.

Mac's are probably the most difficult of all. From what I have read, the users have a very high standard to what applications must look like. Apple also seems to adhere to it's own GUI guidelines as the apps I've seen all look and behave similar.

I never said imitating a native look is going to be easy, but it is possible (Qt is again a case in point). Mac is probably the worst example I can use, but as far as I know Pixel 32 (image editor) fakes all it's native looks as well, and although not 100% accurate (even the WinXP look), the users seems happy enough.

Further, there is one advantage of native gui: accessibility. The user changes it's Windows settings and all software adjusts to it, colors change, fonts get bigger, etc. Does fpgui respect that?

Relatively easy to accomplish. I've already done some trials with fpGUI under Windows. Detecting when system fonts or colours change and adapts to that. I know accessibility is not only fonts and colour, but each OS seems to send out some signals or messages when something important changed so other applications can detect it. fpGUI's corelib could easily hook into those events as well.

Anyway, I know at the time Lazarus was started, there was no working fpGUI and at that point the core Lazarus developers decided native widgets was the way to go. I'm not saying Lazarus should change now, it will be a huge task. The original Lazarus design goal and my current design goals are different - I have no problem with that. Plus I have no intension or interest in creating yet another IDE. Lazarus with fpGUI suites my needs well. Also like you said, LCL seems flexible enough so eventually fpGUI could be integrated with LCL which should solve a few problems and overcome some limitations of the other widget sets.

In the mean time, I just continue improving fpGUI. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email