[Patch] Patch for windows XP themed buttons/checkbuttons/radiobuttons
Georgios Petasis
I have updated my patch for tk 8.4a2 to the latest CVS version of tk
(8.4.4). My patch adds a new option (-stylexp <boolean>)
to button/checkbutton/radiobutton, which enables the widget to be drawn
using the windows XP themes support.
The easiest way to enable XP drawing, is by adding:
## Under Windows XP activate some styled widgets...
if {[string equal "windows" $tcl_platform(platform)] && \
$::tcl_platform(osVersion) >= 5.1} {
option add *Button.StyleXp 1
option add *Toolbar*StyleXp 0
option add *Button.Width -11
option add *Entry.StyleXp 1
option add *Spinbox.StyleXp 1
option add *Checkbutton.StyleXp 1
option add *Radiobutton.StyleXp 1
}
at the begining of an application. Doing so in an app
of mine, gives an this output:
http://www.iit.demokritos.gr/~petasis/Tcl/EllogonXP.png
(Note that toolbar buttons have the default tk look)
The patch can be found at:
http://www.iit.demokritos.gr/~petasis/Tcl/Tk8.4.4XPStyle.patch
(Sorry, SF is down for meintenance :-))
Please, see this patch as an opportunity to add such support
in tk core (of course with the needed changes to whet the patch
implements). I don't want to re-write it for a third time :-)
Any feedback of course is welcomed...
George
Chang Li
Chang
"Georgios Petasis" <pet...@iit.demokritos.gr> wrote in message
news:bj23tp$1q2m$1...@ulysses.noc.ntua.gr...
Georgios Petasis
I have only *added* code, without relying on anything that may have changed
recently (i.e. the use of a different GC for disabled buttons with images,
which used to crash tk). I think that the patch work as expected
also in 8.3.x...
But please, please do not use -stylexp <boolean> directly in your code.
Use the option database instead (as I proposed) as I am sure it will be
changed
in the near future (when and if the patch will find its way into the core).
Its a quick and dirty (:-)) solutuion for testing the drawing capabilities.
I have also written a small test program to display differences/similarities
the patch brings to widgets. See below :-)
George
foreach widget {button checkbutton radiobutton} {
set index 0
set column 0
set row 0
toplevel .$widget
wm title .$widget "Widget = $widget, Style XP"
toplevel .$widget.ns
wm title .$widget.ns "Widget = $widget, Default Tk Style"
foreach bd {2} {
foreach state {normal active disabled} {
foreach relief {flat raised sunken} {
foreach overrelief {flat raised sunken} {
foreach default {normal active disabled} {
if {$widget == "button"} {
$widget .$widget.b[incr index] -bd $bd -state $state \
-relief $relief \
-overrelief $overrelief -default $default -stylexp 1 \
-text "$state,$relief,$overrelief,$default"
grid .$widget.b$index -row $row -column [incr column] \
-sticky snew -padx 1 -pady 1
$widget .$widget.ns.b$index -bd $bd -state $state -relief $relief \
-overrelief $overrelief -default $default -stylexp 0 \
-text "$state,$relief,$overrelief,$default"
grid .$widget.ns.b$index -row $row -column $column -sticky snew \
-padx 1 -pady 1
} else {
$widget .$widget.b[incr index] -bd $bd -state $state \
-relief $relief -overrelief $overrelief -stylexp 1 \
-text "$state,$relief,$overrelief,$default" -anchor w
grid .$widget.b$index -row $row -column [incr column] -sticky
snew \
-padx 1 -pady 1
$widget .$widget.ns.b$index -bd $bd -state $state -relief $relief \
-overrelief $overrelief -stylexp 0 \
-text "$state,$relief,$overrelief,$default" -anchor w
grid .$widget.ns.b$index -row $row -column $column -sticky snew \
-padx 1 -pady 1
}
if {$column >= 6} {
incr row
set column 0
}
}
}
}
}
}
}
pack [button .b -text {Exit} -stylexp 1 -command exit]
"Chang Li" <cha...@neatware.com> wrote in message
news:rYJ5b.4786$Jf3....@newscontent-01.sprint.ca...
Chang Li
> I think it should, but I haven't tested it though.
>
> I have only *added* code, without relying on anything that may have
changed
> recently (i.e. the use of a different GC for disabled buttons with images,
> which used to crash tk). I think that the patch work as expected
> also in 8.3.x...
>
> But please, please do not use -stylexp <boolean> directly in your code.
> Use the option database instead (as I proposed) as I am sure it will be
> changed
I guess -stylexp <boolean> is unnecessary. You can detect XP with an
API call. So when the OS is in the XP theme the button is in XP style.
Chang
Georgios Petasis
For example, I have developed numerous NLP corpora
annotation tools that have tenths of butons, each one having a
different fg/bg colour (so as to distinguish the
various values, as the buttons are associated with
tags on text/html widgets). Removing the background
colour will be a disaster! :-)
George
"Chang Li" <cha...@neatware.com> wrote in message
news:iMQ5b.4845$Jf3....@newscontent-01.sprint.ca...
Chang Li
> But what if the user does not want the XP look?
XP allows user choose Windows 2000 style (theme).
In the XP style every GUI should follow the XP L&F.
Consistent L&F is the 101 of good GUI.
> For example, I have developed numerous NLP corpora
> annotation tools that have tenths of butons, each one having a
> different fg/bg colour (so as to distinguish the
> various values, as the buttons are associated with
> tags on text/html widgets). Removing the background
> colour will be a disaster! :-)
>
It is ideal that when a Tk program running on XP style it
has a XP L&F and when it is running on Win2000 style
it has Win2000 L&F. Like Windows MFC program no
code is required to be modified.
vince darley
> But what if the user does not want the XP look?
> For example, I have developed numerous NLP corpora
> annotation tools that have tenths of butons, each one having a
> different fg/bg colour (so as to distinguish the
> various values, as the buttons are associated with
> tags on text/html widgets). Removing the background
> colour will be a disaster! :-)
Surely XP must provide an alternative approach (different widget or
different way to specify the colour or ...) for those situations where
buttons must be coloured more obviously? The optimal solution for the
future of XP cannot be that some applications use win2000 l&f and
others winXP l&f!
Vince.
Georgios Petasis
In this case, the API does not draw anything :-)
A white rectangle! There is no way to use the visual style
facilities to draw a button with a background colour other
than the default offered by the current theme.
If you know a way, please let me know...
(I think that even windows internet explorer uses
plain rectangular buttons if they have special background
colours...)
George
"vince darley" <vincen...@users.sourceforge.net> wrote in message
news:4dd3bea3.03090...@posting.google.com...
Jeff Hobbs
XP has themes, and this patch hopefully adjusts for them. Just like
the scrollbar now does correctly on Tk, it would pick up the current
theme that the user chooses. This is by far the most desired feel
for professional end users - adapting to the user specified theme. I
run XP on one machine but use the classic Win2K look (which I *much*
prefer), and Tk's scrollbar appropriately uses the same.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Jeff Hobbs
> I have updated my patch for tk 8.4a2 to the latest CVS version of tk
> (8.4.4). My patch adds a new option (-stylexp <boolean>)
> to button/checkbutton/radiobutton, which enables the widget to be drawn
> using the windows XP themes support.
This is great - I'll try it in the 8.5 head soon. I will likely
drop the -stylexp, possibly adding in a magic tk namespace var that
can control this. However, just as the scrollbar does XP themes
now, we should do it right for the other widgets where we can have a
100% overlap of functionality (note that Windows scrollbars can't be
configured as much as the "true Tk" unix scrollbars). A global
fallback for those with "specialized" looks is always a safe bet.
lvi...@yahoo.com
According to Jeff Hobbs <je...@activestate.com>:
:Georgios Petasis wrote:
:> My patch adds a new option (-stylexp <boolean>)
:> to button/checkbutton/radiobutton
:I will likely
:drop the -stylexp, possibly adding in a magic tk namespace var that
:can control this.
Why a magic variable rather than a switch? Just curious to hear your
thoughts. I had thought that Tcl was moving away from magic variables and
towards commands and switches. This one, in particular, seems ripe
for, at the very least, a 'wm style' type command...
--
<URL: http://wiki.tcl.tk/ > <URL: http://www.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Jeff Hobbs
> According to Jeff Hobbs <je...@activestate.com>:
> :Georgios Petasis wrote:
> :> My patch adds a new option (-stylexp <boolean>)
> :> to button/checkbutton/radiobutton
>
> :I will likely
> :drop the -stylexp, possibly adding in a magic tk namespace var that
> :can control this.
> Why a magic variable rather than a switch? Just curious to hear your
> thoughts. I had thought that Tcl was moving away from magic variables and
> towards commands and switches. This one, in particular, seems ripe
> for, at the very least, a 'wm style' type command...
Well, I was thinking more "global" vs "local", and it could have been
in the 'tk' command, but you are right that the 'wm' command is just
as appropriate for it. I'm just not sure that I want it that
publicly exposed. We don't offer any way to return to non-native
dialogs aside from overriding the commands, and no way whatsoever to
return to non-native scrollbars. If the buttons work fully, then
should we be exposing a way a return to the non-native ones?
lvi...@yahoo.com
:dialogs aside from overriding the commands, and no way whatsoever to
:return to non-native scrollbars. If the buttons work fully, then
:should we be exposing a way a return to the non-native ones?
I think that there should be a way for the developer to return to non-native
scrollbars, dialogs, etc.
It should be a decision made by the developer. I have read comments
in the past month, either here or on the wiki, by at least one person
(I can't recall whom - perhaps GPS?) who was struggling in their attempt for a
'one look across all platforms' type approach.
Jeff Hobbs
> According to Jeff Hobbs <je...@activestate.com>:
> :We don't offer any way to return to non-native
> :dialogs aside from overriding the commands, and no way whatsoever to
> :return to non-native scrollbars. If the buttons work fully, then
> :should we be exposing a way a return to the non-native ones?
>
> I think that there should be a way for the developer to return to non-native
> scrollbars, dialogs, etc.
>
> It should be a decision made by the developer. I have read comments
Ah, *you* might think that, but I don't necessarily agree, and there are
many in the HCI field that certainly don't agree. Toolkits shouldn't
necessarily allow "poor UI". Take for example Aqua. It was noted that
you cannot create multi-line buttons in Aqua - the toolkit simply won't
allow it.
Mark Roseman
> I think that there should be a way for the developer to return to non-native
> scrollbars, dialogs, etc.
>
> It should be a decision made by the developer. I have read comments
> in the past month, either here or on the wiki, by at least one person
> (I can't recall whom - perhaps GPS?) who was struggling in their attempt for a
> 'one look across all platforms' type approach.
The developer may want to decide that, but that doesn't mean
Tk should accommodate them. The one look across all platforms
is such a fringe (and usually terribly misguided) requirement
that I think it would be a complete waste of effort to even
begin to try to support it.
Mark
Georgios Petasis
I think it would be a good idea as a first step to add some
public C API to tk that can draw the various XP elements.
My patch targeted primarily buttons, but as buttons have
noumerous uses we can start with other widgets that cannot
be customised a lot (or usually developers don't change
their default look) like the entry widget, the text widget
and spinbox.
I suppose adding the XP drawing public API requires a TIP.
Any opinions on this?
(I got the feeling that despite some recent interest, like
the tk revitalisation project, again nothing moves towards
a better tk :-))
George
"Mark Roseman" <ma...@markroseman.com> wrote in message
news:mark-BC2444.0...@news.cogeco.ca...
Pat Thoyts
>So, what will finally happen to the patch?
>
>I think it would be a good idea as a first step to add some
>public C API to tk that can draw the various XP elements.
>My patch targeted primarily buttons, but as buttons have
>noumerous uses we can start with other widgets that cannot
>be customised a lot (or usually developers don't change
>their default look) like the entry widget, the text widget
>and spinbox.
>
>I suppose adding the XP drawing public API requires a TIP.
>Any opinions on this?
>(I got the feeling that despite some recent interest, like
>the tk revitalisation project, again nothing moves towards
>a better tk :-))
Joe English and I have been working on a modified Tk style engine
that Joe wrote and your XP code was the basis or the xpnative theme
for this project.
You can follow soem of the progress for this at
http://tktable.sf.net/tile/
and get the code from
cvs -d:pserver:anon...@cvs.tktable.sf.net/cvsroot/tktable co tile
--
Pat Thoyts http://www.zsplat.freeserve.co.uk/resume.html
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD