A few things I consider as design flaws in ttk tiles
tombert
think "why the hell is it the way it is ...":
1) background color
Why do some themes don't allow to change the background color. My
application uses three different backgrounds depending on state:
warning, error, active. Consider 'warning' when the entered value is
near some limit, error if its out of limit, active if its currently
processed.
I considers this flaw as a no-go.
2) widgets states
Thinking a bit further, I would like my own additional states
(described above warning, error, active) to be allowed in the
<widget> state
command. Then simply map:
ttk::style map TEntry -fieldbackground {warning yellow}
I also could think of having:
ttk::style map TEntry -state {!active disabled}
Unfort. defining own states throws an error - from my point of view it
would not make much a change to support the described above concept.
3) creating own widgets
Using ttk elements it is possible to create futuristic widgets like a
spincombo in the following way:
eval ttk::style map Mybox [ttk::style map TCombobox]
ttk::style layout Mybox [ttk::style layout TCombobox]
eval ttk::style configure Mybox [ttk::style configure TCombobox]
ttk::style layout Mybox {Combobox.border -sticky nswe -children
{Spinbox.uparrow -side left Combobox.rightdownarrow -side right -
sticky ns Combobox.padding -expand 1 -sticky nswe -children
{Combobox.focus -expand 1 -sticky nswe -children {Combobox.textarea -
sticky nswe}}}}
Assigning the style above to a widget would create a combobox with a
spinbox button inside. I've created and using such a spincombo widget
with normal tk - and I find it very useful.
Unfort. again ttk seemed not to have thought about such a use-case.
So to conclude: I find it nice but point 1 is a show-stopper for me,
point 2 and 3 let me think that the concept is missing something.
Harald Oehlmann
IMHO ttk was necessary to make tk survive,
because applications must look native on windows and MacOS.
It was a big effort to bring it out and it allows to get to the goal.
We are all missing many things from tk.
I am a sort careing about BWidget and bringing them to ttk is
enourmously difficult.
Csabah did a brilliant job with tablelist here.
Background color ? I got the answer, that on the MAC, this is even not
a color but a bitmap.
Thats why property background-color is missing typically for native
themes.
I had a widget with state colors like you have.
I have solved the issue by a frame around the input widget which
changes color, not the entry itself.
I invite you to "coorporate" with ttk.
And there is many space for enhancements...
-Harald
Wojciech Kocjan
> In principle I like the idea of tiles very much ... but sometimes I
> think "why the hell is it the way it is ...":
>
> 1) background color
> Why do some themes don't allow to change the background color. My
> application uses three different backgrounds depending on state:
> warning, error, active. Consider 'warning' when the entered value is
> near some limit, error if its out of limit, active if its currently
> processed.
> I considers this flaw as a no-go.
Yes and no. I agree it is silly you can't just specify background,
especially if you'd use "background" element.
I think it's OSX's theme's fault since you can do that on any platform
except for OSX. I remember seeing some
However, you can easily work around this - I needed a white frame/
label/checkbutton and native frame/label/checkbutton. So, I created
this:
image create photo image_osxWhite -width 16 -height 16
image_osxWhite put \#ffffff -to 0 0 16 16
ttk::style element create OSXWhiteBackground image image_osxBlank16 \
-border {6 6 6 6} -padding {0} -sticky news
# (although I don't think -border is needed, not sure)
ttk::style layout OSXWhiteFrame {
OSXWhiteWidget.background
}
ttk::style layout OSXWhiteLabel {
OSXWhiteWidget.background -children {
OSXWhiteLabel.label
}
}
Again, I do agree here that if someone sets -background, it should be
doable.
But I found ttk layouts VERY useful - for example if you want to just
grab the highlighted frame OSX gives you, you can do:
ttk::style layout OSXHighlightedFrame {
Entry.field
}
bind OSXHighlightedFrame <FocusIn> {%W state focus}
bind OSXHighlightedFrame <FocusOut> {%W state !focus}
And then for the widget:
$path configure -style OSXHighlightedFrame -padding {4 4}
bindtags $path [linsert [bindtags $path] 0 OSXHighlightedFrame]
I create an empty frame for non-OSX, a highlighted frame for OSX and
you can just put widgets in there (like text that doesn't have native
frames) - and they get OSX native frame for free :-)
So, while this particular thing is missing, ttk gives you enough tools
to work around it.
I think the worse thing is lack of introspection - if you want to
"mimic" ttk::checkbutton's default layout, you need to look in OSX
source code and TTK_BEGIN_LAYOUT to get the thing done right.
But, again, I think the advantages overwhelm the problems you can find
with ttk - if you fight such things, my recommendation is to learn ttk
elements, layouts etc.
I personally love this.
> 2) widgets states
> Thinking a bit further, I would like my own additional states
> (described above warning, error, active) to be allowed in the
> <widget> state
> command. Then simply map:
> ttk::style map TEntry -fieldbackground {warning yellow}
>
> I also could think of having:
> ttk::style map TEntry -state {!active disabled}
>
> Unfort. defining own states throws an error - from my point of view it
> would not make much a change to support the described above concept.
Oooh, yes, I have to agree with this one. Again, you can work around
it by doing styles like Warning.TEntry etc, it requiers you to modify -
style yourself, and state mappings are just nicer.
> So to conclude: I find it nice but point 1 is a show-stopper for me,
> point 2 and 3 let me think that the concept is missing something.
Ttk might be improved, I agree there. But I don't think it's missing
something, more like it is not as mature as people would like it to be
yet.
I think ttk is a really good piece of work, being able to combine
requirements for all the different platforms - after all, it supports
OSX, Windows, Gtk, Qt, custom themes etc and still you can just grab
the elements and do your own layout. And once you grab the concept, it
is just all so clear and easy.
--
WK
tombert
MAC ... but at least I learned something new.
"... Csabah did a brilliant job with tablelist here ..." - this I
already told him.
"... It was a big effort to bring it out and it allows to get to the
goal ..." - and I appreciate it.
"... invite you to "coorporate" with ttk ..." - how shall such a
cooperation look like?
Wojciech Kocjan: many thx for your example - it gives me much to think
about how to work with ttk. One question arised from your example:
ttk::style layout OSXHighlightedFrame {
Entry.field
}
bind OSXHighlightedFrame <FocusIn> {%W state focus}
Is it possible not to bind on a layout but on an element? Somthing
like:
bind Entry.field <Button-1> <script>
I'am still thinking about creating own widgets for my purpose using
existing elements. For example think about an open-file entry with a
small folder icon inside - I need to bind on it - but only on that
image.
"... Ttk might be improved, I agree there. But I don't think it's
missing
something ..." - as I would say: a glas of water half filled is
considered half-empty if you're selling it to me or half-full if you
give to me for free.
By the way - I think I will leave my background color as is and place
warning/error/active icons inside. For this I would need to change the
layout dynamically - do you see a problem in that?
many thx
thomas
tombert
different icons depending on my own states:
## create an element image with warning and error state
ttk::style element create State.image image {{} error $imgErr warning
$imgWarn}
## create the user which is able to edit this entry
ttk::style element create User.image image {{} admin $imgAdmin guest
$imgGuest}
## redefine the layout
ttk::style layout TEntry {Entry.field -sticky nswe -children
{Entry.background -sticky nswe -children {State.image -side right
User.image -side right Entry.padding -sticky nswe -children
{Entry.textarea -expand yes -sticky nswe}}}}
## then simply:
<widget> state warning
<widget> state admin
I know I could put the icons outside of the entry but then it would'nt
look so neat and I couldn't use this nice 'state' management.
Wojciech Kocjan
> Wojciech Kocjan: many thx for your example - it gives me much to think
> about how to work with ttk. One question arised from your example:
>
> ttk::style layout OSXHighlightedFrame {
> Entry.field}
>
> bind OSXHighlightedFrame <FocusIn> {%W state focus}
>
> Is it possible not to bind on a layout but on an element? Somthing
> like:
> bind Entry.field <Button-1> <script>
You can bind to whatever you want to. The actual thing that causes the
widget to use binding is:
bindtags $path [linsert [bindtags $path] 0 OSXHighlightedFrame]
This tells Tk that this widget should also use bindings from
OSXHighlightedFrame.
http://www.tcl.tk/man/tcl8.5/TkCmd/bindtags.htm
> I'am still thinking about creating own widgets for my purpose using
> existing elements. For example think about an open-file entry with a
> small folder icon inside - I need to bind on it - but only on that
> image.
Why not just create a frame containing a label and an entry?
You can use Itcl/Itk or snit to wrap it into a nice megawidget. Or you
can just do a proc that creates all 3 and binds them together.
> "... Ttk might be improved, I agree there. But I don't think it's
> missing
> something ..." - as I would say: a glas of water half filled is
> considered half-empty if you're selling it to me or half-full if you
> give to me for free.
Well, it will be considered half-empty by your customers anyway - so
you need to fill in the other half on your own - but without ttk,
you'd need to fill it all the way on your own.
> By the way - I think I will leave my background color as is and place
> warning/error/active icons inside. For this I would need to change the
> layout dynamically - do you see a problem in that?
In worst case you can just change -style and create a few layouts.
Ttk will handle reconfiguring it, but I am not sure if width of the
widget won't change for layout without an image vs layout with an
image.
If this is the case, just create a layout with empty image as default
one.
Anyway, that does seem a really cool idea - if you get it done, please
send the snippet here or on the wiki :-)
--
WK
tombert
ttk::spinbox .s1
pack .s1
ttk::style layout TSpinbox {Spinbox.field -sticky nswe -children
{Spinbox.background -sticky nswe -children {Combobox.rightdownarrow -
side right Spinbox.padding -sticky nswe -children {Spinbox.innerbg -
sticky nswe -children {Spinbox.textarea -expand 1 -sticky {}}}
Spinbox.uparrow -side top -sticky ens Spinbox.downarrow -side bottom -
sticky ens}}}
bindtags .s1 {.s1 Mybox . all}
bind Mybox <Button-1> {puts %W}
How can I bind on a specific element or at least how do I know what
element was clicked?
thx
