Discussion:
setColor part 3
darekm
2006-02-28 18:16:10 UTC
Permalink
Hi
I continue my investigation with widgets color
now i prepare patch for
tSpeedButton
tEdit
tListBox

all for GTK1


Darek

PS. For A.I. Vender
maybe now tEdit change the color.
If not I'll try, but first i must install GTK2
Micha Nelissen
2006-02-28 18:19:15 UTC
Permalink
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?

Micha
darekm
2006-02-28 19:37:14 UTC
Permalink
Post by Micha Nelissen
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms

DrawFrameControl need styles (and this need time to prepare, and trouble
with different widgetsset)


Darek

ps.sorry for my English,
Post by Micha Nelissen
Micha
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Mattias Gaertner
2006-03-01 01:50:57 UTC
Permalink
On Tue, 28 Feb 2006 20:37:14 +0100
Post by darekm
Post by Micha Nelissen
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms
The buttons look should follow the users theme. They should not look the
same on all platforms.
With Frame3D we loose the theme background of buttons. I commented this out
and kept the old DrawFrameControl.
Post by darekm
DrawFrameControl need styles (and this need time to prepare, and trouble
with different widgetsset)
What trouble?

I applied the rest. gtk2 seems to work better now.


Mattias
darekM
2006-03-01 07:41:57 UTC
Permalink
Post by Mattias Gaertner
On Tue, 28 Feb 2006 20:37:14 +0100
Post by darekm
Post by Micha Nelissen
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms
The buttons look should follow the users theme. They should not look the
same on all platforms.
With Frame3D we loose the theme background of buttons. I commented this out
and kept the old DrawFrameControl.
Under tSpeedButton is no background (as I know), all is painting
I have similar problem with tPanel and tHeader, but i will investigate
in next time
Post by Mattias Gaertner
I applied the rest. gtk2 seems to work better now.
thx

Darek
Mattias Gaertner
2006-03-01 09:47:50 UTC
Permalink
On Wed, 01 Mar 2006 08:41:57 +0100
Post by darekM
Post by Mattias Gaertner
On Tue, 28 Feb 2006 20:37:14 +0100
Post by darekm
Post by Micha Nelissen
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms
The buttons look should follow the users theme. They should not look the
same on all platforms.
With Frame3D we loose the theme background of buttons. I commented this
out and kept the old DrawFrameControl.
Under tSpeedButton is no background (as I know), all is painting
I have similar problem with tPanel and tHeader, but i will investigate
in next time
A button under gtk1 is an area, not just the frame. Some themes define a
simple darkened area when presses, some some define whole images (e.g.
round buttons). Maybe gtk2 has more possibilities for TSpeedButton.
Post by darekM
Post by Mattias Gaertner
I applied the rest. gtk2 seems to work better now.
Mattias
darekm
2006-03-01 10:35:48 UTC
Permalink
Post by Mattias Gaertner
On Wed, 01 Mar 2006 08:41:57 +0100
Post by darekM
Post by Mattias Gaertner
On Tue, 28 Feb 2006 20:37:14 +0100
Post by darekm
Post by Micha Nelissen
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms
The buttons look should follow the users theme. They should not look the
same on all platforms.
With Frame3D we loose the theme background of buttons. I commented this
out and kept the old DrawFrameControl.
Under tSpeedButton is no background (as I know), all is painting
I have similar problem with tPanel and tHeader, but i will investigate
in next time
A button under gtk1 is an area, not just the frame. Some themes define a
simple darkened area when presses, some some define whole images (e.g.
round buttons). Maybe gtk2 has more possibilities for TSpeedButton.
I don't know exactly, but DrawFrameControl can't draw round frame, thats
not issue,
we have own paint function with caption and glyph, only frame left from
widgets

for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)

it's only my suggestion

Darek
Post by Mattias Gaertner
Post by darekM
Post by Mattias Gaertner
I applied the rest. gtk2 seems to work better now.
Mattias
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Mattias Gaertner
2006-03-01 10:57:45 UTC
Permalink
On Wed, 01 Mar 2006 11:35:48 +0100
Post by darekm
Post by Mattias Gaertner
On Wed, 01 Mar 2006 08:41:57 +0100
Post by darekM
Post by Mattias Gaertner
On Tue, 28 Feb 2006 20:37:14 +0100
Post by darekm
Post by Micha Nelissen
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms
The buttons look should follow the users theme. They should not look
the >>same on all platforms.
Post by darekM
Post by Mattias Gaertner
With Frame3D we loose the theme background of buttons. I commented this
out and kept the old DrawFrameControl.
Under tSpeedButton is no background (as I know), all is painting
I have similar problem with tPanel and tHeader, but i will investigate
in next time
A button under gtk1 is an area, not just the frame. Some themes define a
simple darkened area when presses, some some define whole images (e.g.
round buttons). Maybe gtk2 has more possibilities for TSpeedButton.
I don't know exactly, but DrawFrameControl can't draw round frame, thats
not issue,
we have own paint function with caption and glyph, only frame left from
widgets
I don't know, what windows can do with DrawFrameControl, but under gtk it
draws an area in a specific style. If this is a button style, and the theme
defines an image, it paints it.
Post by darekm
for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)
Gtk has less widgets, because the idea is combine them. A TGroupbox is a
single widget under windows, while under gtk it needs two. For gtk it is
pretty normal to put a 'listbox' into a menu. That's why you have more
possibilties.
A TSpeedButton that is used a button and that draws some rectangles, when
all other widgets on the application have shaded round widgets looks very
ugly. Especially if you use broken themes, that merely defines images and no
colors.
Post by darekm
it's only my suggestion
What is the trouble with theme painted speedbuttons?


Mattias
Panagiotis Sidiropoulos
2006-03-01 15:35:20 UTC
Permalink
What about developing and compiling for PDAs, Smart phones and other
handheld devices, using Lazarus or FreePascal? Is there, or will be, any
such option?

Panagiotis
Felipe Monteiro de Carvalho
2006-03-01 14:40:46 UTC
Permalink
Post by Panagiotis Sidiropoulos
What about developing and compiling for PDAs, Smart phones and other
handheld devices, using Lazarus or FreePascal? Is there, or will be, any
such option?
Unfortunately Free Pascal website is down, and the wikies are also
down at the moment. I will pass you some links when they come back.
There is a lot of information on PDAs on the wikies.

Here is a small description of the status of different PDAs:

* PDAs that Free Pascal already supports but Lazarus does not

You can already develop software for Windows CE (both for PocketPC and
Smartphones) using the arm-wince cross compiler. Information on how to
set this up is on the wiki. So you can create Free Pascal programs for
Windows CE (I tested this and it works really well). The Lazarus
Widgetset to allow RAD for this platform already compiles, but it's
rather empty. I will work on this when I have time.

You can already develop software for Linux based PDAs using
Qt/Embedded bindings for FPC by Den Jean. The Qt widgetset is under
development (already basicaly working) and will on the not so far
future allow RAD for linux-based PDAs

* PDAs that are not supported by Free Pascal

PalmOS. Needs to have a run-time library implemented. Any help on this
is appreciated

Symbian smartphones. Help is appreciated.

Blackbarry

Java-based phones. Some phones only support java. It's possible to
support them if we can make a compiler that produces java bytecode.
There already exists a pascal compiler that does it, but I cannot
remember the name.

Others.
--

So, please, help us implement PDA support for Lazarus and Free Pascal
=) One of the most needed things (in my opinion) is PalmOS support on
the compiler, because PalmOS has a large chunk of the market.

--
Felipe Monteiro de Carvalho
Alexander Todorov
2006-03-01 15:53:59 UTC
Permalink
On 3/1/06, Felipe Monteiro de Carvalho
Post by Felipe Monteiro de Carvalho
Blackbarry
Java-based phones. Some phones only support java. It's possible to
support them if we can make a compiler that produces java bytecode.
There already exists a pascal compiler that does it, but I cannot
remember the name.
MIDletPascal.

http://www.midletpascal.com/

I've tried it with some simple apps for Nokia and Sony Ericsson phones.
The compiler is great IMO but it needs more classes / functions.

Other options for Palm devices are :

HSPascal
http://hspascal.fihl.net/

PPCompiler
http://www.ppcompiler.org/?lng=en
Michael Van Canneyt
1970-01-01 00:00:00 UTC
Permalink
Post by Felipe Monteiro de Carvalho
* PDAs that are not supported by Free Pascal
PalmOS. Needs to have a run-time library implemented. Any help on this
is appreciated
PalmOS used to be supported.
It's just a matter of reviving the port, and finding a maintainer.

Michael.
Felipe Monteiro de Carvalho
2006-03-03 02:56:01 UTC
Permalink
I had an idea to go around the down wiki problem. Use google cache =)

About FPC+Windows CE: http://www.freepascal.org/wiki/index.php/WinCE_port

About general PDA info:
http://64.233.179.104/search?q=cache:VEOwlJmsauIJ:wiki.lazarus.freepascal.org/index.php/Feature_Ideas+site:wiki.lazarus.freepascal.org+PDA&hl=pt-BR&gl=br&ct=clnk&cd=1

Look for "PDA"

About Qt4/Qtopia LCL:
http://64.233.179.104/search?q=cache:_BUSMxvjks0J:wiki.lazarus.freepascal.org/index.php/Qt_Interface+site:wiki.lazarus.freepascal.org+Qt&hl=pt-BR&gl=br&ct=clnk&cd=1

--
Felipe Monteiro de Carvalho
Dale Welch
2006-03-03 04:07:31 UTC
Permalink
They don't have a recent archive of it... but you can use the Way Back Machine...
http://www.archive.org/
type in any web site...
They will show you dates they archived it.
And you can then look at it from that date.
If you ever lose your site it's a great way to recover an old version of it.
So march 25th of last year
http://web.archive.org/web/20050325031801/http://www.lazarus.freepascal.org/

:-)
---dale
Post by Felipe Monteiro de Carvalho
I had an idea to go around the down wiki problem. Use google cache =)
About FPC+Windows CE: http://www.freepascal.org/wiki/index.php/WinCE_port
http://64.233.179.104/search?q=cache:VEOwlJmsauIJ:wiki.lazarus.freepascal.org/index.php/Feature_Ideas+site:wiki.lazarus.freepascal.org+PDA&hl=pt-BR&gl=br&ct=clnk&cd=1
Look for "PDA"
http://64.233.179.104/search?q=cache:_BUSMxvjks0J:wiki.lazarus.freepascal.org/index.php/Qt_Interface+site:wiki.lazarus.freepascal.org+Qt&hl=pt-BR&gl=br&ct=clnk&cd=1
--
Felipe Monteiro de Carvalho
Felipe Monteiro de Carvalho
2006-03-03 11:09:48 UTC
Permalink
The wiki is up!

Here is a screenshot of a software created with Free Pascal and
running on Windows CE:

http://wiki.lazarus.freepascal.org/index.php/Windows_CE_Interface

Other link: http://wiki.lazarus.freepascal.org/index.php/Feature_Ideas#PDA_Support

--
Felipe Monteiro de Carvalho
darekm
2006-03-03 22:10:41 UTC
Permalink
Hi
with current CVS setColor for tSpeedButton don't work

DrawFrameControl can draw only rectangle with or without shadow, no
other possibilities



rest investigation under
Post by Mattias Gaertner
Post by darekm
Post by Mattias Gaertner
Post by darekM
Post by Mattias Gaertner
Post by darekm
Post by Micha Nelissen
Post by darekm
now i prepare patch for
tSpeedButton
Why use Frame3D instead of DrawFrameControl ?
its simpler,
and why one function for drawing for all components, (on other side is
used only 3 times toolbutton, speedbutton and checkbutton)
Post by Mattias Gaertner
Post by darekm
Post by Mattias Gaertner
Post by darekM
Post by Mattias Gaertner
Post by darekm
SpeedButton is draw near all without widget,
Frame3D should be faster and identical on all platforms
The buttons look should follow the users theme. They should not look
the >>same on all platforms.
Post by darekM
Post by Mattias Gaertner
With Frame3D we loose the theme background of buttons. I commented this
out and kept the old DrawFrameControl.
Under tSpeedButton is no background (as I know), all is painting
I have similar problem with tPanel and tHeader, but i will investigate
in next time
A button under gtk1 is an area, not just the frame. Some themes define a
simple darkened area when presses, some some define whole images (e.g.
round buttons). Maybe gtk2 has more possibilities for TSpeedButton.
Interesting are there possibilities, which we can use in all OS, of
course we can implement all myself, but we are limited
by LCL API, for example now I can't change color of shadow (tButton have
not thous properties)
I think, that we should implement more flexible widgets, not so
dependent from desired library (GTK, WIN, QT)
Post by Mattias Gaertner
Post by darekm
I don't know exactly, but DrawFrameControl can't draw round frame, thats
not issue,
we have own paint function with caption and glyph, only frame left from
widgets
I don't know, what windows can do with DrawFrameControl, but under gtk it
draws an area in a specific style. If this is a button style, and the theme
defines an image, it paints it.
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
Post by Mattias Gaertner
Post by darekm
for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)
Gtk has less widgets, because the idea is combine them. A TGroupbox is a
single widget under windows, while under gtk it needs two. For gtk it is
pretty normal to put a 'listbox' into a menu. That's why you have more
possibilties.
A TSpeedButton that is used a button and that draws some rectangles, when
all other widgets on the application have shaded round widgets looks very
ugly. Especially if you use broken themes, that merely defines images and no
colors.
DrawFrameControl not avoid this
Post by Mattias Gaertner
Post by darekm
it's only my suggestion
What is the trouble with theme painted speedbuttons?
it's not work
Post by Mattias Gaertner
Mattias
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Mattias Gaertner
2006-03-04 01:06:46 UTC
Permalink
On Fri, 03 Mar 2006 23:10:41 +0100
Post by darekm
[...]
Post by darekm
Post by Mattias Gaertner
A button under gtk1 is an area, not just the frame. Some themes define
a >>simple darkened area when presses, some some define whole images
(e.g. >>round buttons). Maybe gtk2 has more possibilities for
TSpeedButton. >>
Interesting are there possibilities, which we can use in all OS, of
course we can implement all myself, but we are limited
by LCL API, for example now I can't change color of shadow (tButton have
not thous properties)
I think, that we should implement more flexible widgets, not so
dependent from desired library (GTK, WIN, QT)
Yes, but then it will be a TButtonPlus. A normal TButton is the normal
button of the theme.
Post by darekm
[...]
I don't know, what windows can do with DrawFrameControl, but under gtk it
draws an area in a specific style. If this is a button style, and the
theme defines an image, it paints it.
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
Correct. But if you want a 'red' button, then you want a custom drawn
button, not a TButton.
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
Frame, BorderWidth, TextAlignment, WordWrap, ... .
This has five advantages:
- the button will really look the same under all platforms
- less code in LCL interfaces
- better for smartlinking
- more flexibility
- cleaner design (themed and non themed controls)
Post by darekm
Post by darekm
for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)
Gtk has less widgets, because the idea is combine them. A TGroupbox is a
single widget under windows, while under gtk it needs two. For gtk it is
pretty normal to put a 'listbox' into a menu. That's why you have more
possibilties.
A TSpeedButton that is used a button and that draws some rectangles, when
all other widgets on the application have shaded round widgets looks very
ugly. Especially if you use broken themes, that merely defines images and
no colors.
DrawFrameControl not avoid this
It should. If not, you found a bug.
Post by darekm
Post by darekm
it's only my suggestion
What is the trouble with theme painted speedbuttons?
it's not work
Can you give more details?

Mattias
Micha Nelissen
2006-03-04 07:06:24 UTC
Permalink
On Sat, 4 Mar 2006 02:06:46 +0100
Post by Mattias Gaertner
Post by darekm
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
Correct. But if you want a 'red' button, then you want a custom drawn
button, not a TButton.
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
TSpeedButton ?

Micha
Micha Nelissen
2006-03-04 07:34:26 UTC
Permalink
On Sat, 4 Mar 2006 08:06:24 +0100
Post by Micha Nelissen
On Sat, 4 Mar 2006 02:06:46 +0100
Post by Mattias Gaertner
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
TSpeedButton ?
I mean we're getting a lot of buttons this way, with mostly redundant
(duplicate) code ... :-/

Micha
Mattias Gaertner
2006-03-04 11:14:57 UTC
Permalink
On Sat, 4 Mar 2006 08:34:26 +0100
Post by Micha Nelissen
On Sat, 4 Mar 2006 08:06:24 +0100
Post by Micha Nelissen
On Sat, 4 Mar 2006 02:06:46 +0100
Post by Mattias Gaertner
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
TSpeedButton ?
Yes, that's indeed a better ancestor for custom drawn buttons.
Post by Micha Nelissen
I mean we're getting a lot of buttons this way, with mostly redundant
(duplicate) code ... :-/
They would be put even in the same unit. I'm sure, we can share the code.
What about this:
TSpeedButton is already painted by the LCL. If the Color property is not the
default, it can switch to custom drawing (Lines instead of
Frame3D/DrawFrameControl). Then we can also add properties BorderWidth,
Margin, gradient, or whatever is desired.
And those who want a 'red' button, we can tell to use a TSpeedButton
instead.
Then the widgetsets need less to fiddle overriding theme properties and
programmers get 'special' looking buttons.
A programmer, who wants a 'red' button, does not care about the theme of
the button anyway.


Mattias
darekm
2006-03-04 11:31:05 UTC
Permalink
Post by Mattias Gaertner
On Fri, 03 Mar 2006 23:10:41 +0100
Post by darekm
[...]
Post by darekm
Post by Mattias Gaertner
A button under gtk1 is an area, not just the frame. Some themes define
a >>simple darkened area when presses, some some define whole images
(e.g. >>round buttons). Maybe gtk2 has more possibilities for
TSpeedButton. >>
Interesting are there possibilities, which we can use in all OS, of
course we can implement all myself, but we are limited
by LCL API, for example now I can't change color of shadow (tButton have
not thous properties)
I think, that we should implement more flexible widgets, not so
dependent from desired library (GTK, WIN, QT)
Yes, but then it will be a TButtonPlus. A normal TButton is the normal
button of the theme.
I talk about tSpeedButton not tButton
Post by Mattias Gaertner
Post by darekm
[...]
I don't know, what windows can do with DrawFrameControl, but under gtk it
draws an area in a specific style. If this is a button style, and the
theme defines an image, it paints it.
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
Correct. But if you want a 'red' button, then you want a custom drawn
button, not a TButton.
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
Frame, BorderWidth, TextAlignment, WordWrap, ... .
- the button will really look the same under all platforms
- less code in LCL interfaces
- better for smartlinking
- more flexibility
- cleaner design (themed and non themed controls)
that's what for is property color,
and maybe order should be different: first without theme and second
(inherited) with.
or (better) tControl should have property - with or without theme
Post by Mattias Gaertner
Post by darekm
Post by darekm
for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)
Gtk has less widgets, because the idea is combine them. A TGroupbox is a
single widget under windows, while under gtk it needs two. For gtk it is
pretty normal to put a 'listbox' into a menu. That's why you have more
possibilties.
A TSpeedButton that is used a button and that draws some rectangles, when
all other widgets on the application have shaded round widgets looks very
ugly. Especially if you use broken themes, that merely defines images and
no colors.
DrawFrameControl not avoid this
It should. If not, you found a bug.
DrawFrameControl use only two function
If (Shadow=GTK_SHADOW_NONE) then
gtk_paint_flat_box(aStyle,aDC.Drawable,
else
gtk_paint_box(aStyle,aDC.Drawable,

both draw rectangle,
As I know, Style either don't have place to set rounded widgets
It can only set pixmap (that's is only difference to windows)


and we not use this to tButton, then why use it to tSpeedButton
Post by Mattias Gaertner
Post by darekm
Post by darekm
it's only my suggestion
What is the trouble with theme painted speedbuttons?
it's not work
Can you give more details?
simple: when I set color:=clRed then not change color (like in others
controls)
Post by Mattias Gaertner
Mattias
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Mattias Gaertner
2006-03-04 13:31:06 UTC
Permalink
On Sat, 04 Mar 2006 12:31:05 +0100
Post by darekm
[...]
I talk about tSpeedButton not tButton
A normal TSpeedButton should look like a normal button.
Only if you set some custom colors, then it can paint some non theme button.
Post by darekm
Post by darekm
Post by Mattias Gaertner
I don't know, what windows can do with DrawFrameControl, but under gtk
it >>draws an area in a specific style. If this is a button style, and
the >>theme defines an image, it paints it.
Post by darekm
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
Correct. But if you want a 'red' button, then you want a custom drawn
button, not a TButton.
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
Frame, BorderWidth, TextAlignment, WordWrap, ... .
- the button will really look the same under all platforms
- less code in LCL interfaces
- better for smartlinking
- more flexibility
- cleaner design (themed and non themed controls)
that's what for is property color,
and maybe order should be different: first without theme and second
(inherited) with.
or (better) tControl should have property - with or without theme
The theme is the default. And painting the theme requires only a call to the
widgetset, while custom painting requires extra code. I don't see, why a
themed control would descend from a non themed control. Or maybe I
misunderstood you here?
About the Theme property: IMHO this property would be redundant and/or
readonly. Can you give an example, where it is needed?
Post by darekm
Post by darekm
Post by Mattias Gaertner
Post by darekm
for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)
Gtk has less widgets, because the idea is combine them. A TGroupbox is
a >>single widget under windows, while under gtk it needs two. For gtk it
is >>pretty normal to put a 'listbox' into a menu. That's why you have
more >>possibilties.
Post by darekm
Post by Mattias Gaertner
A TSpeedButton that is used a button and that draws some rectangles,
when >>all other widgets on the application have shaded round widgets
looks very >>ugly. Especially if you use broken themes, that merely
defines images and >>no colors.
Post by darekm
DrawFrameControl not avoid this
It should. If not, you found a bug.
DrawFrameControl use only two function
If (Shadow=GTK_SHADOW_NONE) then
gtk_paint_flat_box(aStyle,aDC.Drawable,
else
gtk_paint_box(aStyle,aDC.Drawable,
both draw rectangle,
As I know, Style either don't have place to set rounded widgets
It can only set pixmap (that's is only difference to windows)
Correct. They look as if they are round, but it's an illusion. Just as
Frame3D - the frame is not 3D.
But Frame3D only paints a frame without content, while DrawFrameControl
draws a whole control.
Of course this is an extension to the winapi definition. It is done so,
because all the Delphi code using those functions, will look pretty on other
platforms.
Post by darekm
and we not use this to tButton, then why use it to tSpeedButton
TButton has less properties, so it represents the normal button of the
widgetset.
TSpeedButton has some more features (group, down, flat).
Post by darekm
Post by darekm
Post by Mattias Gaertner
Post by darekm
it's only my suggestion
What is the trouble with theme painted speedbuttons?
it's not work
Can you give more details?
simple: when I set color:=clRed then not change color (like in others
controls)
The solution is simple: if color<>clBtnFace then paint a custom button.
The question is only, how to implement it.
The easiest would be to extend TSpeedButton.Paint with a

if (Color<>clBtnFace) or (... other properties ...) then
PaintCustomSpeedButton
else
PaintThemeButton


Mattias
darekm
2006-03-04 16:56:41 UTC
Permalink
Post by Mattias Gaertner
Post by darekm
simple: when I set color:=clRed then not change color (like in others
controls)
The solution is simple: if color<>clBtnFace then paint a custom button.
The question is only, how to implement it.
The easiest would be to extend TSpeedButton.Paint with a
if (Color<>clBtnFace) or (... other properties ...) then
PaintCustomSpeedButton
else
PaintThemeButton
with this patch works (only change order)

two suggestion
1. is clDefault not better than clBtnFace
2. DrawFrameControl should return inner rectangle (control should know
how fat is frame)


Darek
Mattias Gaertner
2006-03-04 17:05:10 UTC
Permalink
On Sat, 04 Mar 2006 17:56:41 +0100
Post by darekm
Post by Mattias Gaertner
Post by darekm
simple: when I set color:=clRed then not change color (like in others
controls)
The solution is simple: if color<>clBtnFace then paint a custom button.
The question is only, how to implement it.
The easiest would be to extend TSpeedButton.Paint with a
if (Color<>clBtnFace) or (... other properties ...) then
PaintCustomSpeedButton
else
PaintThemeButton
with this patch works (only change order)
Applied. Thanks.
Post by darekm
two suggestion
1. is clDefault not better than clBtnFace
Delphi compatibility
Post by darekm
2. DrawFrameControl should return inner rectangle (control should know
how fat is frame)
Yes. It's a todo.


Mattias
Danny Milosavljevic
2006-03-04 18:07:24 UTC
Permalink
Hi,
Post by Mattias Gaertner
On Fri, 03 Mar 2006 23:10:41 +0100
Post by darekm
[...]
Post by darekm
Post by Mattias Gaertner
A button under gtk1 is an area, not just the frame. Some themes define
a >>simple darkened area when presses, some some define whole images
(e.g. >>round buttons). Maybe gtk2 has more possibilities for
TSpeedButton. >>
Interesting are there possibilities, which we can use in all OS, of
course we can implement all myself, but we are limited
by LCL API, for example now I can't change color of shadow (tButton have
not thous properties)
I think, that we should implement more flexible widgets, not so
dependent from desired library (GTK, WIN, QT)
Yes, but then it will be a TButtonPlus. A normal TButton is the normal
button of the theme.
Post by darekm
[...]
I don't know, what windows can do with DrawFrameControl, but under gtk it
draws an area in a specific style. If this is a button style, and the
theme defines an image, it paints it.
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
Correct. But if you want a 'red' button, then you want a custom drawn
button, not a TButton.
If 'red' buttons are needed that often, then we should add a
TCustomDrawnButton (or whatever name fits) with properties like Color,
Frame, BorderWidth, TextAlignment, WordWrap, ... .
- the button will really look the same under all platforms
I hope that it is clear that a button that looks the same under all
platforms is a _disadvantage_. The button of random app X should adapt
to the desktop environment in use, otherwise it looks out of place. Just
look at the java apps around. Everywhere, no matter if on mswin32 or
unix or mac, just everywhere, (our) java swing gui is ugly. It just
looks the same everywhere, which is 1) out of place for mswin32 2) out
of place for unix and 3) out of place for mac ... not good :)

cheers,
Danny
Post by Mattias Gaertner
- less code in LCL interfaces
- better for smartlinking
- more flexibility
- cleaner design (themed and non themed controls)
Post by darekm
Post by darekm
for tButton all depend from widgets, but for me in tSpeedButton all
should be independent. (GTK has't two widgets)
Gtk has less widgets, because the idea is combine them. A TGroupbox is a
single widget under windows, while under gtk it needs two. For gtk it is
pretty normal to put a 'listbox' into a menu. That's why you have more
possibilties.
A TSpeedButton that is used a button and that draws some rectangles, when
all other widgets on the application have shaded round widgets looks very
ugly. Especially if you use broken themes, that merely defines images and
no colors.
DrawFrameControl not avoid this
It should. If not, you found a bug.
Post by darekm
Post by darekm
it's only my suggestion
What is the trouble with theme painted speedbuttons?
it's not work
Can you give more details?
Mattias
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Danny Milosavljevic
2006-03-04 13:50:34 UTC
Permalink
Hi,
Post by darekm
[...]
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
I merely react to this grossly out of context (so please forgive me),
but I just can't resist...

Did you really mean what I read you to mean?

Many (and I mean MANY) people can't even _see_ red (but can see colors
that somewhat resemble it), so they _have_ to change it... others don't
like the color red because of psychic problems (after witnessing
accidents, ...) (especially big red areas on buttons that look like a
puddle of blood that flows around until it reaches some obstacle).
Others don't like it because of other reasons.
Low-color displays (over modem lines etc) have 256 color limitations,
which makes hardcoded color values a PITA, because they eat up palette
entries for _all_ applications and in the end you can't read a thing.
(not mentioning black-and-white displays here because they got kind of
rare)

http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm

Let's not go back to the dark old times where the programmer decided
what was good and the user needed to eat it, whether he wants to or not.
Also, nowadays, we usually do have some processor cycles to spare for
doing the right thing.

gtk does the right thing by letting the programmer register "style
properties" for a widget class. These names can then be used in themes
and gtk will assign the theme color to the style property of the widgets
of that class on runtime.

I know that it usually depends on the target audience whether it's ok to
take shortcuts like hardcoding colors (if your program is to be used by
an internal group of 5 people, new people never enter, and none of them
has color blindness, sure, hardcode red all you like). _But_ when
designing a framework, that is the wrong way to take because they affect
all the users there are.

sigh.

cheers,
Danny
darekm
2006-03-04 17:11:05 UTC
Permalink
Post by Danny Milosavljevic
Hi,
Post by darekm
[...]
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
I merely react to this grossly out of context (so please forgive me),
but I just can't resist...
Did you really mean what I read you to mean?
Many (and I mean MANY) people can't even _see_ red (but can see colors
that somewhat resemble it), so they _have_ to change it... others don't
like the color red because of psychic problems (after witnessing
accidents, ...) (especially big red areas on buttons that look like a
puddle of blood that flows around until it reaches some obstacle).
Others don't like it because of other reasons.
Low-color displays (over modem lines etc) have 256 color limitations,
which makes hardcoded color values a PITA, because they eat up palette
entries for _all_ applications and in the end you can't read a thing.
(not mentioning black-and-white displays here because they got kind of
rare)
http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm
Let's not go back to the dark old times where the programmer decided
what was good and the user needed to eat it, whether he wants to or not.
Also, nowadays, we usually do have some processor cycles to spare for
doing the right thing.
gtk does the right thing by letting the programmer register "style
properties" for a widget class. These names can then be used in themes
and gtk will assign the theme color to the style property of the widgets
of that class on runtime.
I know that it usually depends on the target audience whether it's ok to
take shortcuts like hardcoding colors (if your program is to be used by
an internal group of 5 people, new people never enter, and none of them
has color blindness, sure, hardcode red all you like). _But_ when
designing a framework, that is the wrong way to take because they affect
all the users there are.
Yes, You have right,
user should have possibility to change color
but primary programmer set up all controls
if I make button for alerts or erase (or other important or unusual
things) I make it different

when user change theme they should'n make back all controls similar, he
should change it in different way

When I can (but I can't) done step one, then I will do step two.


Darek

PS. With the rest: live is not so easy as You write
A.J. Venter
2006-03-04 18:00:15 UTC
Permalink
Post by Danny Milosavljevic
gtk does the right thing by letting the programmer register "style
properties" for a widget class. These names can then be used in themes
and gtk will assign the theme color to the style property of the widgets
of that class on runtime.
I know that it usually depends on the target audience whether it's ok to
take shortcuts like hardcoding colors (if your program is to be used by
an internal group of 5 people, new people never enter, and none of them
has color blindness, sure, hardcode red all you like). _But_ when
designing a framework, that is the wrong way to take because they affect
all the users there are.
What you are saying is correct, but not absolutely so. There are exceptions to
every rule and the fact is programmers MUST have the capacity to sometimes
enforce certain look and feel changes regardless of themes because themes are
always generic (they are meant to apply to all apps) and sometimes a program
is doing something which is simply specific to that program and the
programmer needs a way of visually explaining a concept to users which simply
does not exist in any theming system.
Take tappytux for example (the program which was the reason why I started the
gtk2 font setting patches). Number one requested feature from users was: make
the text entry bar at the bottom HUGE.

This was not MY choice, it was THEIR choice. This was not something that could
be done for EVERY tedit in the program, but it HAD to be done for THAT tedit
- because the nature of the program was such that, that "entry bar" had to be
really big and accentuated.
Why ? Because the program is for children, and it's a game - and people who
only learned to read a month ago needs to be able to read what they type in
there at a single glance.
The rest of the program they have TIME to spell out letters, if they have to
do it there they will never learn not to have to (at least not from the
program which is supposed to have been written to help teach them this)
because they will simply go game over before they finish the first word.

See what I am getting at ? It's partially intended audience but it's also
purpose of the program, sometimes a programmer needs to be able to enforce
some things in the look and feel department.
Finally there is the simple reality that despite the lack of credit popular
culture gives us in this regard nearly all programmers are highly creative
people. We LIKE to design interfaces and we like to be a little bit artistic
when we do, and there is nothing wrong with that. Since we are the creators,
we should be able to design something which is visually pleasing to us ?

I am not saying we should force users to use bright-red buttons (and I know
that green-red as distinguishing features is a horrible thing to do to users
since about 8% of men cannot distinguish them), but I am saying that we
SHOULD be able to sometimes say "This is the main headline part of my main
screen - I would really like it if it was in Mincho Gothic font in blue
letters on a cream colored button -because it is not SUPPOSED to be the same
as the other buttons" - and that I believe is entirely a good thing, and
something I encourage in my trainee's.
Programmer designs should never detract from usability, but we should still be
able to employ a little bit of creativity in interface design - the job of
interface design is to take an abstract computing concept of some sort and
create a visual analogy that allows non-computer experts to understand what
they program does for them and how to achieve their goals with it. This IS a
creative process and ingenuity can make all the difference here, especially
with custom apps which are often the first to design for a certain concept.
To imagine that any theme can be broad enough to handle ALL the problems any
program will ever be asked to solve and still be usable as a theme is
downright ridiculous.
The default should always be to follow the theme, the programmer should think
five or six times before overriding it - but when he does, it must be assumed
that he had a good reason and his changes should be honoured.

Ciao
A.J.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
Danny Milosavljevic
2006-03-04 18:39:42 UTC
Permalink
Hi,
Post by A.J. Venter
Post by Danny Milosavljevic
gtk does the right thing by letting the programmer register "style
properties" for a widget class. These names can then be used in themes
and gtk will assign the theme color to the style property of the widgets
of that class on runtime.
I know that it usually depends on the target audience whether it's ok to
take shortcuts like hardcoding colors (if your program is to be used by
an internal group of 5 people, new people never enter, and none of them
has color blindness, sure, hardcode red all you like). _But_ when
designing a framework, that is the wrong way to take because they affect
all the users there are.
What you are saying is correct, but not absolutely so. There are exceptions to
every rule and the fact is programmers MUST have the capacity to sometimes
enforce certain look and feel changes regardless of themes because themes are
always generic (they are meant to apply to all apps) and sometimes a program
is doing something which is simply specific to that program and the
programmer needs a way of visually explaining a concept to users which simply
does not exist in any theming system.
Yes, when it is too new a feature to be considered in the theming system
yet, I agree.
Post by A.J. Venter
Take tappytux for example (the program which was the reason why I started the
gtk2 font setting patches). Number one requested feature from users was: make
the text entry bar at the bottom HUGE.
This was not MY choice, it was THEIR choice. This was not something that could
be done for EVERY tedit in the program, but it HAD to be done for THAT tedit
- because the nature of the program was such that, that "entry bar" had to be
really big and accentuated.
Why ? Because the program is for children, and it's a game - and people who
only learned to read a month ago needs to be able to read what they type in
there at a single glance.
The rest of the program they have TIME to spell out letters, if they have to
do it there they will never learn not to have to (at least not from the
program which is supposed to have been written to help teach them this)
because they will simply go game over before they finish the first word.
See what I am getting at ? It's partially intended audience but it's also
purpose of the program, sometimes a programmer needs to be able to enforce
some things in the look and feel department.
Yes, but not colors. It's just getting too hairy. Since humans settled
down and have no natural enemies anymore, over time the same will happen
to us that happened to our pets: we lose color sight. Over a short or a
long period, we do. Evolution hates wasting effort on unused gadgets :)

oops, getting off-track :)
Post by A.J. Venter
Finally there is the simple reality that despite the lack of credit popular
culture gives us in this regard nearly all programmers are highly creative
people.
I know and I restrain myself every day to actually use the ... stuff
that is there already instead of rewriting everything :)
Post by A.J. Venter
We LIKE to design interfaces and we like to be a little bit artistic
when we do, and there is nothing wrong with that.
If it's within limits, it's ok. (Minimum) Font sizes and colors are
entirely in the user's realm though and we just can't magically set that
to a constant value for everyone. It just doesn't work :)

But if it's with layouting existing widgets and clustering them in
different windows and such, sure, all freedom there. But _for example_
creating a new-and-improved kind of "knob" control instead of a slider
is off-limits.
Post by A.J. Venter
Since we are the creators,
we should be able to design something which is visually pleasing to us ?
Yes, so use style properties (and maybe propose defaults for them to
gtk) and fall back to your defaults in code if missing in theme.

I'm not saying that design shouldn't be done. Design is important. Some
stuff is outside of our realm though, like font size and color.
Post by A.J. Venter
I am not saying we should force users to use bright-red buttons (and I know
that green-red as distinguishing features is a horrible thing to do to users
since about 8% of men cannot distinguish them), but I am saying that we
SHOULD be able to sometimes say "This is the main headline part of my main
screen - I would really like it if it was in Mincho Gothic font in blue
letters on a cream colored button -because it is not SUPPOSED to be the same
as the other buttons" - and that I believe is entirely a good thing, and
something I encourage in my trainee's.
Yes, so make a class "FooHeadline" or so that does that and defaults to
those colors and font (the actual font can even be fixed, not the size
though) and font size, but overrideable by user gtkrc config file /
theme.
Post by A.J. Venter
Programmer designs should never detract from usability, but we should still be
able to employ a little bit of creativity in interface design - the job of
interface design is to take an abstract computing concept of some sort and
create a visual analogy that allows non-computer experts to understand what
they program does for them and how to achieve their goals with it. This IS a
creative process and ingenuity can make all the difference here, especially
with custom apps which are often the first to design for a certain concept.
To imagine that any theme can be broad enough to handle ALL the problems any
program will ever be asked to solve and still be usable as a theme is
downright ridiculous.
Therefore the system is extensible. You don't even have to install any
file onto the system, just call gtk_widget_install_style_property or so
and bam, _it's there_. If user puts color/font size for that name into
his theme, _it's used_.

It can be summed up with:
- Use sane defaults for font size/color
- But let user override them (and _not_ only on a per-application basis,
but at most desktop-wide and at least single-control-instance-wide)
Post by A.J. Venter
The default should always be to follow the theme, the programmer should think
five or six times before overriding it - but when he does, it must be assumed
that he had a good reason and his changes should be honoured.
Exactly.
Post by A.J. Venter
Ciao
A.J.
cheers,
Danny
A.J. Venter
2006-03-04 18:58:25 UTC
Permalink
Post by Danny Milosavljevic
Post by A.J. Venter
The default should always be to follow the theme, the programmer should
think five or six times before overriding it - but when he does, it must
be assumed that he had a good reason and his changes should be honoured.
Exactly.
Let me try to explain what I mean with an EXTREME example.
Say you are coding the control system for a nuclear power station. Now 99% of
your screen is showing the current values for things and with some sliders
the operators can adjust some of the equipment settings to ensure that
everything remains normal.

For almost all times this is ALL there is to it. But there on one side is a
few critical values, these ones won't just be changed by adjusting one thing,
if they are outside tolerance values then that means a trained expert will
need to adjust probably 80% of those sliders to very specific settings to
deal with what is in fact an emergency.

So when one of those goes out of tolerable range you start by activating every
alarm in the building, syrens howling, strobe lights flashing the works. But
on screen you do NOT want everything highlighted. What you DO want is for the
area around the specific value that triggered the problem to start cycling
through red-green-blue-orange-purple and some more colours at a fairly high
rate so the operator your alarm woke up will INSTANTLY see which value is out
of range and can start fixing it immediately.
You don't want to pop up a dialog - clicking ok means it takes longer before
he starts adjusting the parameters, but you MUST highlight THAT specific
element in a way that should NEVER happen otherwise.

The element may be a TEdit on a tgroupbox. Now if an emergency exists and you
start colour-flashing the tgroupbox to draw attention to the RIGHT tedit but
a theme overrides your colour calls so it doesn't flash and the whole town is
flattened before the operator finds the right value (he cannot fix the
problem until he knows WHAT the problem is) - well the whole theory just went
up in smoke (as did the town).

In a non computerized nuclear power station, a big LED would have flashed
below the dial with the out of sync value, in a computerized version you HAVE
to find a way of getting exactly the same kind of notification and theme must
not prevent you from doing it, especially since computerising has so many
other usefull advantages (a computer could solve simpler cases itself, like
automatically increasing cooling if the temperature rises by a few degrees)
in other words, a computerized interface is a good idea - but it MUST be able
to override the theme when needed.

Yes this is probably the most extreme example there is but it is a very real
one, and just because most of us are not coding nuclear reactor controls
doesn't mean that our reasons for occasionally having to FORCE colors or
fonts are not good ones.

A.J.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
Danny Milosavljevic
2006-03-04 19:36:06 UTC
Permalink
Hi,
Post by A.J. Venter
Post by Danny Milosavljevic
Post by A.J. Venter
The default should always be to follow the theme, the programmer should
think five or six times before overriding it - but when he does, it must
be assumed that he had a good reason and his changes should be honoured.
Exactly.
Let me try to explain what I mean with an EXTREME example.
Say you are coding the control system for a nuclear power station. Now 99% of
your screen is showing the current values for things and with some sliders
the operators can adjust some of the equipment settings to ensure that
everything remains normal.
For almost all times this is ALL there is to it. But there on one side is a
few critical values, these ones won't just be changed by adjusting one thing,
if they are outside tolerance values then that means a trained expert will
need to adjust probably 80% of those sliders to very specific settings to
deal with what is in fact an emergency.
So when one of those goes out of tolerable range you start by activating every
alarm in the building, syrens howling, strobe lights flashing the works. But
on screen you do NOT want everything highlighted. What you DO want is for the
area around the specific value that triggered the problem to start cycling
through red-green-blue-orange-purple and some more colours at a fairly high
rate so the operator your alarm woke up will INSTANTLY see which value is out
of range and can start fixing it immediately.
You don't want to pop up a dialog - clicking ok means it takes longer before
he starts adjusting the parameters, but you MUST highlight THAT specific
element in a way that should NEVER happen otherwise.
The element may be a TEdit on a tgroupbox. Now if an emergency exists and you
start colour-flashing the tgroupbox to draw attention to the RIGHT tedit but
a theme overrides your colour calls so it doesn't flash and the whole town is
Well, a theme bug... guess the theme author must go hide really well
now :)

And usually then it isn't a TGroupBox any more but a TAlertableFrame
that is derived from TGroupBox and has some extra style properties like
"overloaded-reactor-color" ... :)

I feel like I'm still missing your point :(
Post by A.J. Venter
flattened before the operator finds the right value (he cannot fix the
problem until he knows WHAT the problem is) - well the whole theory just went
up in smoke (as did the town).
In a non computerized nuclear power station, a big LED would have flashed
below the dial with the out of sync value, in a computerized version you HAVE
to find a way of getting exactly the same kind of notification and theme must
not prevent you from doing it, especially since computerising has so many
other usefull advantages (a computer could solve simpler cases itself, like
automatically increasing cooling if the temperature rises by a few degrees)
in other words, a computerized interface is a good idea - but it MUST be able
to override the theme when needed.
Yes this is probably the most extreme example there is but it is a very real
one, and just because most of us are not coding nuclear reactor controls
doesn't mean that our reasons for occasionally having to FORCE colors or
fonts are not good ones.
Yes, occassionaly being the keyword :)

I am in favour of bondage & discipline, so I want the case of
force-setting colors to be hard and weary and the case of installing a
normal style property to be easy :)

That is not to say that it should be impossible to set your own colors,
just really really hard. That's also why it's so hard to do in gtk+. And
it should be kept that hard to do (at least).

Of course that is all theoretical talk because when one of the supported
widgetsets of the LCL doesn't support themes, we are screwed and _have
to_ expose Color & Font directly... we'll see..

cheers,
Danny
darekM
2006-03-04 22:37:08 UTC
Permalink
Post by Danny Milosavljevic
Well, a theme bug... guess the theme author must go hide really well
now :)
And usually then it isn't a TGroupBox any more but a TAlertableFrame
that is derived from TGroupBox and has some extra style properties like
"overloaded-reactor-color" ... :)
I feel like I'm still missing your point :(
Why You want all world move to theme.
I know : theme are are good and we can do everything with it.
But its only feature (its good ) not obligation
Lazarus was made with one aspect: compatibility with Delphi and till now
it has no "theme thinking" at API layer.
Of course we can all stuff prepare to theme, but many of us have hundred
thousand lines of code without theme, and now we all must move all code
to theme: what for? for new bugs, not necessary feature?
Not all people need theme, only working software. If they don't like
programs they change it.
You can't tell: don't use Color only theme. Programmer have to know what
is better, he (not ) decided, if he goes wrong, he will not sell program.

And when we talk about freedom: this is freedom to make mistake or not,
Lazarus should (it can be) work with and without theme, even it
(programing without theme) is bad

When I say : live its not so simple, I think: nobody know all aspect and
environment of every program. One tools never be enough good to use in
any case.





Darek
Mattias Gaertner
2006-03-05 09:40:35 UTC
Permalink
On Sat, 04 Mar 2006 23:37:08 +0100
Post by darekM
Post by Danny Milosavljevic
Well, a theme bug... guess the theme author must go hide really well
now :)
And usually then it isn't a TGroupBox any more but a TAlertableFrame
that is derived from TGroupBox and has some extra style properties like
"overloaded-reactor-color" ... :)
I feel like I'm still missing your point :(
Why You want all world move to theme.
I know : theme are are good and we can do everything with it.
But its only feature (its good ) not obligation
Lazarus was made with one aspect: compatibility with Delphi and till now
it has no "theme thinking" at API layer.
Of course we can all stuff prepare to theme, but many of us have hundred
thousand lines of code without theme, and now we all must move all code
to theme: what for? for new bugs, not necessary feature?
That's why the LCL maps the winapi functions, that are often used in Delphi
code, to themed functions.
Post by darekM
Not all people need theme, only working software. If they don't like
programs they change it.
You can't tell: don't use Color only theme. Programmer have to know what
is better, he (not ) decided, if he goes wrong, he will not sell program.
And when we talk about freedom: this is freedom to make mistake or not,
Lazarus should (it can be) work with and without theme, even it
(programing without theme) is bad
It's much simpler to implement one custom drawing function for a control,
then to map to various themed widgetsets. The LCL took the difficult and
more complex approach. Other people can contribute custom drawn controls. I
wonder, why there is not already a package providing some custom drawn
controls as there are so many for Delphi.
Post by darekM
When I say : live its not so simple, I think: nobody know all aspect and
environment of every program. One tools never be enough good to use in
any case.
Sure, but we try. :)


Mattias
A.J. Venter
2006-03-05 09:56:52 UTC
Permalink
Post by Mattias Gaertner
It's much simpler to implement one custom drawing function for a control,
then to map to various themed widgetsets. The LCL took the difficult and
more complex approach. Other people can contribute custom drawn controls. I
wonder, why there is not already a package providing some custom drawn
controls as there are so many for Delphi.
Well most of my visual components are actually custom drawn since they are
designed to implement stuff that GTK doesn't normally do. Where themes fall
short is in going one level up as it were. A quick google will find you at
least twenty delphi components for doing more advanced pop-up hints with for
example, depending on what you are looking for (everything from bubble-shaped
to extensive html with image support is available) - THAT is where custom
drawing becomes usefull, for adding that which gives your program an edge.
Sure you don't NEED bubble-shaped pop-ups but they are more pleasing to users
than square lines, and in fact they are becoming the default in several
development environments (on windows anyway).
As far as I can tell, there is no way to implement this with a theme - you
need some form of custom drawing to do it, and I don't think it can be said
that this in any way detracts from usability.
Several usability studies have come to the same conclusion, the universal look
and feel is a myth - icons and colours only have meaning in the culture from
which they originate - in other cultures they could mean completely different
things or more commonly nothing at all - the core thing a programmer MUST do
for usability is be consistent -always use the SAME file open icon, so users
can recognise it even if it DOESN'T mean anything to them.
The second most important thing is to ensure that your interface makes the
purpose of every element obvious right from the start, the more obvious you
can make things the easier it is to "get" the program.
The third rule is - make it look pretty.

Rule 1 says - uses themeing almost all the time.
Rules 2 and 3 says - override the theme if you have to.

Mind you lazarus does not at present provide a clean way of SETTING theme
style properties, and I think it will be very hard to add since the nature of
this will be platform independent (I highly doubt that the same themeing
structure would work on windows that works on GTK and even between GTK1 and
GTK2 there are huge differences in the theme files).
What would be good is if we can create a set of generic theme-style specifiers
for the LCL (much like we translated widgets) which are added as ADDITIONAL
properties, not replacing the delphi properties but being added as extras.
This way you can set at least those elements which are common to all
platforms in the IDE and it will follow a theme file on how to actually
implement them, but when there is a good reason, you use the delphi style
properties to override the them.
A side effect is that if it can also translate to CSS properties it would be a
very nice tool one day when CGI-from-the-IDE starts to become visual :)
Post by Mattias Gaertner
Post by darekM
When I say : live its not so simple, I think: nobody know all aspect and
environment of every program. One tools never be enough good to use in
any case.
Sure, but we try. :)
Lol, that is why there isn't one programming language to rule them all :) but
OP comes pretty close.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
Danny Milosavljevic
2006-03-05 12:09:52 UTC
Permalink
Hi,
Post by A.J. Venter
Post by Mattias Gaertner
It's much simpler to implement one custom drawing function for a control,
then to map to various themed widgetsets. The LCL took the difficult and
more complex approach. Other people can contribute custom drawn controls. I
wonder, why there is not already a package providing some custom drawn
controls as there are so many for Delphi.
Well most of my visual components are actually custom drawn since they are
designed to implement stuff that GTK doesn't normally do. Where themes fall
short is in going one level up as it were. A quick google will find you at
least twenty delphi components for doing more advanced pop-up hints with for
example, depending on what you are looking for (everything from bubble-shaped
to extensive html with image support is available) - THAT is where custom
drawing becomes usefull, for adding that which gives your program an edge.
Sure you don't NEED bubble-shaped pop-ups but they are more pleasing to users
than square lines, and in fact they are becoming the default in several
development environments (on windows anyway).
Well, add them to gtk then - it's not closed or anything. And shapes are
not a problem, sizes and colors are - so as long as you read the
original tooltip color style property in your Paint method - sure, make
them look better :)
Post by A.J. Venter
As far as I can tell, there is no way to implement this with a theme
you are right - this is not within the scope of gtk theming at least -
that is to say, it doesn't do winamp 3 style
make-widget-look-completely-foreign ;)
Post by A.J. Venter
- you
need some form of custom drawing to do it, and I don't think it can be said
that this in any way detracts from usability.
Several usability studies have come to the same conclusion, the universal look
and feel is a myth - icons and colours only have meaning in the culture from
which they originate - in other cultures they could mean completely different
things or more commonly nothing at all - the core thing a programmer MUST do
for usability is be consistent -always use the SAME file open icon, so users
can recognise it even if it DOESN'T mean anything to them.
The second most important thing is to ensure that your interface makes the
purpose of every element obvious right from the start, the more obvious you
can make things the easier it is to "get" the program.
The third rule is - make it look pretty.
Rule 1 says - uses themeing almost all the time.
Rules 2 and 3 says - override the theme if you have to.
Mind you lazarus does not at present provide a clean way of SETTING theme
style properties, and I think it will be very hard to add since the nature of
this will be platform independent
I don't know - there aren`t that many obvious ways to choose from ...

Maybe one person per platform knowing how it is done there can comment
here...
Post by A.J. Venter
(I highly doubt that the same themeing
structure would work on windows that works on GTK and even between GTK1 and
GTK2 there are huge differences in the theme files).
What would be good is if we can create a set of generic theme-style specifiers
for the LCL (much like we translated widgets) which are added as ADDITIONAL
properties, not replacing the delphi properties but being added as extras.
This way you can set at least those elements which are common to all
platforms in the IDE and it will follow a theme file on how to actually
implement them, but when there is a good reason, you use the delphi style
properties to override the them.
A side effect is that if it can also translate to CSS properties it would be a
very nice tool one day when CGI-from-the-IDE starts to become visual :)
Post by Mattias Gaertner
Post by darekM
When I say : live its not so simple, I think: nobody know all aspect and
environment of every program. One tools never be enough good to use in
any case.
Sure, but we try. :)
Lol, that is why there isn't one programming language to rule them all :) but
OP comes pretty close.
hehe

cheers,
Danny

Danny Milosavljevic
2006-03-05 11:48:56 UTC
Permalink
hi,
Post by darekM
Post by Danny Milosavljevic
Well, a theme bug... guess the theme author must go hide really well
now :)
And usually then it isn't a TGroupBox any more but a TAlertableFrame
that is derived from TGroupBox and has some extra style properties like
"overloaded-reactor-color" ... :)
I feel like I'm still missing your point :(
Why You want all world move to theme.
I thought I explained why :)
Post by darekM
I know : theme are are good and we can do everything with it.
But its only feature (its good ) not obligation
When you hardcode one color, no matter where, they become useless _and_
you can't know whether your hardcoded background color clashes with the
theme's foreground color for that widget.
Post by darekM
Lazarus was made with one aspect: compatibility with Delphi and till now
it has no "theme thinking" at API layer.
Of course we can all stuff prepare to theme, but many of us have hundred
thousand lines of code without theme, and now we all must move all code
to theme: what for? for new bugs, not necessary feature?
So people born nowadays can use the program...
Post by darekM
Not all people need theme, only working software. If they don't like
programs they change it.
You can't tell: don't use Color only theme. Programmer have to know what
is better, he (not ) decided, if he goes wrong, he will not sell program.
And when we talk about freedom: this is freedom to make mistake or not,
Lazarus should (it can be) work with and without theme, even it
(programing without theme) is bad
Yes. But overriding the theme color should be hard(er) for the
programmer, shouldn't it?
Post by darekM
When I say : live its not so simple, I think: nobody know all aspect and
environment of every program.
Exactly. Hence ~/.gtkrc-2.0 for the user to be able to configure it (and
lazarus also allows you to ship a ${APPNAME}rc file to be able as a
programmer to set defaults) - the idea is similar to CSS, really.
Post by darekM
One tools never be enough good to use in
any case.
We can try ;)
Post by darekM
Darek
cheers,
Danny
Danny Milosavljevic
2006-03-04 18:22:54 UTC
Permalink
Hi,
Post by darekm
Post by Danny Milosavljevic
Hi,
Post by darekm
[...]
If I want (as programmer) to one of buttons will be red, user should'n
change it by change theme
I merely react to this grossly out of context (so please forgive me),
but I just can't resist...
Did you really mean what I read you to mean?
Many (and I mean MANY) people can't even _see_ red (but can see colors
that somewhat resemble it), so they _have_ to change it... others don't
like the color red because of psychic problems (after witnessing
accidents, ...) (especially big red areas on buttons that look like a
puddle of blood that flows around until it reaches some obstacle).
Others don't like it because of other reasons.
Low-color displays (over modem lines etc) have 256 color limitations,
which makes hardcoded color values a PITA, because they eat up palette
entries for _all_ applications and in the end you can't read a thing.
(not mentioning black-and-white displays here because they got kind of
rare)
http://vision.about.com/od/commonvisiondefects/ss/colorblindimage_3.htm
Let's not go back to the dark old times where the programmer decided
what was good and the user needed to eat it, whether he wants to or not.
Also, nowadays, we usually do have some processor cycles to spare for
doing the right thing.
gtk does the right thing by letting the programmer register "style
properties" for a widget class. These names can then be used in themes
and gtk will assign the theme color to the style property of the widgets
of that class on runtime.
It's similar but more flexible to the borland pascal turbo vision
palette approach btw (but uses strings as ids, not integers, and is
per-class)
Post by darekm
Post by Danny Milosavljevic
I know that it usually depends on the target audience whether it's ok to
take shortcuts like hardcoding colors (if your program is to be used by
an internal group of 5 people, new people never enter, and none of them
has color blindness, sure, hardcode red all you like). _But_ when
designing a framework, that is the wrong way to take because they affect
all the users there are.
Yes, You have right,
user should have possibility to change color
but primary programmer set up all controls
if I make button for alerts or erase (or other important or unusual
things) I make it different
Yes, you register style properties like "alert-color" and "erase-color"
and fallback if those are not defined in the theme after all for your
class.

Having a published Color property in TControl kind of defeats that
though. Better have a list of style property names/types there.

like

TControl
StyleList
alert-color Color
erase-color Color

of course I don't know about mswin32... do they even have a mechanism
like that? I tend to think so, they added "theming" with mswinxp, right?

And qt surely has the same thing somehow...

It's really the obvious way to just abstract out style the same way html
did with css too...
Post by darekm
when user change theme they should'n make back all controls similar, he
should change it in different way
I assume you mean there should be a class "alert control" and a class
"normal control". All alert controls surely have to look the same to
each other or else it wouldn't be ... well... alerting ...
Or, if you wish, "alertable control" which can be both depending on
internal state.
Post by darekm
When I can (but I can't) done step one, then I will do step two.
What is step 1? You can derive any kind of gtk widget from an existing
widget class, give it new properties and handle it differently in the
theme (theme value selections are per widget name and/or widget class
name and/or style property name and/or extra "detail" field internal to
the drawer - he passes that when calling the drawing functions, it can't
get much more flexible than that ;))

like,

widget_class "*Alert*" style "foo"
widget_class "*Erase*" style "bar"

or so :)

or by name:

widget "evolution_folder_frame_tree" style "green"
:)
Post by darekm
Darek
PS. With the rest: live is not so easy as You write
Well, life is hard, especially with UNIX :)

But I am thankful to the Gnome guys that I don't have to cope with
unusable (X, motif, win32, ....) apps anymore... only a handful
crashprone apps left (filemanager, window manager, panel), Xfce
replacing them for me :)

If you mean that doing the right thing is hard, then I agree, it is,
always, everywhere :)

But it should be done.

cheers,
Danny
Mattias Gaertner
2006-02-28 18:26:27 UTC
Permalink
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
Hi
I continue my investigation with widgets color
now i prepare patch for
tSpeedButton
tEdit
tListBox
all for GTK1
Darek
PS. For A.I. Vender
maybe now tEdit change the color.
If not I'll try, but first i must install GTK2
Maybe there is a bug in the constants?

GTK_STYLE_TEXT = $81 -> this flag bitmask bites GTK_STATE_ACTIVE

if GTK_STYLE_TEXT in mask then

Do you mean something like
GTK_STYLE_BASE = $40; // custom flag to change base styles
GTK_STYLE_TEXT = $80; // custom flag to change text styles

?


Mattias
darekm
2006-02-28 19:29:57 UTC
Permalink
Post by Mattias Gaertner
Maybe there is a bug in the constants?
GTK_STYLE_TEXT = $81 -> this flag bitmask bites GTK_STATE_ACTIVE
if GTK_STYLE_TEXT in mask then
Do you mean something like
GTK_STYLE_BASE = $40; // custom flag to change base styles
GTK_STYLE_TEXT = $80; // custom flag to change text styles
?
I forget about speed, of course that can be change (can You do this or I
should prepare new patch)

tGtkStateEnumRange = 0..31; // lower than 32 to keep set in one integer
tGtkStateEnum = set of tGtkStateEnumRange;

GTK_STYLE_TEXT = 20;
GTK_STYLE_BASE = 21;


^^^^^^^^^^^^^^^^^^^^
this is better




Darek
Mattias Gaertner
2006-02-28 18:30:35 UTC
Permalink
On Tue, 28 Feb 2006 19:16:10 +0100
Post by darekm
Hi
I continue my investigation with widgets color
now i prepare patch for
tSpeedButton
tEdit
tListBox
all for GTK1
Darek
PS. For A.I. Vender
maybe now tEdit change the color.
If not I'll try, but first i must install GTK2
I just saw, that tGtkStateEnum is set of byte. What of waste of space and
time.
It should be something like

tGtkStateEnumRange = 0..31; // lower than 32 to keep set in one integer
tGtkStateEnum = set of tGtkStateEnumRange;

GTK_STYLE_TEXT = 20;
GTK_STYLE_BASE = 21;

Mattias
Continue reading on narkive:
Loading...