tktable-tile-dev — Discussion about tile development

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

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

> On OS X, I do fiddle with the Tile scrollbars, or rather, I call
> scrollbar instead of ttk::scrollbar, because the Tile scrollbars on OS X
> don't look right, whereas the standard Tk scrollbars are natively-drawn.
> It's a simple workaround. If the Tile scrollbars are still broken in the
> forthcoming versions, that is what I'll continue to do.

    Well, and that's exactly what I do.  It just doesn't make much sense
that if you used the THEMED widgets, you don't get a native scrollbar,
but if you use the NON-THEMED widgets, you do.  I know it's not an
easy problem to solve, and I'm forced to do the same thing.  I just
hope we can clear it up before it goes into 8.5.  I'd also REALLY love
to see tile-qt get bumped up to tier 1, so to speak.

Damon

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

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

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.  How many people fiddle with the damn scrollbars anyway?  I don't
> think I've ever changed a scrollbar option outside of -orient.

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

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

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

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



Damon Courtney wrote:

| 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.  How many people fiddle with the damn scrollbars anyway?
|

On OS X, I do fiddle with the Tile scrollbars, or rather, I call
scrollbar instead of ttk::scrollbar, because the Tile scrollbars on OS X
don't look right, whereas the standard Tk scrollbars are natively-drawn.
It's a simple workaround. If the Tile scrollbars are still broken in the
forthcoming versions, that is what I'll continue to do.

Cheers,

Kevin Walzer, PhD
WordTech Software
http://www.wordtech-software.com
http://www.kevin-walzer.com
sw at wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFC+k/JJmdQs+6YVcoRAlX+AJwLFoLK4wJ/2EAe5xwyXst8E93X1QCXXSjd
BxofCIxK602YY57gRxWmVg==
=Ir64
-----END PGP SIGNATURE-----

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

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

> 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 that I have a clear
roadmap for Ttk, I can make all the needed modifications to BWidget to
finish off the support.  After the first iteration, some of the
options still look at Tk resources for their values, which was fine
when Ttk was still including dummy options, but now that they're going
away, I need to make sure BWidget's use of them does too.

    As far as Ttk support in widgets goes, I have some basic stuff going
on that should work decently well, but it basically mimics some of the
(unwanted?) behavior that Ttk has now.  Like a Button, for example,
has a new -style option that will pass on to Ttk, but it still has all
the rest of the options that just don't do anything.  So, you can do:

Button .b -background white -foreground black -style Style

    And if you're using Ttk, the style option does something while the
other two do nothing, but if you're not using Ttk, the style option
does nothing and the other two do.  Should we go a different route
with this?  Turning on Ttk support in BWidgets goes like this:

BWidget::use ttk

    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]} {
    ## Define Ttk options for the button class
    Widget::declare Button ...
} else {
    ## Define using normal options.
    Widget::declare Button ...
}

    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 style, and if I've chosen to
turn on Ttk support for this platform, it will draw using Ttk, and if
I've chosen not to turn it on, I don't have to rewrite anything.  The
BWidget Button will just do the right thing.

    Opinions?  Jeff?

> [ Explanation: (1) is why the contents of [ttk::notebook]s don't
>   look right on Windows XP, and why nothing really looks right
>   under OSX.  (2) is why Tile still doesn't have native-looking
>   scrollbars in the aqua and tile-qt themes.  (3) is why e.g.
>   a ttk::frame inside a core toplevel often have different
>   colors on X11.   (3) is almost solved; (1) and (2) still
>   have me stumped. ]

    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.  How many people fiddle with the damn scrollbars anyway?  I don't
think I've ever changed a scrollbar option outside of -orient.

Damon

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

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

[ I 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);

For those who didn't see it, here it is again:

-----
Newsgroups: comp.lang.tcl
Subject: Tile release schedule (WAS Re: tile: bug in paned widget?)
Date: 5 Aug 2005 11:31:52 GMT
Message-ID: <dcv...@ne...>
References: <QSMHe.2375$6D...@ne...> <dco...@ne...> <6ou...@co...>

Bugs wrote:

>Would there happen to be a new release of Tile on the near horizon?  =)

Not on the near horizon, but probably before October.

Current goals are to get all of the ttk::treeview bugs fixed
for 0.6.6 (and any new ttk::combobox bugs that pop up --
all known bugs have been fixed, but from experience it's
a safe bet that more are lurking :-(.

I also want to get ttk::dialog and related routines into 
their final form, and integrate the (really nice!) file 
selection dialogs that Schelte Bron contributed.  These 
might go into 0.6.6, or there might be a 0.6.8 release too.

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?)

Somebody (maybe me) is eventually going to implement a spinbox widget;
that might show up in the 0.6 series (if somebody else does it :-)
or the 0.7 series.

After that: the 8.4-compatibility options have to go away at some 
point before Tile 1.0.  This is going to cause some pain for
early adopters who used the [namespace import] trick to convert
existing applications, so I'm reluctant to do it, but it will 
happen either at 0.8.0 or 0.9.0.

The other things that need to happen before 1.0 are: (1) solve 
The Background Problem; (2) solve The Scrollbar Problem; and 
(3) solve The Color Mismatch Problem.

[ Explanation: (1) is why the contents of [ttk::notebook]s don't
  look right on Windows XP, and why nothing really looks right
  under OSX.  (2) is why Tile still doesn't have native-looking
  scrollbars in the aqua and tile-qt themes.  (3) is why e.g.
  a ttk::frame inside a core toplevel often have different
  colors on X11.   (3) is almost solved; (1) and (2) still
  have me stumped. ]


--Joe English

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

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

Jeff Hobbs wrote:

> Just going through the demos again, aside from the scrollbars,
> I don't see much improvement over a mix of Default and
> Revitalized.  The clipped corners seems ok for some things
> (like the entry), but the button looks ill-defined.  Of the
> three, here are my unix prefs (and maybe now is the time to
> mix/match the "best" default): [...]

Sounds reasonable, but we should also consider what the
rest of the desktop looks like.

The "Clam" theme was designed to match (what was at the time)
the default XFCE theme, and "default" is designed to match the
Gnome "Simple" theme.  "Clam" is also a reasonable, though not 
great, match for ClearLooks.  Similarly "default" is a reasonable 
match for most members of the Mist family.

Another design goal for the "default" theme is that it should
be as plain and simple as possible; no graphical elements should
clash with anything else on the desktop.  "default" doesn't need
to be the default theme on X11, but the root theme does need to
be clean and featureless (no grips, no fancy borders, etc.)

I'm working -- slowly -- on themes that will match BlueCurve,
Galaxy, and a couple of the standard KDE themes.  Work in progress
in the DARCS repository here:

    <URL: http://www.flightlab.com/~joe/repos/themebag >

[ As an aside to the Windows and OSX users -- "Clam" et al. really
  need to be seen under X11.  Due to numerous small glitches
  in Tk's Xlib emulation layer that just aren't worth working
  around right now, Clam looks like utter crap on Windows
  and the Mac. ]

> > >>> The "Step", "Clam", and possibly "Classic" themes
> > >>> are also going away, possibly to return as separate loadable
> > >>> extensions.
>
> Will this save us lots of code?

In the end, not a whole lot, but it will save a lot of
grunt-work in the meantime if we can reduce the number
of themes to be maintained moving forward.  If we're going
to support all the different L&F that I'd like to support,
I think a different approach is needed (see themebag,
above -- the basic idea is to make it easier to assemble
a theme out of a large stock collection of predefined
graphical elements).


--Joe English

  jen...@fl...

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

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

>     Where can one get this "revit" theme?

"revit" == "revitalized"

Abbrvtns-R-Us
-- 
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] Heads up -- upcoming changes

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

    Where can one get this "revit" theme?

Damon

> I would say overall, I like clam, default, revit, in
> that order. Here is my list:
>
>  Radio/Checkbuttons:  clam,revit
>  normal buttons:      clam,default
>  notebook:            revit
>  scrollbar:           clam, default
>  scale:               clam, revit
>  progressbar:         revit, default
>  labelframe:          default/revit
>  entry:               clam,default
>  menubutton:          revit (arrow, not fat bd), clam
>  general colors:      all are ok
>  tree:                default,clam
>
>
> --brett
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
>
> -------------------------------------------------------
> 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
>

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

[Brett S. <bre...@ya...>]

I would say overall, I like clam, default, revit, in
that order. Here is my list:

 Radio/Checkbuttons:  clam,revit
 normal buttons:      clam,default
 notebook:            revit
 scrollbar:           clam, default
 scale:               clam, revit
 progressbar:         revit, default
 labelframe:          default/revit
 entry:               clam,default
 menubutton:          revit (arrow, not fat bd), clam
 general colors:      all are ok
 tree:                default,clam


--brett


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

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

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

Steve Landers wrote:
> Fourth

-1.  See below ...

> On 10/08/2005, at 10:35 PM, Damon Courtney wrote:
> >     Third.  Clam was the only one on UNIX that actually looked decent. 
> > I've never really cared for its darker color scheme, but I definitely 
> > appreciate the softer, more-rounded look of it all.  My multiplatform 
> > stuff definitely uses Clam as the default on UNIX systems until 
> > something better comes along.

> >> Mats Bengtsson <ma...@pr...> wrote:
> >> Why is "Clam" going away? To me this is definitely the best looking 
> >> theme on unix. Very clean and with soft contrasts.

Just going through the demos again, aside from the scrollbars,
I don't see much improvement over a mix of Default and
Revitalized.  The clipped corners seems ok for some things
(like the entry), but the button looks ill-defined.  Of the
three, here are my unix prefs (and maybe now is the time to
mix/match the "best" default):

Radio/Checkbuttons:  revit (clam is close)
normal buttons:      default
notebook:            revit
scrollbar:           clam (like the [|||] handle)
scale:               clam (like the [|||] handle)
progressbar:         default
labelframe:          default/revit
entry:               default (maybe clam)
menubutton:          revit (like arrow, don't like fat bd)
general colors:      NOT clam
tree:                default

> >> Joe English wrote:
> >>> will involve a few important user-visible changes. Mainly: all of 
> >>> the transitional compatibility options are going away sooner rather 
> >>> than later.

FWIW, this is a good, albeit short-term painful thing.  I had
a bug in our code because -vcmd for entries wasn't supported,
only the extended -validatecommand, although nothing complained.
This is *bad* when trying to "port" code.  On a side note, I do
question why we can't keep the shorter opt names.  I lk to abbr
thgs.

> >>> The "Step", "Clam", and possibly "Classic" themes 
> >>> are also going away, possibly to return as separate loadable 
> >>> extensions.

Will this save us lots of code?  I do prefer the idea that we
strengthen the "default" look.  Less can be more (as we've
seen in options, choice can paralyze).  However, I would want
to encourage focus on whatever can make the unix side pick up
either kde and/or gnome looks.

Jeff

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

[Steve L. <st...@Di...>]

Fourth

On 10/08/2005, at 10:35 PM, Damon Courtney wrote:

>     Third.  Clam was the only one on UNIX that actually looked decent.
> I've never really cared for its darker color scheme, but I definitely
> appreciate the softer, more-rounded look of it all.  My multiplatform
> stuff definitely uses Clam as the default on UNIX systems until
> something better comes along.
>
> Damon
>
>
>
>> I'll second that. Clam was for me the obvious choice on Linux.
>>
>> Mark
>>
>>
>> Mats Bengtsson <ma...@pr...> wrote:
>> Why is "Clam" going away? To me this is definitely the best looking
>> theme on unix. Very clean and with soft contrasts.
>>
>> 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.
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> 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
>>
>>
>>
>> ---------------------------------
>> Yahoo! Mail for Mobile
>>  Take Yahoo! Mail with you! Check email on your mobile phone.
>>
>
>
>
>
> -------------------------------------------------------
> 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
>

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

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

    Third.  Clam was the only one on UNIX that actually looked decent. 
I've never really cared for its darker color scheme, but I definitely
appreciate the softer, more-rounded look of it all.  My multiplatform
stuff definitely uses Clam as the default on UNIX systems until
something better comes along.

Damon


> I'll second that. Clam was for me the obvious choice on Linux.
>
> Mark
>
>
> Mats Bengtsson <ma...@pr...> wrote:
> Why is "Clam" going away? To me this is definitely the best looking
> theme on unix. Very clean and with soft contrasts.
>
> 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.
>>
>
>
> -------------------------------------------------------
> 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
>
>
>
> ---------------------------------
> Yahoo! Mail for Mobile
>  Take Yahoo! Mail with you! Check email on your mobile phone.

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

[Mark G. <du...@ya...>]

I'll second that. Clam was for me the obvious choice on Linux.

Mark


Mats Bengtsson <ma...@pr...> wrote:
Why is "Clam" going away? To me this is definitely the best looking
theme on unix. Very clean and with soft contrasts.

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


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


		
---------------------------------
Yahoo! Mail for Mobile
 Take Yahoo! Mail with you! Check email on your mobile phone.

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

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

Why is "Clam" going away? To me this is definitely the best looking
theme on unix. Very clean and with soft contrasts.

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

[Tile-dev] Heads up -- upcoming changes

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

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

Re: [Tile-dev] Windows builds pre 8.4.6

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

I was finally able to build a 8.4.1 based tclkit with tile statically linked
on Windows.

I have put it all at: http://coccinella.sf.net/tclkits/
which includes a How To README file, various things needed,
and prebuilt tclkits:
http://coccinella.sf.net/tclkits/tclkit-tile.exe
http://coccinella.sf.net/tclkits/tclkit-tile.upx.exe

Read all about it at: http://coccinella.sf.net/tclkits/README

Mats


Mats Bengtsson wrote:
> 
> Update:
> 
> Joe English wrote:
> >
> > Mats Bengtsson wrote:
> > >
> > > I'm squezzed between the fcopy bug in post 8.4.1 tclkits on Windows
> > > (https://sourceforge.net/tracker/?func=detail&atid=110894&aid=719790&group_id=10894)
> > > and building tile to work with tclkit 8.4.1
> > > (http://sourceforge.net/mailarchive/forum.php?thread_id=7358857&forum_id=42051)
> >
> > I have a strong suspicion that this just plain isn't going to work.
> >
> > You can try building Tile against 8.4.1 headers;
> > use 8.4.1 headers and -DNO_PRIVATE_HEADERS;
> > or use 8.4.1 headers, -DNO_PRIVATE_HEADERS, and take out -DUSE_TK_STUBS.
> >
> > If you can successfully build a .DLL with any of these three
> > approaches, and an 8.4.1 tclkit.exe can successfully [load]
> > the DLL, it ought to work just fine.  However, I'd be very
> > surprised if an 8.4.1 tclkit.exe will be able to [load] them.
> >
> 
> True. It doesn't.
> If I build Tcl/Tk 8.4.1 from scratch, and build tile with:
> 
> nmake -f makefile.vc TCLDIR=..\..\tcl8.4.1 TKDIR=..\..\tk8.4.1 INSTALLDIR=C:\Tcl OPTS=nostubs
> 
> (note relative paths to avoid spaces; nostubs doesn't add -DUSE_TK_STUBS)
> then I can load (and run) tile into the standard 8.4.1 wish, but if loading it into
> 8.4.1 tclkit-win32.exe it crashes the first time I'm creating a ttk widget.
> 
> The combination of tile require 8.4.6 and the post 8.4.1 fcopy bug
> makes tile useless for tclkits on Windows (at least if you are using network stuff).
> This is very bad. It seems to me that it is necessary to build the starkit and link
> tile statically, but this is way above my head.
> Or any other suggestions.
> 
> Mats
> 
> PS: this is a real nightmare...
> 
> > Compiling against 8.4.9 headers and loading into an 8.4.1 interp
> > will definitely make things crash.
> >
> > --Joe English
> >
> >   jen...@fl...
> >
> > > I'm doing:
> > > nmake -f makefile.vc tile OPTS=nostubs
> > > on VC7
> > > and
> > > nmake -f makefile.vc tile OPTS=nostubs,nouxtheme
> > > on VC6
> > > Using an ordinary 8.4.9 installation which is probably wrong
> > > since the tclkit still crashes.
> > > Perhaps someone can give me a clue of how to proceed before
> > > I continue my experimentation.
> >
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

Re: [Tile-dev] Windows builds pre 8.4.6

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

Update:

Joe English wrote:
> 
> Mats Bengtsson wrote:
> >
> > I'm squezzed between the fcopy bug in post 8.4.1 tclkits on Windows
> > (https://sourceforge.net/tracker/?func=detail&atid=110894&aid=719790&group_id=10894)
> > and building tile to work with tclkit 8.4.1
> > (http://sourceforge.net/mailarchive/forum.php?thread_id=7358857&forum_id=42051)
> 
> I have a strong suspicion that this just plain isn't going to work.
> 
> You can try building Tile against 8.4.1 headers;
> use 8.4.1 headers and -DNO_PRIVATE_HEADERS;
> or use 8.4.1 headers, -DNO_PRIVATE_HEADERS, and take out -DUSE_TK_STUBS.
> 
> If you can successfully build a .DLL with any of these three
> approaches, and an 8.4.1 tclkit.exe can successfully [load]
> the DLL, it ought to work just fine.  However, I'd be very
> surprised if an 8.4.1 tclkit.exe will be able to [load] them.
> 

True. It doesn't. 
If I build Tcl/Tk 8.4.1 from scratch, and build tile with:

nmake -f makefile.vc TCLDIR=..\..\tcl8.4.1 TKDIR=..\..\tk8.4.1 INSTALLDIR=C:\Tcl OPTS=nostubs

(note relative paths to avoid spaces; nostubs doesn't add -DUSE_TK_STUBS)
then I can load (and run) tile into the standard 8.4.1 wish, but if loading it into
8.4.1 tclkit-win32.exe it crashes the first time I'm creating a ttk widget.

The combination of tile require 8.4.6 and the post 8.4.1 fcopy bug 
makes tile useless for tclkits on Windows (at least if you are using network stuff). 
This is very bad. It seems to me that it is necessary to build the starkit and link 
tile statically, but this is way above my head.
Or any other suggestions.

Mats

PS: this is a real nightmare...

> Compiling against 8.4.9 headers and loading into an 8.4.1 interp
> will definitely make things crash.
> 
> --Joe English
> 
>   jen...@fl...
> 
> > I'm doing:
> > nmake -f makefile.vc tile OPTS=nostubs
> > on VC7
> > and
> > nmake -f makefile.vc tile OPTS=nostubs,nouxtheme
> > on VC6
> > Using an ordinary 8.4.9 installation which is probably wrong
> > since the tclkit still crashes.
> > Perhaps someone can give me a clue of how to proceed before
> > I continue my experimentation.
>

Re: [Tile-dev] Windows builds pre 8.4.6

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

Mats Bengtsson wrote:
> 
> I'm squezzed between the fcopy bug in post 8.4.1 tclkits on Windows
> (https://sourceforge.net/tracker/?func=detail&atid=110894&aid=719790&group_id=10894)
> and building tile to work with tclkit 8.4.1
> (http://sourceforge.net/mailarchive/forum.php?thread_id=7358857&forum_id=42051)

I have a strong suspicion that this just plain isn't going to work.

You can try building Tile against 8.4.1 headers;
use 8.4.1 headers and -DNO_PRIVATE_HEADERS;
or use 8.4.1 headers, -DNO_PRIVATE_HEADERS, and take out -DUSE_TK_STUBS.

If you can successfully build a .DLL with any of these three
approaches, and an 8.4.1 tclkit.exe can successfully [load]
the DLL, it ought to work just fine.  However, I'd be very 
surprised if an 8.4.1 tclkit.exe will be able to [load] them.

Compiling against 8.4.9 headers and loading into an 8.4.1 interp
will definitely make things crash.


--Joe English

  jen...@fl...

> I'm doing: 
> nmake -f makefile.vc tile OPTS=nostubs
> on VC7
> and 
> nmake -f makefile.vc tile OPTS=nostubs,nouxtheme
> on VC6
> Using an ordinary 8.4.9 installation which is probably wrong
> since the tclkit still crashes.
> Perhaps someone can give me a clue of how to proceed before
> I continue my experimentation.

[Tile-dev] Windows builds pre 8.4.6

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

I'm squezzed between the fcopy bug in post 8.4.1 tclkits on Windows
(https://sourceforge.net/tracker/?func=detail&atid=110894&aid=719790&group_id=10894)
and building tile to work with tclkit 8.4.1
(http://sourceforge.net/mailarchive/forum.php?thread_id=7358857&forum_id=42051)

I'm doing: 
nmake -f makefile.vc tile OPTS=nostubs
on VC7
and 
nmake -f makefile.vc tile OPTS=nostubs,nouxtheme
on VC6
Using an ordinary 8.4.9 installation which is probably wrong
since the tclkit still crashes.
Perhaps someone can give me a clue of how to proceed before
I continue my experimentation.

Mats

Re: [Tile-dev] New feature: ttk::dialog

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

Damon Courtney wrote:
> [...]
> Of course, I'm not exactly sure how to name that dialog.
> 
> MessageDlg .m -type yesnonotallyestoallcancel
> 
>     Just doesn't seem like the right thing to do. 0-]
> 

Great googly moogly no, that wouldn't be right at all :-)

I think the approach taken by [ttk::dialog] is pretty close --
it's not *exactly* the right thing (I don't like the -labels
option much), but it's close.  In particular, taking an
open-ended list of -buttons, and making '-type' a 
shorthand/compatibility feature that specifies a 
predefined set of other option/value pairs seems to me
like a pretty good way of doing things.

Take a look at the the (undocumented) ttk::dialog::stockButton 
and ttk::dialog::stockDialog procedures for ideas -- and
if you can improve on them, let me know :-)

--Joe English

  jen...@fl...

RE: [Tile-dev] Treeview column auto-resize

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

> The widget *should* behave the way you describe by default; 
...
> Sorry for the inconvenience,

No sweat, Joe.  That's just one of the "features" of pre-1.0.  I just wasn't
sure if I was mis-using the widget.

Thanks,
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] Treeview column auto-resize

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

Techentin, Robert W.  wrote:

> I placed a single-column ttk::treeview into a ttk::paned, and I wanted to
> make the column resize to the width of the widget when the pane changed.
> 
> I find that if I change the column width programattically,
> 
>   $tv column #0 -width 200
> 
> Then the widget size changes.  But if I drag the pane sash, the column
> remains the same size.  I thought I could be clever and tried binding to the
> widget's Configure event, but that created an auto-expanding column and
> widget.
> 
> Is there a way to make a treeview column expand when the widget size changes
> from an external event?

The ttk::treeview column autosizing is still terribly buggy --
it's better than before, but still not right.

The widget *should* behave the way you describe by default; 
that it doesn't currently is a bug.  This is on the "must fix"
list for 0.7; if you can live with the current behavior for now
I'd recommend not doing anything special in the application
to work around it.  If you can't, I'll try to think of something :-)

Sorry for the inconvenience,


--Joe English

  jen...@fl...

RE: [Tile-dev] New feature: ttk::dialog

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

> Damon Courtney wrote:
>>     Actually, I'm adding this type of feature to the BWidget
>> Dialogs (and the new ChooseDirectory widget).  I just added a
>> -name option to the dialogs that would provide a name for the
>> dialog, and they remember state from the last instance.  Example:
>>
>> ChooseDirectory .d -name OpenImage
>>
>>     That way, even though choosing a directory can be done in
>> many different places throughout an application, each one
>> remembers its state.  I like this better than a global state
>> because I like to remember where the user was last when the
>> clicked this particular dialog.
>
> Isn't this redundant to the '.d' name already?  If they reuse
> .d without destroying it, it should keep the info, otherwise
> they would have another named CD dialog, no?


    Actually, the real purpose of the -name attribute is to make it easier
to create dialogs with a user state.  IE:

Yes, No, No to All, Yes to All, Cancel

    The user clicks "No to All," and the dialog remembers that based on
the name of the dialog.  Then, any subsequent calls to create a dialog
with that name just immediately return a No.  Of course, I'm not
exactly sure how to name that dialog.

MessageDlg .m -type yesnonotallyestoallcancel

    Just doesn't seem like the right thing to do. 0-]

D

[Tile-dev] Treeview column auto-resize

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

I placed a single-column ttk::treeview into a ttk::paned, and I wanted to
make the column resize to the width of the widget when the pane changed.

I find that if I change the column width programattically,

  $tv column #0 -width 200

Then the widget size changes.  But if I drag the pane sash, the column
remains the same size.  I thought I could be clever and tried binding to the
widget's Configure event, but that created an auto-expanding column and
widget.

Is there a way to make a treeview column expand when the widget size changes
from an external event?

Thanks,
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/ 

[Tile-dev] "Thickness" of progressbars

[Joi O. <jo...@ya...>]

Is there a way of increasing the "thickness" of a
ttk::progressbar? That is, increase the height for
horizontal progressbars and the width for vertical
ones. The default one is too small for WindowsXP and
OSX and does not look fully native.

Thanks!



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com