tktable-tile-dev — Discussion about tile development

RE: [Tile-dev] Random treeview suggestion

[Jeff H. <je...@Ac...>]

Larry McVoy wrote:
> For those of you on windows, try downloading process explorer 
> from www.sysinternals.com (it's like top and ps -axf rolled 
> into one; and filemon from the same place is a lot like a 
> graphical lsof).
> 
> If someone could take the treeview widget and dummy up 
> something that worked liked this on Unix I think that would 
> be an excellent test of emulating a working, useful, polished 
> Windows app.  Assuming that's of any interest.

This already exists in the tktreectrl:
	http://tktreectrl.sourceforge.net/

The latest version does themed header buttons as well.  We use
it in the TDK VFS Explorer.

Jeff

Re: [Tile-dev] Random treeview suggestion

[<lm...@bi...>]

On Tue, Sep 20, 2005 at 05:20:27PM -0700, Larry McVoy wrote:
> For those of you on windows, try downloading process explorer from
> www.sysinternals.com (it's like top and ps -axf rolled into one;
> and filemon from the same place is a lot like a graphical lsof).
> 
> If someone could take the treeview widget and dummy up something that
> worked liked this on Unix I think that would be an excellent test of
> emulating a working, useful, polished Windows app.  Assuming that's
> of any interest.

Oy, that last sentence probably came off in classic Larry McVoy snotty
style.  Sorry about that, that wasn't the intent.  What I was trying
to say is that it's a good app to emulate, if tcl/tk could do that look
and feel and functionality easily that would be a good thing for tcl/tk.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[Tile-dev] Random treeview suggestion

[<lm...@bi...>]

For those of you on windows, try downloading process explorer from
www.sysinternals.com (it's like top and ps -axf rolled into one;
and filemon from the same place is a lot like a graphical lsof).

If someone could take the treeview widget and dummy up something that
worked liked this on Unix I think that would be an excellent test of
emulating a working, useful, polished Windows app.  Assuming that's
of any interest.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] treeview widget support for -xscrollcommand option and xview command

[Joe E. <jen...@fl...>]

Jelco Huijser wrote:

> Currently the the treeview widget still lacks support for
> -xscrollcommand option and xview command which it "ought" to support 
> (referring to
> the treeview documentation). I'm using the treeview as a replacement
> for some mclistbox windows and can't get around the fact that they
> become equally wide, so I need the horizontal scrollbar move the pane
> left or right.

You can adjust column widths from the program with:

	$tv column $columnid -width $pixels

Unfortunately there's no easy way (at present) to automatically 
calculate preferred column widths.  (Suggestions welcome here.)

The treeview's requested width will be the sum of the visible
column widths.  If the actual width ends up larger or smaller than 
this, the difference is added to or subtracted from the last column,
down to a minimum width.  If necessary, subsequent columns are 
"squeezed" from right to left.  I plan to replace this algorithm
with the one the [ttk::paned] widget uses, that seems to work
better.

> Is there a workaround, and/or will this be fixed in the next release? I
> read there is work in progress for calculating the column size more
> accurately, I guess these issues are related.


--Joe English

  jen...@fl...

RE: [Tile-dev] Re: entry widget validation with textvariable "not right"

[Jeff H. <je...@Ac...>]

Joe English wrote:
> Jeff Hobbs wrote:
> > Take a simple validated entry widget:
> >
> > proc isValid {e str} {
> >     set ok [file isfile $str]
> >     $e configure -bg [expr {$ok ? "white" : "lightyellow"}]
> >     return 1
> > }
> 
> OK -- so here you're using the validation facility strictly
> to provide visual feedback, not to prevent the user from 
> entering an invalid value (which in this case is impossible 
> anyway -- you can't type a valid filename without typing 
> something that isn't a filename in between).

Correct, I am "overloading" validatecommand to provide visual
feedback for validity instead of the "less friendly" forced
exclusion.  This is considered friendlier UI practice in some
cases now, and the classic entry widget allows you to do this
very easily.  I prefer to do this with validatecommand
instead of var tracing as the "View" then maintains its own
consistency.  Note that likely many use the -validatecommand
as an entry tracing command.

> Part of the problem is that the return value of the 
> '-validatecommand' means two different things, depending on
> context: (a) allow/don't allow this change, or (b) the value
> is currently valid/invalid.  (The ttk::entry manpage calls case
> (a) "prevalidation" and case (b) "revalidation".)
> 
> But in this case, what you want to say is "the new value is 
> invalid, but accept the change anyway".  There's no good way 
> to do this with the current API.

Yes, and I see this as an unfortunate limitation compared to
the classic entry, given that we have disallowed good UI
practice.

> One possibility would be to use the 'alternate' state instead 
> of 'invalid' for visual feedback:

OK, that would work fine, then I just have to add comments as
to why I call it "alternate" vs. "invalid", since the latter
is self-documenting.

> How about this: change the [ttk::entry] widget to generate
> an <<EntryChanged>> virtual event whenever the value changes. 

Eh?  That's what -validate is already supposed to do.  The use
of a virtual event here seems excessive.

> The ttk::entry widget doesn't currently perform validation
> when the linked -textvariable is set because this leads to 
> anomalies -- if the validation script(s) also set the 
> variable, the widget can't detect it since the original write 
> trace is still active.  I can only think of two ways around 
> this; either don't worry about it and say "User beware", 
> which is basically what the core [entry] does; or schedule 
> revalidation as an idle handler, which leads to even more 
> weirdness. However, it *would* be safe to queue an 
> <<EntryChanged>> event in this condition.

I tried the idle handler with the core entry, and had to go
with "user beware" in the end.  I don't think we should have
to rely on further events in this situation.

> I'm not sure how useful the current 'invalid/!invalid' state 
> logic is.  The intent was to give visual feedback about the 
> current validity of the value, and also to prevent validation 
> lockout: if the widget becomes invalid, let the user type 
> whatever he wants until it's valid again.  But if the 
> application is using prevalidation, the widget can't become 
> invalid in the first place (barring bugs in the app).  
> 
> Maybe it should only set/clear the invalid bit after revalidation?  
> This would make your first approach work (use '-validate key', 
> set/clear the invalid bit in the -validatecommand, always return 1.)  
> Or maybe the widget should not set it at all, leaving it entirely 
> up to the app to do so?

This makes more sense - I want to have the state-based
visual control without actual lockout occuring, and it would
be nice to somehow make this work through -validatecommand.

Jeff

[Tile-dev] Re: entry widget validation with textvariable "not right"

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

> Take a simple validated entry widget:
>
> proc isValid {e str} {
>     set ok [file isfile $str]
>     $e configure -bg [expr {$ok ? "white" : "lightyellow"}]
>     return 1
> }

OK -- so here you're using the validation facility strictly
to provide visual feedback, not to prevent the user from
entering an invalid value (which in this case is impossible
anyway -- you can't type a valid filename without typing
something that isn't a filename in between).

Part of the problem is that the return value of the
'-validatecommand' means two different things, depending on
context: (a) allow/don't allow this change, or (b) the value
is currently valid/invalid.  (The ttk::entry manpage calls case
(a) "prevalidation" and case (b) "revalidation".)

But in this case, what you want to say is "the new value is
invalid, but accept the change anyway".  There's no good
way to do this with the current API.

One possibility would be to use the 'alternate' state instead
of 'invalid' for visual feedback:

    style map TEntry \
    	-foreground {alternate red} -background {alternate lightyellow} ;
    proc checkFilename {e p} {
	$e state [expr {[file isfile $p] ? "!alternate" : "alternate"}]
	return 1
    }
    ttk::entry .e -validatecommand { checkFilename %W %P }

This isn't entirely satisfactory.

How about this: change the [ttk::entry] widget to generate
an <<EntryChanged>> virtual event whenever the value changes.
Then you could use:

    ttk::entry .e -validate none -validatecommand { file isfile %P }
    bind .e <<EntryChanged>> { %W validate }

That is: no prevalidation, but revalidate on every change.

The ttk::entry widget doesn't currently perform validation
when the linked -textvariable is set because this leads to
anomalies -- if the validation script(s) also set the variable,
the widget can't detect it since the original write trace
is still active.  I can only think of two ways around this;
either don't worry about it and say "User beware", which is
basically what the core [entry] does; or schedule revalidation
as an idle handler, which leads to even more weirdness.
However, it *would* be safe to queue an <<EntryChanged>>
event in this condition.

 * * *

I'm not sure how useful the current 'invalid/!invalid' state
logic is.  The intent was to give visual feedback about the
current validity of the value, and also to prevent validation lockout:
if the widget becomes invalid, let the user type whatever he wants
until it's valid again.  But if the application is using prevalidation,
the widget can't become invalid in the first place (barring bugs
in the app).  

Maybe it should only set/clear the invalid bit after revalidation?  
This would make your first approach work (use '-validate key', 
set/clear the invalid bit in the -validatecommand, always return 1.)  
Or maybe the widget should not set it at all, leaving it entirely 
up to the app to do so?


--Joe English

  jen...@fl...

[Tile-dev] entry widget validation with textvariable "not right"

[Jeff H. <je...@Ac...>]

Take a simple validated entry widget:

package require tile
proc isValid {e str} {
    set ok [file isfile $str]
    $e configure -bg [expr {$ok ? "white" : "lightyellow"}]
    return 1
}
proc getfile {e var} {
    set tmp [tk_getOpenFile -title "Select File"]
    if {$tmp ne ""} {
	set $var $tmp
    }
}

destroy .classic
set t [toplevel .classic]
set e [entry $t.e -textvariable ::myvar -validate key \
	-validatecommand [list isValid %W %P]]
button $t.b -text "..." -command [list getfile $e ::myvar]
pack $t.e $t.b -fill x -side left
pack configure $t.e -expand 1

# now in Tile, the "obvious" translation:

# only -foreground seems reliably controllable
style map TEntry -foreground {invalid \#FF0000}

proc isValidTtk {e str} {
    set ok [file isfile $str]
    $e state [expr {$ok ? "!invalid" : "invalid"}]
    return 1
}
proc getfileTtk {e var} {
    set tmp [tk_getOpenFile -title "Select File"]
    if {$tmp ne ""} {
	set $var $tmp
    }
}

destroy .ttk
set t [toplevel .ttk]
set e [ttk::entry $t.e -textvariable ::myvarttk -validate key \
	-validatecommand [list isValidTtk %W %P]]
ttk::button $t.b -text "..." -command [list getfileTtk $e ::myvarttk]
pack $t.e $t.b -fill x -side left
pack configure $t.e -expand 1

Now just type in (don't use the ... yet).  You will see that
the above doesn't work at all.  The problem is that the entry
widget sets the "invalid" bit to whatever is return by the
-validatecommand.  OK, let's try this instead:

proc isValidTtk {e str} {
    set ok [file isfile $str]
    return $ok
}

OK, this will work if the entry starts in an invalid state, as
tile does some internal state handling that way.  However, we
get to any valid state, and we are "locked" there, not able to
type anything else, which is what we were avoiding in the first
place.

OK, so let's consider the ... cases.  I'm setting the textvar
directly.  The behavior difference here is a known variance,
but it only make editing more difficult.  If we get into an
invalid state, we would have to recall '$e validate' on any
getfileTtk call to force validate.  Try to control all via the
entry widget instead:

proc getfileTtk {e var} {
    set tmp [tk_getOpenFile -title "Select File"]
    if {$tmp ne ""} {
	$e delete 0 end
	$e insert 0 $tmp
    }
}

So this will handle validation ... but wait, it doesn't work
at all if you have the strict validation on.  You have to set
-validate none, edit entry, then reset validation.

All in all, it seems like we've lost the flexibility that we
used to have ...

I guess I need a paradigm shift, going back to a whole bunch
of triggers on variable tracing instead, but this is a step
backwards IMO.  Or am I missing something?

Jeff

RE: [Tile-dev] Menubutton look in xpnative theme

[Jeff H. <je...@Ac...>]

[hopefully SF is letting my mail through again ...]

Joe English wrote:
> Schelte Bron wrote:
> > The menubutton in the xpnative theme doesn't look like a button
> > at all. [...]
> > But that's all avoiding the real issue: I think a menubutton
> > should look like a button in the xpnative theme, just like it
> > does in all the other themes. The toolbar look should be
> > obtained by specifying: -style Toolbutton.
> 
> Which brings up a good question: what should [ttk::menubutton]s
> look like by default?  There are a number of possibilities:
> 
> (1) a borderless, plain label with minimal padding, suitable
> for use in a menubar; (2) a distinct button with standard
> button border and an indicator (usually a downward-pointing
> arrow) on the right side; or (3) a toolbar-style button, flat
> by default, raises when the mouse cursor hovers over it.
> 
> (1) is the default for core [menubutton]s, probably for
> compatibility with Tk 3; nowadays it's better to use [menu]s
> instead of a series of [menubutton]s to build menu bars.
> (2) is what you get with [tk_optionMenu].  Tile uses option
> (2) in most themes, except for Windows XP where it uses (3).
> 
> I can't find very many modern UIs that use menubuttons other
> than in toolbars; comboboxes (read-only or otherwise) are much 
> more common (though some KDE apps use something like optionmenus).

On OS X, menubuttons are more common in certain contexts.  See
my changes to the GUI Builder toolbar here:
	http://wiki.tcl.tk/14522

The Justification setting is a menubutton, consistent with OS X
apps.  In fact, the font size should be a menubutton as well,
but I kept the combo to be able to edit it.  I should also be
using the menubutton where I use some spinboxes on OS X.
Windows definitely prefers the readonly combobox instead, and
that is somewhat my preference as well, but the menubutton does
seem a little more polished on OS X (likely because it is much
more in use).

We need to maintain the indicator as mentioned in (2), as that
is what the menubutton needs.  In any case, OS X still seems
to be the heavy mb user, and the look is "just right" there.
It might be nice to recognize -style Toolbutton to control the
Windows behavior that is currently fixed toolbar oriented.

What I'm really curious about is whether we can effect some
sort of button/menu widget properly, as is common in 90% of
modern apps.  This is the button that has a main action item,
but to the right is the dropdown indicator that, if clicked,
drops a menu instead.  The menu item has an action, but the
button never changes from its main command text/image.

Jeff

Re: [Tile-dev] Menubutton look in xpnative theme

[Brian G. <bgr...@mo...>]

Joe English wrote:

>
>I can't find very many modern UIs that use menubuttons other
>than in toolbars; comboboxes (read-only or otherwise) are much 
>more common (though some KDE apps use something like optionmenus).
>
>What do others think?  What, if anything, do you use menubuttons
>for, and what's the best default look and feel?
>  
>

This has been my experience.  We don't use menubuttons anywhere in our 
application, only combo boxes.

-Brian

-- 
# 12th Annual Tcl/Tk Conference: Oct 24-28, 2005, Portland OR
#              http://www.tcl.tk/community/tcl2005
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-------------------------------------------------------------

Re: [Tile-dev] Menubutton look in xpnative theme

[Joe E. <jen...@fl...>]

Schelte Bron wrote:

> The menubutton in the xpnative theme doesn't look like a button
> at all. [...]
> But that's all avoiding the real issue: I think a menubutton
> should look like a button in the xpnative theme, just like it
> does in all the other themes. The toolbar look should be
> obtained by specifying: -style Toolbutton.

Which brings up a good question: what should [ttk::menubutton]s
look like by default?  There are a number of possibilities:

(1) a borderless, plain label with minimal padding, suitable
for use in a menubar; (2) a distinct button with standard
button border and an indicator (usually a downward-pointing
arrow) on the right side; or (3) a toolbar-style button, flat
by default, raises when the mouse cursor hovers over it.

(1) is the default for core [menubutton]s, probably for
compatibility with Tk 3; nowadays it's better to use [menu]s
instead of a series of [menubutton]s to build menu bars.
(2) is what you get with [tk_optionMenu].  Tile uses option
(2) in most themes, except for Windows XP where it uses (3).

I can't find very many modern UIs that use menubuttons other
than in toolbars; comboboxes (read-only or otherwise) are much 
more common (though some KDE apps use something like optionmenus).

What do others think?  What, if anything, do you use menubuttons
for, and what's the best default look and feel?

Also relevant: #1183071 and #1263470.


--Joe English

  jen...@fl...

[Tile-dev] treeview widget support for -xscrollcommand option and xview command

[Jelco H. <je...@it...>]

Currently the treeview widget still lacks support for
-xscrollcommand option and xview command which it "ought" to support
(referring to the treeview documentation). I'm using the treeview as a
replacement for some mclistbox windows and can't get around the fact
that they become equally wide, so I need the horizontal scrollbar move
the pane left or right.

Is there a workaround, and/or will this be fixed in the next release? 
I read there is work in progress for calculating the column size more
accurately, I guess these issues are related.

Thanks, 
Jelco Huijser.

[Tile-dev] treeview widget support for -xscrollcommand option and xview command

[Jelco H. <je...@dd...>]

Currently the the treeview widget still lacks support for
-xscrollcommand option and xview command which it "ought" to support (referring to
the treeview documentation). I'm using the treeview as a replacement
for some mclistbox windows and can't get around the fact that they
become equally wide, so I need the horizontal scrollbar move the pane
left or right.

Is there a workaround, and/or will this be fixed in the next release? I
read there is work in progress for calculating the column size more
accurately, I guess these issues are related.

Thanks, 
Jelco Huijser.

[Tile-dev] Menubutton look in xpnative theme

[Schelte B. <sb...@wa...>]

The menubutton in the xpnative theme doesn't look like a button 
at all. It seems to be hiding in the background and it almost 
magically appears when the mouse pointer passes over it.

I guess in many situation a readonly combobox can be used as an 
alternative. But especially in existing applications the 
different approach needed for a combobox means that quite a bit 
of code has to be redesigned.

Of course, as a dirty hack the menu can be kept around out of 
sight and used by a binding like:
bind $cb <<ComboboxSelect>> {%W.menu invoke [%W current]}

But that's all avoiding the real issue: I think a menubutton 
should look like a button in the xpnative theme, just like it 
does in all the other themes. The toolbar look should be 
obtained by specifying: -style Toolbutton.

Any thoughts?


Schelte.

RE: [Tile-dev] Upcoming changes - compatibility options removed

[Jeff H. <je...@Ac...>]

> Another upcoming change with a potential impact is that
> [style default ...] is going to be renamed to the more 
> sensible [style configure ...].  (This should've been done a 
> long time ago, just haven't gotten around to it yet.)

Out of curiousity, is this then going to return the full
default style info as well, as a Tk widget would do?

Jeff

Re: [Tile-dev] Upcoming changes - compatibility options removed

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

> > Another upcoming change with a potential impact is that
> > [style default ...] is going to be renamed to the more
> > sensible [style configure ...].  (This should've been done a
> > long time ago, just haven't gotten around to it yet.)
>
> Out of curiousity, is this then going to return the full
> default style info as well, as a Tk widget would do?

[style default] and [style map] already work like other
"generalized accessors" -- [style default $style] returns
a dictionary of all specified option/value pairs, and
[style default $style -option] returns the current setting
for '-option' (or the empty string if none has been specified).

It doesn't (and won't) return a list of 5/2-tuples like
[$widget configure] does, since style settings aren't
implemented on top of Tk_OptionTables.  (Plus, the dictionary
representation is a lot easier for application code to
work with.)


--Joe English

  jen...@fl...

[Tile-dev] Upcoming changes - compatibility options removed

[Joe E. <jen...@fl...>]

Now in CVS: compatibility options are disabled by default.
`make clean` and recompile for this to take effect.

To turn them back on -- for now -- run "./configure --enable-compat",
or compile with "-DENABLE_COMPAT".  But be aware that this will
stop working soon too.

Another upcoming change with a potential impact is that
[style default ...] is going to be renamed to the more sensible
[style configure ...].  (This should've been done a long time ago,
just haven't gotten around to it yet.)


--Joe English

  jen...@fl...

[Tile-dev] Re: [TCLCORE] last call: TIP #248 "Integrate Tile into Tk as Ttk"

[Joe E. <jen...@fl...>]

[ I wrote ]
>  [...]
> Now would be a good time for Tk maintainers to review the tile
> codebase, just so y'all know what you're getting :-)  I'll write
> up an overview of the internals in the next couple of days.

Posted here: 

    <URL: http://tktable.sourceforge.net/tile/doc/internals.txt >


--Joe English

  jen...@fl...

[Tile-dev] Tcl/Tk 2005 Conference - Schedules available now, Registration is open

[<aku...@sh...>]

Tcl/Tk 2005 Conference Schedule & Registration
==============================================

The 12th Tcl/Tk Conference Schedules are available.

The tutorials and paper presentation schedules have been 
finalized and are available at:

http://www.tcl.tk/community/tcl2005/tut2005.html
http://www.tcl.tk/community/tcl2005/schedule.html

The abstracts for the selected papers are available at:

http://www.tcl.tk/community/tcl2005/abstracts.html

The conference dinner will be on Wednesday evening.  
Blueteam will be providing a social hour with drinks
and munchies on Thursday evening.

Registration is open for tutorials and technical 
sessions at:

http://www.tcl.tk/community/tcl2005/reg.html


Program Committee:
==================
 Donal  Fellows       University of Manchester
 Clif   Flynt         Noumena Corp.
 Ron    Fox           NSCL Michigan State University
 Jeff   Hobbs         ActiveState Corp.
 Steve  Landers       Digital Smarties
 Gerald Lester        HMS Software
 Cyndy  Lilagan       Eolas Technologies Inc.
 Arjen  Markus        WL | Delft Hydraulics

--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [Tile-dev] possible to detect click on image in a notebook tab?

[Mats B. <ma...@pr...>]

You can see how I made it in Coccinella:
http://coccinella.sf.net
http://hem.fyristorg.com/matben
See the chat dialog if you create more than one thread.
In short, I just did a ttk::label with a cross png image which is clickable,
and 'place'ed rightmost in the tab area. Not very nice if the tabs extend
to the right side, but is easy to modify.
I didn't see any other problems using place here.

Mats

Bryan Oakley wrote:
> 
> Is it possible to detect a click over the image of a ttk::notebook tab?
> I'm wanting to put a graphical (x) on each tab (ala safari) for
> dismissing the tab. I can display the image but I'm not sure how to go
> about making it active.
> 
> If that's not possible or planned, is there any way to add a clickable
> image in the right of the blank area reserved for tabs (ala firefox)
> other than by placing it with place, which sounds decidedly difficult to
> make work in a cross platform way?
> 
> Thanks.
>

Re: [Tile-dev] possible to detect click on image in a notebook tab?

[Joe E. <jen...@fl...>]

Bryan Oakley wrote:

> Is it possible to detect a click over the image of a ttk::notebook tab?
> I'm wanting to put a graphical (x) on each tab (ala safari) for
> dismissing the tab. I can display the image but I'm not sure how to go
> about making it active.

Not at present; one possibility would be to add an [$nb identify $x $y]
command that would return the tab index and element at position $x,$y.

See also #1168548 "Custom styles for complex widgets" -- you might
not be able to get the checkbox in just the right place since
custom styles for notebooks don't work right yet.

> If that's not possible or planned, is there any way to add a clickable
> image in the right of the blank area reserved for tabs (ala firefox)
> other than by placing it with place, which sounds decidedly difficult to
> make work in a cross platform way?

I'd like to be able to support this UI idiom as well, but haven't
thought of a good way to specify it yet.  Ideas?


--Joe English

  jen...@fl...

[Tile-dev] possible to detect click on image in a notebook tab?

[Bryan O. <oa...@ba...>]

Is it possible to detect a click over the image of a ttk::notebook tab? 
I'm wanting to put a graphical (x) on each tab (ala safari) for 
dismissing the tab. I can display the image but I'm not sure how to go 
about making it active.

If that's not possible or planned, is there any way to add a clickable 
image in the right of the blank area reserved for tabs (ala firefox) 
other than by placing it with place, which sounds decidedly difficult to 
make work in a cross platform way?

Thanks.

Re: [Tile-dev] Scale widget

[Jeff H. <je...@Ac...>]

Joe English wrote:
> I use the core [scale] widget a lot, and am perpetually
> frustrated by various quirks and irregularities, so
> I'd like to propose that the [ttk::scale] widget
> *not* be completely compatible with it :-)

While I tend to agree some widgets could be "fixed", this
is one of those that I have a hard time agreeing with.

Most of your arguments seem simply preferential, so my gut
response is ... making these changes will only make it
harder for Tk users to move between tk and ttk.  It may
well end up being just as head scratching for them each
time another person hits the subtle differences.

It really comes down to (and this will be true for other
widget design decisions at this point), what degree of
changes should we make to improve a widget, balanced
against the cost of confusion since classic Tk widgets
will remain the same.

> First: I think it's safe to desupport '-showvalue true'.
> No other toolkit uses this visual idiom that I'm aware of,
> and there are more effective ways to achieve the same effect.

Hmmm ... maybe, but unless you are saying that some native
toolkits simply have no support for it, I think we should
leave this in.  For example, I rewrote the vu::dial widget
and realized that it really is a scale with a different
look (several looks, actually).  There the showing of the
value can be very important regards to placement.

> The [scale] widget tends to invoke the -command at unusual
> times, and it's unpredictable when the linked -variable is
> adjusted to match -from, -to, and -resolution.  This makes it 
> difficult to use [scale]s as input/output widgets.
> 
> (Even worse: the behavior has changed between Tk 8.4 and
> the current CVS HEAD, and I can't find any clue as to why.)

Handling of rounding perhaps?

> Vertical [scale]s move the slider from the top of the widget
> to the bottom as the value changes between -from and -to.
> While this is consistent with Tk's coordinate system --
> the Y axis points downwards -- it runs contrary to user
> expectations.  IOW: horizontal scales should set -from=min
> and -to=max, while vertical scales should set -from=max
> and -to=min.  The [ttk::scale] widget should rectify this.

Hmmm, this seems like a perfect example of how to really
confuse people.  2 identically purposed widgets that use
different coord systems ...

> The scale has "-length" and "-width" options, where "-width"
> actually specifies the height of horizontal scales.  This 
> option should be renamed "-thickness" (or left out entirely 
> and let the theme decide, like the [ttk:scrollbar] does).

We need to control the thickness, I would think.  This is
a good example of changing something to improve clarity,
but -width is only confusing here in width/height, whereas
length/width is just as valid a name pairing.

> Finally: scale widgets and spinboxes have a similar function --
> both are "valuator" widgets -- so it would be a good idea to
> make the widget API's as similar as possible.

And a dial widget!  ;)

Jeff

[Tile-dev] Scale widget

[Joe E. <jen...@fl...>]

The [ttk::scale] widget is currently missing a few features
relative to the core [scale] widget.

I use the core [scale] widget a lot, and am perpetually
frustrated by various quirks and irregularities, so
I'd like to propose that the [ttk::scale] widget
*not* be completely compatible with it :-)

First: I think it's safe to desupport '-showvalue true'.
No other toolkit uses this visual idiom that I'm aware of,
and there are more effective ways to achieve the same effect.

The [scale] widget tends to invoke the -command at unusual
times, and it's unpredictable when the linked -variable is
adjusted to match -from, -to, and -resolution.  This makes it 
difficult to use [scale]s as input/output widgets.

(Even worse: the behavior has changed between Tk 8.4 and
the current CVS HEAD, and I can't find any clue as to why.)

Vertical [scale]s move the slider from the top of the widget
to the bottom as the value changes between -from and -to.
While this is consistent with Tk's coordinate system --
the Y axis points downwards -- it runs contrary to user
expectations.  IOW: horizontal scales should set -from=min
and -to=max, while vertical scales should set -from=max
and -to=min.  The [ttk::scale] widget should rectify this.

The scale has "-length" and "-width" options, where "-width"
actually specifies the height of horizontal scales.  This 
option should be renamed "-thickness" (or left out entirely 
and let the theme decide, like the [ttk:scrollbar] does).

Finally: scale widgets and spinboxes have a similar function --
both are "valuator" widgets -- so it would be a good idea to
make the widget API's as similar as possible.

Any other thoughts?


--Joe English

  jen...@fl...

Re: [Tile-dev] modified themes for labelframes

[Damon C. <dam...@tc...>]

> Were you trying to write something that passed the Snit test suite,
> or just an analogous framework?  If the former, is not 100% because
> of lack of time, or were there specific things you found you couldn't
> duplicate?  The subject of re-implementing Snit on top of XOTcl or
> something like it has indeed come up recently, and it's an interesting
> notion; I'm very curious to know what the gaps might be.


    To be honest, I started down the path of using SNIT-like syntax and
design along with some features I actually appreciated in BWidgets. 
Though I really hate BWidget's internals for designing widgets, there
were a few megawidget-specific things that it did that I liked.

    Specifically, the validation of widet options based on type was
something I found that SNIT didn't do.  At least not in the versions I
was using back when I started playing with this stuff.  I'll admit
that I haven't used SNIT in a while now because most of my work is
BWidget-related.

    The other thing that differs is the way options and methods are
defined.  This was mostly because the prior syntax in SNIT wasn't very
expandable, and I needed to add some options to it.  I know that you
were working on rewriting the syntax, but I haven't followed that
development.  We might be very close to each other now.

    Finally, I did not try AT ALL to duplicate much of SNIT's
functionality as an object system.  The framework that I wrote was
PURELY designed as a means for creating megawidgets using XOTcl.  I
felt that since it was already built on top of an object system, there
really wasn't much worth in me trying to duplicate SNIT completely.

    What I ultimately ended up with was what I wanted.  A megawidget
framework with SNIT-like syntax that is built on top of a C-based
object system.  I tested this by porting the BWidget ButtonBox over to
the new framework, and it works reasonably well.  I e-mailed you a
copy of what I had if you want to take a look at it.

    I'm willing to put in the effort to do a full conversion of BWidgets
to SNIT or any other OO system if one is included in the core of Tcl. 
Without that, I'm not interested.  I use BWidgets more than any other
library due to its pure-Tcl-ness (TM). 0-]

D


> Were you trying to write something that passed the Snit test suite,
> or just an analogous framework?  If the former, is not 100% because
> of lack of time, or were there specific things you found you couldn't
> duplicate?  The subject of re-implementing Snit on top of XOTcl or
> something like it has indeed come up recently, and it's an interesting
> notion; I'm very curious to know what the gaps might be.
>
> Will
>
> On Aug 12, 2005, at 10:45 AM, Jeff Hobbs wrote:
>
>> Damon Courtney wrote:
>>
>>>> Given the complexity of the rest ... I'm inclined to think that this
>>>> may well be more appropriate as a snidget (or xidget, should we do
>>>> xotcl widgets ;) ).  At some point, we have to draw the line for
>>>> where
>>>> we layer and where we hard-code.
>>>>
>>>
>>>     I had heard somewhere that 8.5 would include XOTcl as the
>>> object system with wrappers for Itcl and Snit?  Is that true?
>>>  I piddled around with a library a while back that was
>>> basically SNIT written in XOTcl.  I called it XWidgets. 0-]
>>> It wasn't 100% there, but pretty damn close. If anyone's
>>> interested, I can send it along somewhere.

Re: [Tile-dev] Difference between tile entry and old entry

[Joe E. <jen...@fl...>]

> I found what I think is a difference in the tile entry and I believe I
> have a small test case here:
>[ ... ]
> If you run the program as is, it works fine.  What should happen is
> when you click the button, the tv1 (text variable 1) is updated via the
> called routine, and the validate command should update the tv2 (text
> variable 2).

This is a known (intentional, and documented) difference.

See <URL: http://tktable.sourceforge.net/tile/doc/entry.html >,
section "VALIDATION", subsection "DIFFERENCES FROM TK ENTRY
WIDGET VALIDATION".  Summarizing, the main differences are:

    (1) ttk::entry widgets don't set '-validate none' if
        a validation script changes the value; and
    (2) setting the linked -textvariable doesn't trigger validation.

There are a couple other minor differences having to do with
when errors get reported (the core [entry] widget uses an idle
handler in some circumstances where the [ttk::entry] reports
them immediately), and [ttk::entry] widget validation has
some additional interactions with the 'invalid' widget state,
but those are the main ones that may impact existing code.

> Is this a bug?  It might be a design change and I should change my
> stuff.  I realize from reading the doc that having a textvariable and a
> validatecommand might be problematic.

As far as I know, the [ttk::entry] widget doesn't have any
problems if -textvariable and -validatecommand are both specified
(subject to #2, above).


--Joe English

  jen...@fl...