Hi,
I'm using the development code from http://ltk.rplay.net/svn/branches/ltk/repl (r210)
Since tiled Tk dropped the -indicatoron attribute from radio-buttons, I need to define a custom style as described on pages 5-7 of http://tktable.sourceforge.net/tile/tile-tcl2004.pdf
How would one approach this with ltk?
Or have I walked past the bleeding edge...
Thanks, Daniel
On Sat, 6 Jun 2009, Daniel Herring wrote:
I'm using the development code from http://ltk.rplay.net/svn/branches/ltk/repl (r210)
Since tiled Tk dropped the -indicatoron attribute from radio-buttons, I need to define a custom style as described on pages 5-7 of http://tktable.sourceforge.net/tile/tile-tcl2004.pdf
How would one approach this with ltk?
First try was to directly use (send-wish). Then more reading revealed that the Toolbar style was added to all standard ttk themes. So the following just works (bash shell, Tk 8.5 or higher).
# cat << _EOF | wish ttk::checkbutton .cb -text "test" -style Toolbutton ttk::checkbutton .cb2 -text "test2" -style Toolbutton pack .cb pack .cb2 _EOF
However, the ltk equivalent doesn't work...
(defun ltk-toolbar () (with-ltk () (let* ((f (make-instance 'frame)) (cb (make-instance 'check-button :master f :text "test" :variable "cb" :style "Toolbutton")) (cb2 (make-instance 'check-button :master f :text "test2" :variable "cb2" :style "Toolbutton"))) (pack f) (pack cb) (pack cb2))))
Running this gives an error that :style is an invalid parameter. Ok, update (defargs check-button) to include style and recompile ltk.
Now I get the same error I was getting with radio-buttons. "Tcl/Tk error: Layout toolbutton not found" "Do you wish to invoke the debugger?" Y/N
(setf *debug-tk* t) Now I see the problem; the log shows buffer_text "ttk::checkbutton .wc.wd -style toolbutton -textvariable text_wd -variable cb"
"Toolbutton" was downcased to "toolbutton" and the quotes were removed. Looks like a (format s "~A" "Toolbutton") somewhere...
Here's the diffs which make Toolbar-style checkboxes work in ltk for me. I'm not exactly sure what the *initargs* voodoo is, but it seemed to behave rationally.
***** diff --git a/ltk.lisp b/ltk.lisp index aec7b93..b30a0e8 100644 --- a/ltk.lisp +++ b/ltk.lisp @@ -1339,6 +1339,7 @@ can be passed to AFTER-CANCEL" (spacing2 spacing2 "~@[ -spacing2 ~(~a~)~]" spacing2 "") (spacing3 spacing3 "~@[ -spacing3 ~(~a~)~]" spacing3 "") (state state "~@[ -state ~(~a~)~]" state "") + (style style "~@[ -style ~s~]" style "") (tabs tabs "~@[ -tabs ~(~a~)~]" tabs "") (takefocus takefocus "~@[ -takefocus ~(~a~)~]" takefocus "if true, the widget can take the focus") (tearoff tearoff "~@[ -tearoff ~(~a~)~]" tearoff "if true, the menu can be torn off") @@ -1465,7 +1466,7 @@ can be passed to AFTER-CANCEL"
#-:tk84 (defargs check-button () - cbcommand class compound cursor image offvalue onvalue state takefocus textvariable underline variable width) + cbcommand class compound cursor image offvalue onvalue state style takefocus textvariable underline variable width)
#+:tk84 (defargs check-button () *****
Later, Daniel
Hallo Daniel,
indeed, ttk style support is not in LTk yet, but I am happy about your contributions there. Unfortunately, finding out about all the Tk 8.5 changes is a bit of guesswork in absence of some overview documentation... but the link you posted should help a bit.
The initargs seems indeed to be black voodoo - perhaps it actually is :). But you did it exactly right. To explain the concept of the system:
- defargs tells LTk which arguments/parameters a widget takes. - the list *initargs* describes how the single parameters should be handled when passing them to Tk. By default it inded prints the content lowercased - that works usually quite well as most literal arguments Tk takes are lowercased strings. So with this format directive you can just use Lisp keywords as in (pack :side :left) For parameters where this is not desired, you have to give the fitting definition as you did. This definition applies for all widgets, which have a "style" parameter. The format of the definition has four elements: 1) the internal name by which the parameter is looked up 2) the name used for the corresponding keyword parameter e.g. for initalize-instance 3) the format string for formatting the parameter 4) a lisp form that is evaluated and passed to format for consumption by the format string in 3)
so 4) is either 2) or an expression of 2) 1) is mostly also 2) but sometimes not, if different widget need to implement the parameter with different format statements. See for example that there is a separate cbcommand, which creates a command parameter for the check-button, as in contrast to the command parameter for the plain button, the created callback gets the value of the widget passed.
I hope that helps... Peter
-
Daniel Herring -
Peter Herth