tktable-tile-dev — Discussion about tile development

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

[Joey M. <jo...@sw...>]

I found what I think is a difference in the tile entry and I believe I 
have a small test case here:

package require tile
# namespace import -force ttk::entry

global tv1 tv2
set tv1 ""
set tv2 ""

proc updatetv1 {} {
     global tv1
     set tv1 "This is Text 1"
}
proc updatetv2 {} {
     global tv2
     set tv2 "This is Text 2"
     return 1
}

entry .txt1 -width 40 -relief sunken -bd 2 -textvariable tv1 -bg white 
-validate key -validatecommand {updatetv2}
entry .txt2 -width 40 -relief sunken -bd 2 -textvariable tv2 -bg white
button .b1 -text "Update BOTH text fields" -command {updatetv1}

pack .txt1 .txt2 .b1 -side top

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).  If you uncomment the namespace import, the program no 
longer works.

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.

Joey

Re: [Tile-dev] modified themes for labelframes

[Will D. <wi...@wj...>]

Damon,

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.
>>
>
> I'm interested.
>
> Jeff
>
>

-------------------------------------------------------------
        will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills

RE: [Tile-dev] modified themes for labelframes

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

> I think I've convinced myself that [ttk::labelframe] ought
> to drop the -relief option altogether.  On CUA-descendant 
> platforms (Win2K/Motif/etc.), you almost always want "-relief 
> groove"; but "groove" is a totally inappropriate description 
> of how groupbox borders look on XP and OSX.
> 
> The theme engine could: (a) selectively ignore -relief values 
> that aren't appropriate for the platform; (b) DWIM ("you 
> asked for a grooved border, but that won't look right on a 
> Mac, so we'll just do a curvy shaded border instead"); or (c) 
> take it literally ("OK, you asked for -relief groove, I'll 
> draw a Motif border, even though this really won't look 
> right...").  Tile currently does a combination of these three 
> in various places; but it would be more in keeping with the 
> general philosophy to do (d) remove the "-relief" widget 
> option completely.

I think removing the -relief option should be done in concert
with improving the ability to adjust labelframe styles.  If
I can't remove the relief altogether (-relief flat), then it
restricts labelframe's usefulness.

> That's part of it; the other part is that "semi-transparent" 
> widgets like checkbuttons and radiobuttons appearing inside 
> the groupbox also need to have a darker background.

Right, they need to adapt from their parent ... the background
problem.  :/

Jeff

Re: [Tile-dev] modified themes for labelframes

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

Jeff Hobbs wrote:

> > At the
> > very least, they should be NULL by default so that custom styles
> > will work.
>
> I think some control of the border might be nice (like, if I
> have -bd 0, no border should really be drawn), but I'm torn
> on whether fiddling with relief and others is necessary.

That's the basic idea: if "-borderwidth" has a NULL default,
then the widget will use theme defaults unless the application
explicitly specifies a -borderwidth.  The way it is now,
it's as if the application has always specified "-borderwidth 2"
since that's the hardcoded widget default.

I think I've convinced myself that [ttk::labelframe] ought
to drop the -relief option altogether.  On CUA-descendant
platforms (Win2K/Motif/etc.), you almost always want
"-relief groove"; but "groove" is a totally inappropriate
description of how groupbox borders look on XP and OSX.

The theme engine could: (a) selectively ignore -relief values
that aren't appropriate for the platform; (b) DWIM ("you
asked for a grooved border, but that won't look right on
a Mac, so we'll just do a curvy shaded border instead");
or (c) take it literally ("OK, you asked for -relief groove,
I'll draw a Motif border, even though this really won't
look right...").  Tile currently does a combination of
these three in various places; but it would be more in
keeping with the general philosophy to do (d) remove
the "-relief" widget option completely.


> > Under OSX, the groupbox background gets
> > successively darker depending on the nesting level.  Tile
> > can't handle this at all right now (this is The Background Problem.)
>
> Isn't this the use of DrawThemeSecondaryGroup instead of
> DrawThemePrimaryGroup, where we only use the latter?

That's part of it; the other part is that "semi-transparent"
widgets like checkbuttons and radiobuttons appearing inside
the groupbox also need to have a darker background.


--Joe English

  jen...@fl...

RE: [Tile-dev] modified themes for labelframes

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

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.

I'm interested.

Jeff

Re: [Tile-dev] modified themes for labelframes

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

> 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.

Damon

RE: [Tile-dev] modified themes for labelframes

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

> > I'm porting more stuff to OS X, and finding that the alternate 
> > grouping controls (essentially labelframes) might be nice to have.  
> > See:
> >
> > http://developer.apple.com/documentation/UserExperience/Conceptual/
> >    OSXHIGuidelines/XHIGLayout/chapter_19_section_4.html

> In principal, yes, this ought to be possible with custom 
> styles, but it will be necessary to define a few new elements, and the 
> labelframe layout algorithm needs to be generalized a bit more.

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.

> This doesn't work at present, because the [ttk::labelframe]
> has non-NULL defaults for -relief and -borderwidth, which will 
> take precedence.  I'm starting to think that these should be removed 
> altogether (-relief in particular; Tk's standard set of 
> -relief values don't map onto platform-native border styles 
> very well).  At the 
> very least, they should be NULL by default so that custom styles 
> will work.

I think some control of the border might be nice (like, if I
have -bd 0, no border should really be drawn), but I'm torn
on whether fiddling with relief and others is necessary.

> Another groupbox style we ought to support is the BWidget 
> PanelFrame, where the label appears in a shaded box that 
> extends across the top of the frame.  This isn't possible 
> with the current layout algorithm, but it might work if the 
> "-labelanchor" option were extended to allow things like 
> "nwe" in addition to "n", "nw", and "ne".

Heh heh ... I wrote that widget too (for our PDK app).  I
was thinking about integrating that with superframe, but it
really does more (allowing you to add buttons into the panel
area, which really makes for nice UI).  I could see
supporting that for the other frame types too, but then I
would be forced to do the 'getframe' or 'setwidget' stuff
because I would need multiple frames.  With superframe, I
am really just a tricked out hull - you can put stuff right
in it and use it 100% the same as a regular frame.

> Then there's things like "disclosure boxes" (commonly used
> for e.g., "Show/Hide Advanced Options" sections in dialog 
> boxes). I think this is currently doable as a snidget, using 
> a custom [ttk::checkbox] as the -labelwidget.

Yes, I could see wanting a whitespace-style labelframe for that.

> And lastly: Under OSX, the groupbox background gets 
> successively darker depending on the nesting level.  Tile 
> can't handle this at all right now (this is The Background Problem.)

Isn't this the use of DrawThemeSecondaryGroup instead of
DrawThemePrimaryGroup, where we only use the latter?

Jeff

Re: [Tile-dev] modified themes for labelframes

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

Jeff Hobbs wrote:

> I'm porting more stuff to OS X, and finding that the alternate
> grouping controls (essentially labelframes) might be nice to
> have.  See:
>
> http://developer.apple.com/documentation/UserExperience/Conceptual/
>    OSXHIGuidelines/XHIGLayout/chapter_19_section_4.html
>
> We should be able to reproduce these in styles, but the current
> labelframe drawing disallows that.  It has a -borderwidth, but
> that is ignored for anything but adjusting the label inset (at
> size 0, it still draws the border, Windows and OS X).
>
> On OS X it seems that for drawing themed groupboxes, there is
> only the one API func.  So I'm wondering ... is this an
> instance of something tile styles should support,

In principal, yes, this ought to be possible with custom styles,
but it will be necessary to define a few new elements, and the 
labelframe layout algorithm needs to be generalized a bit more.

> Essentially, I want the option:
> 	labelframe .foo -style whitespace|bordered|separator

You can almost get the "Whitespace" style with:

    style default Flat.TLabelframe -relief flat -borderwidth 0

This doesn't work at present, because the [ttk::labelframe]
has non-NULL defaults for -relief and -borderwidth, which will 
take precedence.  I'm starting to think that these should be removed 
altogether (-relief in particular; Tk's standard set of -relief values
don't map onto platform-native border styles very well).  At the 
very least, they should be NULL by default so that custom styles 
will work.

([ttk::label]s have the same problem wrt. custom styles.  This
will be fixed in 0.7 when we drop attempted BWidget compatibility.)

For the "separator" style, it might work to define a
Separator.TLabelframe.border element that only draws one edge
of the border. 

Another groupbox style we ought to support is the BWidget
PanelFrame, where the label appears in a shaded box that
extends across the top of the frame.  This isn't possible
with the current layout algorithm, but it might work if
the "-labelanchor" option were extended to allow things like
"nwe" in addition to "n", "nw", and "ne".

Then there's things like "disclosure boxes" (commonly used
for e.g., "Show/Hide Advanced Options" sections in dialog boxes).
I think this is currently doable as a snidget, using a custom
[ttk::checkbox] as the -labelwidget.

See also: #1117281, which may be tangentially relevant.

And lastly: Under OSX, the groupbox background gets successively
darker depending on the nesting level.  Tile can't handle this
at all right now (this is The Background Problem.)


Other ideas?


--Joe English

  jen...@fl...

RE: [Tile-dev] alternate entry background?

[Techentin, R. W. <tec...@ma...>]

>     style map TEntry -fieldbackground {invalid #FF7777}
> 
> This doesn't work everywhere -- in particular, it will have
> no effect on Windows XP (since the EP_EDITTEXT theme part 
> always uses system colors, and there's no ETS_* flag
> corresponding to an "invalid" state).   "-foreground"
> ought to work in all themes AFAIK.

But that's not a WindowsXP limitation, is it?  My Firefox browser displays a
yellow background in the URL entry for secure connections.  It must be
possible to change the background on XP.

> I will adjust my use to use a red foreground rather 
> than the lightyellow bg for invalid that we had.  
> However, this isn't ideal for those cases where an 
> empty entry field is also not valid ...

Also don't forget that a red foreground is indistinguishable from a black
foreground for the small percentage of (mostly) guys who are color blind.

Bob
-- 
Bob Techentin                        tec...@ma... 
Mayo Foundation                                 (507) 538-5495 
200 First St. SW                            FAX (507) 284-9171
Rochester MN, 55901  USA            http://www.mayo.edu/sppdg/ 

RE: [Tile-dev] alternate entry background?

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

> Depending on the theme:
> 
>     style map TEntry -fieldbackground {invalid #FF7777}
> 
> This doesn't work everywhere -- in particular, it will have 
> no effect on Windows XP (since the EP_EDITTEXT theme part 
> always uses system colors, and there's no ETS_* flag
> corresponding to an "invalid" state).   "-foreground"
> ought to work in all themes AFAIK.

I will adjust my use to use a red foreground rather than
the lightyellow bg for invalid that we had.  However, this
isn't ideal for those cases where an empty entry field is
also not valid ...

Thanks,

Jeff

Re: [Tile-dev] alternate entry background?

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

I wrote:

> Also, for now you'll need to set [$e state invalid] / [$e state !invalid]
> by hand in the -validatecommand.
> (The ttk::entry widget should set the 'invalid' bit
> automatically whenever revalidation fails, I just haven't
> gotten around to implementing it yet. [...]

Just got around to implementing it; in CVS now (entry.c r1.31)

--Joe

[Tile-dev] RE: modified themes for labelframes

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

> I'm porting more stuff to OS X, and finding that the=20
> alternate grouping controls (essentially labelframes) might=20
> be nice to have.  See:

Since I couldn't find anything better to do for the last 2 hours,
I wrote what I wanted as a snidget.  I'm sure it still has issues,
but it "works" at the basic level.

Jeff

Re: [Tile-dev] alternate entry background?

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

Jeff Hobbs wrote:

> Is there any way to control the entry fieldbackground?  The
> use case (a pretty standard one) is to signify invalid data
> in the entry field.  I've played a bit with style mapping
> for a TEntry variant, but no luck ... is this possible yet?

Depending on the theme:

    style map TEntry -fieldbackground {invalid #FF7777}

This doesn't work everywhere -- in particular, it will have 
no effect on Windows XP (since the EP_EDITTEXT theme part 
always uses system colors, and there's no ETS_* flag
corresponding to an "invalid" state).   "-foreground"
ought to work in all themes AFAIK.

Hm... and just to cover all the bases, better do:

    style map TEntry \
    	-fieldbackground {invalid #FF7777} \
    	-background {invalid #FF7777} \
	;

since the various themes aren't completely consistent wrt. 
option names in 0.6.

Also, for now you'll need to set [$e state invalid] / [$e state !invalid]
by hand in the -validatecommand.

(The ttk::entry widget should set the 'invalid' bit
automatically whenever revalidation fails, I just haven't
gotten around to implementing it yet.  The other part of the
plan is for ttk::entry widgets to accept all edits whenever the
'invalid' bit is set, even when prevalidation fails, and to
automatically clear the bit when (re|pre)validation succeeds.
This will prevent "validation lockout" where you've got an
invalid value and can't make it valid with a single keystroke.)


--Joe English

  jen...@fl...

[Tile-dev] modified themes for labelframes

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

I'm porting more stuff to OS X, and finding that the alternate
grouping controls (essentially labelframes) might be nice to
have.  See:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIG=
uidel
ines/XHIGLayout/chapter_19_section_4.html

We should be able to reproduce these in styles, but the current
labelframe drawing disallows that.  It has a -borderwidth, but
that is ignored for anything but adjusting the label inset (at
size 0, it still draws the border, Windows and OS X).

On OS X it seems that for drawing themed groupboxes, there is
only the one API func.  So I'm wondering ... is this an
instance of something tile styles should support, or is this
something where a snidget is more appropriate?

Essentially, I want the option:

	labelframe .foo -style whitespace|bordered|separator

with other options (like -inset) for control of whitespace.
Currently tile only does bordered, while the classic labelframe
could improvise the whitespace variant (by asking for -relief
flat -bd 4 or something).  The separator would be tricky, but
possible (use classic labelframe with a widget, no border).

However, I'd like to this tile styles could handle this ...
ideas?

Jeff

Re: [Tile-dev] Heads up -- upcoming changes

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

Donal K. Fellows wrote:
> Mats Bengtsson wrote:
> 
>> It would be a good thing if tile could still be built as a shared lib 
>> even
>> when placed in the tk source tree. If you have read about my tclkit
>> adventures here and elsewhere you understand my motivitaion.
>> There can be reasons to use tile in earlier versions than 8.4.12?, 8.5b1?
> 
> 
> The only on-the-table plan for integrating Tile and Tk is a scheme for
> co-distribution. I see no reason for necessarily having Tk and Ttk
> widgets in the same library, just as I see no reason for having Tk in
> the same library as Tcl...

That is going to change, the integration will be in full for 8.5.
However, Joe has already noted that he plans to maintain an 8.4
compatible extension, which would address Mats' needs.

-- 
   Jeff Hobbs, The Tcl Guy
   http://www.ActiveState.com/, a division of Sophos

Re: [Tile-dev] Heads up -- upcoming changes

[Donal K. F. <don...@ma...>]

Mats Bengtsson wrote:
> It would be a good thing if tile could still be built as a shared lib even
> when placed in the tk source tree. If you have read about my tclkit
> adventures here and elsewhere you understand my motivitaion.
> There can be reasons to use tile in earlier versions than 8.4.12?, 8.5b1?

The only on-the-table plan for integrating Tile and Tk is a scheme for
co-distribution. I see no reason for necessarily having Tk and Ttk
widgets in the same library, just as I see no reason for having Tk in
the same library as Tcl...

Donal.

Re: [Tile-dev] Heads up -- upcoming changes

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

Another thing:

It would be a good thing if tile could still be built as a shared lib even
when placed in the tk source tree. If you have read about my tclkit
adventures here and elsewhere you understand my motivitaion.
There can be reasons to use tile in earlier versions than 8.4.12?, 8.5b1?

Mats

Joe English wrote:
> 
> I posted a tentative release schedule to comp.lang.tcl last week
> (which, for some reason, google groups doesn't have in the archive);
> but there's been talk recently about merging Tile into the core,
> so the previous tentative plan is no longer operative...
> 
> The immediate short-term goal is now to get the codebase in
> shape for integration.  Most of this will just be internal
> cleanups, but it will involve a few important user-visible
> changes.  Mainly: all of the transitional compatibility
> options are going away sooner rather than later.
> 
> The [ttk::progress] widget will also be removed shortly,
> (so if you haven't yet switched to the [ttk::progressbar],
> now would be a good time to do so...).  The "Step", "Clam",
> and possibly "Classic" themes are also going away, possibly
> to return as separate loadable extensions.
> 
> More changes later as I come across them.
> 
> --Joe English
> 
>   jen...@fl...
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Tile-dev] alternate entry background?

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

Is there any way to control the entry fieldbackground?  The
use case (a pretty standard one) is to signify invalid data
in the entry field.  I've played a bit with style mapping
for a TEntry variant, but no luck ... is this possible yet?

Jeff

RE: [Tile-dev] The ScrollBar Problem

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

Kevin Walzer wrote:
> I've been using Bryan Oakley's combobox on the Mac with a 
> horrible hack (a gif taken from a screenshot of a native Aqua 
> dropdown combobox arrow) because it has a native scrollbar, 
> but have been playing with Tile's combobox, where the 
> scrollbar looks wrong.
> 
> I've found that if I add this to the Tile combobox.tcl file:
> 
> if {[string equal [tk windowingsystem] "aqua"]} {
> ~    interp alias {} ::ttk::scrollbar {} ::scrollbar
> }
> 
> the scrollbar looks right. Consequently, I'm probably going 
> to move to using the Tile combobox, as it has similar 
> functionality to Bryan's.

This eliminates the ttk scrollbar totally, which isn't ideal.
I have already patched tile (in cvs) to use the regular
scrollbar on aqua for the combobox.

Jeff

Re: [Tile-dev] The ScrollBar Problem

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've got a related question...

I've been using Bryan Oakley's combobox on the Mac with a horrible hack
(a gif taken from a screenshot of a native Aqua dropdown combobox arrow)
because it has a native scrollbar, but have been playing with Tile's
combobox, where the scrollbar looks wrong.

I've found that if I add this to the Tile combobox.tcl file:

if {[string equal [tk windowingsystem] "aqua"]} {
~    interp alias {} ::ttk::scrollbar {} ::scrollbar
}

the scrollbar looks right. Consequently, I'm probably going to move to
using the Tile combobox, as it has similar functionality to Bryan's.

Is this worth a patch at SF? Where should I submit it? Or should I just
keep this in my own apps?


Cheers,

Kevin Walzer, PhD
WordTech Software
http://www.wordtech-software.com
http://www.kevin-walzer.com
sw at wordtech-software.com

Joe English wrote:
| Damon Courtney wrote:
|
|
|>    For "The Scrollbar Problem," couldn't you just accept that themes like
|>OS X and KDE don't want you to draw element-by-element and just draw
|>them as one, big thing when using those themes?  If I understand
|>correctly, the problem is that OS X and KDE provide APIs to draw
|>entire scrollbars but not smaller elements within them, right?  So, if
|>the user has chosen a theme with that limitation, just draw it that
|>way.
|
|
| That's more or less what I plan to do, the only question
| is where to put the logic.
|
|
| --Joe English
|
|   jen...@fl...
|
|
| -------------------------------------------------------
| SF.Net email is Sponsored by the Better Software Conference & EXPO
| September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
| Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
| Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
| _______________________________________________
| Tktable-tile-dev mailing list
| Tkt...@li...
| https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+nSVJmdQs+6YVcoRAmgbAJ9oLkhpnON2XaOnCKfqaFVtMFhVmACfXd5U
mfWyt4S4mNvudC6fBHqVhLY=
=/I/6
-----END PGP SIGNATURE-----

[Tile-dev] The ScrollBar Problem

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

Damon Courtney wrote:

>     For "The Scrollbar Problem," couldn't you just accept that themes like
> OS X and KDE don't want you to draw element-by-element and just draw
> them as one, big thing when using those themes?  If I understand
> correctly, the problem is that OS X and KDE provide APIs to draw
> entire scrollbars but not smaller elements within them, right?  So, if
> the user has chosen a theme with that limitation, just draw it that
> way.

That's more or less what I plan to do, the only question
is where to put the logic.


--Joe English

  jen...@fl...

RE: [Tile-dev] Heads up -- upcoming changes

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

Damon Courtney wrote:
> > Release 0.7.0 will follow shortly afterwards.  This is when all the 
> > BWidget compatibility hacks will be removed.  Hopefully by that time 
> > there will have been a new BWidget release with Tile integration done 
> > right (Damon?  Any progress on that?)
> 
>     The new BWidget release should be hitting a beta pretty 
> soon here. 
> Jeff said he had some stuff to commit, and I need to get his 
> in and call a freeze before merging all of my stuff.  Now 

I have commited my BWidgets changes that reflect tile
"awareness".  There are likely more fixes to come, but I
haven't even made them yet (like BWidgets dialogs need a
platform-awareness overhaul).

> we go a different route with this?  Turning on Ttk support in 
> BWidgets goes like this:
> 
> BWidget::use ttk

Mind you, I added (not documented):
	Widget::theme ?bool?

I don't mind the above either, but perhaps 'theme' instead of
'use' is better?  That way it can default to classic or something.

>     Should we use this to redefine the widget classes?  
> Should the Button class only inherit the options for what 
> it's actually using?  IE:
> 
> if {[BWidget::using ttk]} {

I have done some stuff like that, see font.tcl, statusbar.tcl
and scrollframe.tcl.  Those are only ones I used, but others
could be updated.  In some cases though, you just have to
punt/abort/port.  For example, if you use the BWidgets
ComboBox, then you should just replace it with a ttk one and
figure out the options changes.

>     I, personally, kinda' like having the options dummy'd out 
> in BWidgets because it lets BWidgets become a bridge between 
> Tk and Ttk.  I can specify all of my options including a 

Again, I'm against this due to the enhanced possibility of
bugs (as my previous Entry -vcmd example).

Jeff

RE: [Tile-dev] Heads up -- upcoming changes

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

> It's a feature I could live without quite easily though. This is only 
> one of maybe two times in my career when I wanted to do something 
> non-standard with a scrollbar.

But let's face it, those "1 or 2" times for such customizations
as a trough-enhanced scrollbar in a diff app *make* the app.
That is why it is important to have both simple, themed widgets
for the 90% solutions while still allowing users to get that
extra 10% that really makes their apps kick *ss.

Jeff

Re: [Tile-dev] Heads up -- upcoming changes

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

Damon Courtney wrote:
>     And, while I agree that that's REALLY cool, I don't think ANY of the
> "native" scrollbars will give you that kind of action.  Heck, even the
> current Tk scrollbar doesn't have that kind of customizability. 
> You're always going to have to roll your own for that.

Agreed. Though it would be Really Nice if it looked and acted just like 
a native scrollbar, save for the eye candy in the trough. Not mandatory 
just Really Nice.

One of tkdiff's minor failings, IMO, is the rather clunky emulation of a 
scrollbar (and hey, I wrote a bunch of that code so I'm largely dissing 
myself here...) I was pretty happy when I discovered I could use a style 
to draw in the trough but didn't have to worry about drawing the arrows 
or thumb myself. I've been blown away by tile for quite a while now, but 
that added a little extra wind :-)

It's a feature I could live without quite easily though. This is only 
one of maybe two times in my career when I wanted to do something 
non-standard with a scrollbar.

Re: [Tile-dev] Heads up -- upcoming changes

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

> One instance where it would be nice to "fiddle with the damn scrollbars"
> is in an application like tkdiff, which has a special scrollbar that has
> graphical elements (colored lines) in the trough.
>
> I was experimenting with this the other day and was able to use a
> dynamic photo image in the trough area. It was pretty neat having a
> "real" scrollbar with a drawable area in it.
>
> Admittedly, that's a fairly unique thing to do, and could be done other
> ways (such as how tkdiff does it today...).

    And, while I agree that that's REALLY cool, I don't think ANY of the
"native" scrollbars will give you that kind of action.  Heck, even the
current Tk scrollbar doesn't have that kind of customizability. 
You're always going to have to roll your own for that.

Damon