tktable-tile-dev — Discussion about tile development

[Tile-dev] Tile-aware treectrl

[Tim B. <tre...@ho...>]

I've been looking into a tile version of treectrl. Using treeview as
a guide, I end up needing the following things exported:

RegisterWidget -> Ttk_RegisterWidget?

Ttk_CreateSublayout
Ttk_DrawLayout
Ttk_FreeLayout
Ttk_LayoutFindNode
Ttk_LayoutNodeInternalParcel
Ttk_LayoutSize
Ttk_PlaceLayout
Ttk_RebindSublayout
TtkRedisplayWidget
TtkResizeWidget
TtkWidgetCgetCommand
TtkWidgetConfigureCommand
TtkWidgetInstateCommand

ttkCoreOptionSpecs

Some widgets may need these:
TtkWidgetDoLayout
TtkWidgetGetLayout

Also, there should be some way for a widget to specify that it
does not want to be double-buffered. For large-area widgets like
treectrl it isn't very efficient (and treectrl already does
double-buffering). Also, on composited desktops (OSX, Vista)
isn't every toplevel already double-buffered?

A [ttk::style names] command would be nice for getting the
names of existing styles, like [ttk::style theme names] and
[ttk::style element names].

-- Tim Baker

Re: [Tile-dev] Tile merged into the core

[Eckhard L. <ec...@we...>]

Joe English schrieb:
> Consequently: any existing programs that call [package require tile]
> will fail when run with Tk CVS HEAD on ELF-based systems.
>
> Windows (and, I believe, OSX) aren't affected, since shared
> libraries work differently there.
>   

Indeed this is happening on Windows - on Linux I haven't tried so far. 
Anyway, it seems that I must find some workaround when the time has come 
to upgrade.

Thank you for the info..


Eckhard

Re: [Tile-dev] Tile merged into the core

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

Eckhard Lehmann wrote:
>
> I checked out the latest Tk version (the one that includes tile) and
> encountered several - for me major - problems while running a tile'd
> program:
>
> - the [style] command has vanished - it is [ttk::style] now [...]
> - The ttk::treeview vanished somehow [...]

Tile 0.8.0 will have a transition strategy for all the
public routines that got renamed; and will still include
the treeview widget.

I'd recommend including both in the Tk 8.5 beta, but that's
up to Jeff.

> Another problem is that Tk8.5a6 (the cvs version) conflicts with an
> installed tile distribution and [package re tile]. I didn't get this to
> run. Even if I don't do [package re tile], there comes an error "can not
> find a usable tile.tcl in the following directories..."

OK, here's what's happening:

Tk 8.5a6 does not provide (in the sense of [package provide])
"tile" or "Ttk" packages, so [package require tile] ends up
loading tile.so and calling Tile_Init().

Tile_Init() in turn calls Ttk_StylePkgInit(); however, on
ELF-based systems, this gets resolved to the version of the
routine in the core, not the version in tile.so.  Since the
core provides an API that's incompatible with Tile 0.7.X,
the scripts in $::tile::library raise an error.  (This might
cause other problems as well, but that's the main one).

Consequently: any existing programs that call [package require tile]
will fail when run with Tk CVS HEAD on ELF-based systems.

Windows (and, I believe, OSX) aren't affected, since shared
libraries work differently there.


--Joe English

  jen...@fl...

Re: [Tile-dev] Tile merged into the core

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

Joe English wrote:
> Georgios Petasis wrote:
> > Will changes in 8.5 tile be backported to 8.4 tile package?
>=20
> It'll probably go the other way around, at least initially --=20
> new development will continue in Tile CVS HEAD, and changes=20
> will get forward-ported to 8.5 once stable.
>=20
> At least that's how I think it'll work.  Or maybe I'll just

It will probably be a bit of a mix until 8.5b1, when we settle on what =
"public
Ttk" looks like.  Then it will likely be as Joe notes above.

Jeff

Re: [Tile-dev] Tile merged into the core

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

Georgios Petasis wrote:
>
> While this is definitely good news, I got a little worried about the the
> themed parts
> changes (for the tileqt extension :-)). Tileqt parts are tightly related
> to the ones defined by tile, so any changes will affect also tileqt. So,
> what is the plan now?

Current plan: I'm in the middle of re-syncing the Tile and
core codebases, and trying to figure out a reasonable way to
keep them in sync in future.

The Tile 0.8.0 release will match the API in Tk 8.5b1, and
will also include deprecated aliases for the benefit of
code written against the 0.7.* API.

Then I plan to get back to what I was doing re: theme reorganization.

> Is tile going to remain a separate package for Tk 8.4 only?

I plan to continue to maintain Tile as an 8.4-compatible package
for as long as Tk 8.4 remains a viable platform.  Once 8.5 is
released and widely available, and 8.4 is EOLed, Tile as a separate
package will also go into maintenance-only mode.  (That should
take a couple years; hopefully by then it'll be finished :-)

> Will changes in 8.5 tile be backported to 8.4 tile package?

It'll probably go the other way around, at least initially --
new development will continue in Tile CVS HEAD, and changes
will get forward-ported to 8.5 once stable.

At least that's how I think it'll work.  Or maybe I'll just
do everything in a GIT repository and push out parallel patches.
I really don't know yet.

> Or is the 8.4 tile package considered "feature complete", and only bug
> fix releases will happen from now on?
> I am asking because tileqt must follow a similar scheme :-)

For tileqt: in principle, if you build against core 8.4 headers and
link with the Tile stub library, the resulting binary should
be loadable into wish8.4+tile.so and into wish8.5 equally well.
(The latter doesn't work at the moment, the stubs mechanism
got broken during the merge, but it'll get fixed once I figure
out how.)


--Joe English

  jen...@fl...

[Tile-dev] Tile merged into the core

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

In case anyone missed the announcement, Jeff recently
merged Tile into the Tk core, as per TIP#248:

    http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3321550

In the next couple of days I plan to backport the changes
into the Tile CVS repository to bring the two codebases
back into sync.  There are a number of incompatible changes
(mostly concerning procedures in the tile::* namespace),
so expect some instability in CVS HEAD.


--Joe

[Tile-dev] Another Tile success story :)

[Igor N. <igo...@gm...>]

Hi all!

Our sK1 project (http://sk1.sf.net) uses Tile engine as a main widgetset
under XWindow. On our opinion, it could be a good sample of Tile engine
potential. Using Tile sample themes we constructed own version of KDE
Plastik theme which is closely similar to native theme:

http://sk1.sf.net/screenshots/sk1_cmyk.png
http://sk1.sf.net/screenshots/sK1_kubuntu_6_06.PNG

and other screenshots in http://sk1.sf.net/screenshots/
Please note, that this theme requires tkpng package and some Tile scripts
are slightly modified.

Also we plan creating GNOME Clearlooks similar theme to provide native
look-and-feel for sK1 under GNOME.

Sincerely,

Igor E. Novikov
sK1 project
http://sk1.sf.net

[Tile-dev] =?iso-8859-15?q?Feature_request=3A_ttk=3A=3Anotebook_w?= =?iso-8859-15?q?ith_scroll_arrows=2C_close_button_=26_dropdown_selector?=

[Eckhard L. <ec...@we...>]

Harald wrote in comp.lang.tcl :
> Tile 0.7.8, TCL 8.4.13, Windows XP:
> 
> when using the tabbed notebook widget and there is not enough space to
> display all the tabs, the tab text is clipped. I would prefer the
> solution of BWidgts to show tab scrolling arrows in this case.
> 
> Is there any way to activate those or is there any plan to enhance the
> present tile notebook ? The current solutions seems quite suited to
> static window size, which is IMHO not TCL-like.

Apart from the scroll arrows it would be good to have an optional close button on each tab and a dropdown selector list of all tabs. That are common design idioms nowadays, you see it everywhere from Mozilla (2.0) to Eclipse.

would it be hard to implement this?

I followup this posting to tkt...@li....


Eckhard


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

Re: [Tile-dev] Modal question dialogs in Tile

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

> BTW, there will never be a ttk::listbox, right?  The preferred =20
> solution is to make a ttk::treeview with one column?

I wouldn't make this assumption for the last few widgets that have no =
ttk
equivalent (text, listbox, spinbox, etc.).  If nothing else, it would be =
nice
to have ttk bordering on the standard widget.  It may be easier to do =
this
when it is fully integrated for 8.5.  For example, the text widget looks =
odd
on OS X solely because it doesn't have the blue fade focus outline.  =
Then
again, maybe it would be made possible with a ttk::border widget that =
would go
around scrolledwindows and other encompassing frames as well.

Jeff

Re: [Tile-dev] Combobox documentation

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

Alastair Davies wrote:
> (It also supports the -show option, but 
> I can't imagine that is actually all that useful!)

FWIW, I think the -show option of the entry really ought to be part of a
style, and not as something set directly. One important reason for this
is that the preferred "password obscuration" character is really a
platform-specific thing, with * being common on Unix/X11 and a bullet
being common on Windows.

Donal.

[Tile-dev] Combobox documentation

[Alastair D. <ala...@si...>]

> People keep saying that.  "Tile is totally undocumented!",
> I keep hearing.  I don't get it.  Given that there is
> documentation for every widget (including all options and
> every subcommand), documentation for the [style] command --
> sparse, to be sure, but it's there -- documentation
> for a good chunk of the low-level C API, plus a white paper
> giving an overview and rationale, people must be using some
> definition of the term "totally" with which I am unfamiliar.
> 
> RTFM here: http://tktable.sourceforge.net/tile/doc/
> 
> 
> --Joe.


I think the documentation of the Tile widgets is at least as 
comprehensive as the documentation of the Tk widgets, and is often more 
clear.  The only omission I would like to point out would be for the 
/combobox/ widget.  The documentation of the *Widget Commands* points 
out that it supports seven of the commands of the /entry/ widget.  In 
the *Options* section, however, it is not mentioned that the /combobox/ 
also supports the -invalidcommand, -validate and -validatecommand 
options of the /entry/ widget.  (It also supports the -show option, but 
I can't imagine that is actually all that useful!)


Thanks,
Alastair

Re: [Tile-dev] Modal question dialogs in Tile

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

Oops, I guess I spoke too soon.  On Unix, in my case, Solaris, it  
looks out of place.  The tile stuff seems to match my gnome desktop  
where the tk_messageBox looks like a CDE message box.  Not horrible,  
just a little inconsistent.  I guess this is one of the platforms  
which is where it is not native?

I haven't tried running in a CDE environment to see if tile looks right.

On Oct 12, 2006, at 11:50 AM, Donal K. Fellows wrote:

> Joey Mukherjee wrote:
>> if {[tk_dialog .d "Warning" "Are you sure you wish to delete  
>> these  files?" warning 0 Yes No]==1} {
>>      return
>> }
>
> Any reason for not using tk_messageBox instead? On at least two
> platforms that's fully native, and it is modal already.
>
> Donal.

Re: [Tile-dev] Modal question dialogs in Tile

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

Wow, how did we miss that?  Ok, that looks like a great solution.   
I'm not sure why we were doing tk_dialog in the first place...  I'm  
just going through our old code and see if I can't tile'ize  
everything and looked for all places not having a ttk.

BTW, there will never be a ttk::listbox, right?  The preferred  
solution is to make a ttk::treeview with one column?

Thanks!

On Oct 12, 2006, at 11:50 AM, Donal K. Fellows wrote:

> Joey Mukherjee wrote:
>> if {[tk_dialog .d "Warning" "Are you sure you wish to delete  
>> these  files?" warning 0 Yes No]==1} {
>>      return
>> }
>
> Any reason for not using tk_messageBox instead? On at least two
> platforms that's fully native, and it is modal already.
>
> Donal.

Re: [Tile-dev] Modal question dialogs in Tile

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

Joey Mukherjee wrote:
> if {[tk_dialog .d "Warning" "Are you sure you wish to delete these  
> files?" warning 0 Yes No]==1} {
>      return
> }

Any reason for not using tk_messageBox instead? On at least two
platforms that's fully native, and it is modal already.

Donal.

[Tile-dev] Modal question dialogs in Tile

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

I have a lot of code like the following:

if {[tk_dialog .d "Warning" "Are you sure you wish to delete these  
files?" warning 0 Yes No]==1} {
     return
}

where I ask the user and wait for a response and act on the  
response.  In tile, the ttk::dialog doesn't really have -modal  
option.  Is something like this possible or worth adding?

Thanks,
Joey

Re: [Tile-dev] Release plans

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

On Oct 3, 2006, at 2:17 PM, Joe English wrote:

> Jeff Hobbs wrote:
>
>> It is waiting for Ttk inclusion (which I have
>> mostly sandboxed, but is totally lacking doc and needs more tests)
>                            ^^^^^^^^^^^^^^^^^^^
>
> People keep saying that.  "Tile is totally undocumented!",
> I keep hearing.  I don't get it.  Given that there is
> documentation for every widget (including all options and


Sorry for the late reply!  Back from travel...

At any rate, what happened to documentation for ttk::scale?   It  
seems to be missing and has been for some time.  It also isn't  
updated for the latest version since I notice ttk::paned and not  
panedwindow.

BTW, thanks for the detailed analysis of that time dialog thing!  I  
read it and not fully digested it yet, but I plan to soon.  For the  
record, I didn't write that code! ;-)  I just wanted to report a "bug/ 
feature" when we trying to convert some of our legacy stuff over to  
tile.

Cheers,
Joey

Re: [Tile-dev] Keramik Theme

[Pat T. <pat...@us...>]

Joe English <jen...@fl...> writes:

>Sebastien MAURICE wrote:
>
>> I use aMSN application (Linux) and there is a plugin "chameleon" which
>> "allows you to change aMSN look and feel using the Tile extension for
>> Tk". I want to use the Keramik theme.
>> How can I do ? Download it through CVS repository ? Where should I put it ?
>
>For that, you should use Georgios Petasis' TileQT theme,
>available as a separate download.  This uses the Qt library
>to draw Ttk widgets, for a much tighter integration with
>KDE than is possible with Tk alone.
>
>
>The TileQT homepage seems to be down right now, but there are
>links to relevant information here:
>
>    <URL: http://www.flightlab.com/~joe/gutter/packages/tileqt.html >
>
>
>[ Pat -- there probably ought to be a pointer to TileQT on the
>  main Tile page, could you add a link?  ]
>

Sure. The image based keramik and plastik themes are just packages. 
Copy the folder to any of the folders listed in the tcl auto_path
variable (in aMSN you can use Control-C to get a console window and
then enter set ::auto_path to see the value).

I'm uncertain how easy it is to build the TileQt extension - maybe we
can put a binary up for people to try out, or a second starkit.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [Tile-dev] Keramik Theme

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

Sebastien MAURICE wrote:

> I use aMSN application (Linux) and there is a plugin "chameleon" which
> "allows you to change aMSN look and feel using the Tile extension for
> Tk". I want to use the Keramik theme.
> How can I do ? Download it through CVS repository ? Where should I put it ?

For that, you should use Georgios Petasis' TileQT theme,
available as a separate download.  This uses the Qt library
to draw Ttk widgets, for a much tighter integration with
KDE than is possible with Tk alone.


The TileQT homepage seems to be down right now, but there are
links to relevant information here:

    <URL: http://www.flightlab.com/~joe/gutter/packages/tileqt.html >


[ Pat -- there probably ought to be a pointer to TileQT on the
  main Tile page, could you add a link?  ]


--Joe English

[Tile-dev] Keramik Theme

[Sebastien M. <seb...@un...>]

Hi !

I use aMSN application (Linux) and there is a plugin "chameleon" which 
"allows you to change aMSN look and feel using the Tile extension for 
Tk". I want to use the Keramik theme.
How can I do ? Download it through CVS repository ? Where should I put it ?


Thank you in advance for your answer !

-- 
Sébastien MAURICE
Direction des Systèmes d'Information
Université Paul CEZANNE
Contact : 0442961411
seb...@un...

[Tile-dev] ANNOUNCE: Tile widget set, release 0.7.8

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

[5 Oct 2006]

ANNOUNCE: Tile Widget Set, version 0.7.8.

~ What is it?

The Tile widget set is an experimental reimplementation
of some of the standard Tk widgets.  The main features are:

    + Native look and feel under Windows (XP, NT, and 2K)
    + Nearly-native look and feel under Mac OSX
    + "Revitalized" look and feel under X11
    + Appearance controlled by a theme engine, providing
      greater flexibility for custom widgets
    + New widgets, including notebook, progressbar, combobox,
      separator, and sizegrip.

~ What's New in 0.7.8

+ A [ttk::sizegrip] widget has been added (that's the gizmo
  sometimes seen in the lower right corner that resizes
  the window when dragged).

+ The [ttk::treeview] widget now supports item tags,
  similar to the Text and Canvas widgets.  [$tv tag bind]
  and [$tv tag configure] methods are supported.

+ The [ttk::treeview] widget now supports -selectmode {browse|extended|none}
   The default selection behavior has been improved, and
  '-selectmode none' combined with tag bindings make it
  possible to implement other behaviors if desired.

+ All widgets now have an 'identify' method, for better
  megawidget support.

+ A few more bugfixes and minor L&F improvements.

+ POTENTIAL INCOMPATIBILITY: Widget options now take precedence
  over [style map] settings.  (This is usually the desired behavior).

~ Forward Compatibility

Due to popular demand, the [ttk::paned] widget will be
renamed to [ttk::panedwindow] in the next release.
To smooth the transition, [ttk::panedwindow] is now
available as a synonym (either one will work in 0.7.8;
in 0.8.0 the old name will become deprecated).

~ Stability

The script-level API for widgets may be considered stable at
this point, with the exception of procedures in the 'tile::*'
namespace and the [ttk::paned] widget, which will be renamed.
Theme definitions are still subject to change: user-defined
themes will need to be revised in the 0.8 series.


~ A note on version numbers

To help distinguish formal releases from CVS snapshots,
the subminor version number will be incremented immediately before
and immediately after making a release.  Thus odd-numbered subminor
versions indicate a CVS snapshot, and even-numbered ones indicate
a known release.

~ Availability

The tile widget set is hosted under the tktable project
at SourceForge:

    <URL: http://tktable.sourceforge.net/tile/ >
    <URL: http://sourceforge.net/projects/tktable/ >

Sources are available under the 'tile' module in CVS.
A prebundled tarball is available in the file release area:

    <URL: http://sourceforge.net/project/showfiles.php?group_id=11464 >

Documentation is available here:

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

Re: [Tile-dev] Release plans

[Will D. <Wil...@jp...>]

oo::
namespace ensemble
namespace path
Snit 2.0

I'm eager to move to 8.5 once it's stable.

Will

On Oct 2, 2006, at 10:06 PM, Jeff Hobbs wrote:

> Steve Landers wrote:
>>
>> On 02/10/2006, at 11:18 PM, Jeff Hobbs wrote:
>>
>>> You can also look at this as more reasons to pull people to 8.5,
>>> including our own focus.  Yes, at this point I think some of us (very
>>> much myself included) need to find ways to break with the attachment  
>>> to
>>> 8.4, or 8.5 won't see the light of day this decade.
>>
>> I suspect moving it from alpha to beta or even released might be an
>> effective way ;-)
>
> I know you gave a winky, but I'm not sure if you underestimate the  
> truth
> and seriousness of my message.  Who cares about 8.5 when we have tile
> fully operational in 8.4, dict backported, etc.  What is 8.5 really
> offering?
>
> Jeff
>
> ----------------------------------------------------------------------- 
> --
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>
>
------------------------------------------------------------------------
Will Duquette, JPL  | Wil...@jp...
But I speak only    | http://eis.jpl.nasa.gov/~will (JPL Use Only)
for myself.         | It's amazing what you can do with the right tools.

Re: [Tile-dev] Release plans

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

Jeff Hobbs wrote:

> It is waiting for Ttk inclusion (which I have
> mostly sandboxed, but is totally lacking doc and needs more tests)
                           ^^^^^^^^^^^^^^^^^^^

People keep saying that.  "Tile is totally undocumented!",
I keep hearing.  I don't get it.  Given that there is
documentation for every widget (including all options and
every subcommand), documentation for the [style] command --
sparse, to be sure, but it's there -- documentation
for a good chunk of the low-level C API, plus a white paper
giving an overview and rationale, people must be using some
definition of the term "totally" with which I am unfamiliar.

RTFM here: http://tktable.sourceforge.net/tile/doc/


--Joe.

Re: [Tile-dev] Release plans

[Oscar B. <ob...@bi...>]

On Oct 3, 2006, at 9:58 AM, Jeff Hobbs wrote:

> Oscar Bonilla wrote:
>> On Oct 3, 2006, at 9:43 AM, Jeff Hobbs wrote:
>>> problem.  Noone is playing nag-meister.  Another issue is that =20
>>> noone is
>>> pointing out a "critical" need for 8.5 - feature-wise or company
>>> backing.  So why nag?
>>
>> So what's the value of 8.5? I mean, if every single feature that is
>> existent in 8.5 has been back-ported to 8.4. What's 8.5's
>> raison d'=EAtre?
>
> Exactly - that is the best response so far for Larry's other =20
> question.  It has
> no raison d'=EAtre currently.  It is waiting for Ttk inclusion (which =20=

> I have
> mostly sandboxed, but is totally lacking doc and needs more tests) and
> (possibly) oo.  Each is a feature-defining release point.  8.5 also =20=

> has
> {expand} and dict, but dict is backported and {expand} is not =20
> release-defining
> in itself.  There are of course many more changes already:
> 	http://wiki.tcl.tk/10630
>
> While they may fill up a whole, it's nothing earth-shattering to =20
> many.  8.5
> without Tile and/or oo might as well not be (IOW: can wait).

But while it waits it's dragging considerable resources to backport =20
stuff to 8.4. That's a hidden but measurable cost. So the "can wait" =20
part is really costly.

--
pgp fingerprint: BC64 2E7A CAEF 39E1 9544  80CA F7D5 784D FB46 16C1

Re: [Tile-dev] Release plans

[<ke...@cr...>]

je...@ac... said:
> While they may fill up a whole, it's nothing earth-shattering to many.
>  8.5 without Tile and/or oo might as well not be (IOW: can wait).

It's a damned POINT release!  Other people label point releases that have
nothing but bugfixes!

It has a number of new things: Bignum support.  Floating point
tk_precision cleanup. (You have no idea how important that is if
you're doing anything with numerics.) Dict. Ensembles.
[switch] enhancements. [return] and [catch] rationalization.
Greatly improved localisation ([source -encoding], [clock], [msgcat]
root locale).

It's got quite a number of appearance changes to Tk.  Xft, new checkbutton
and radiobutton L&F, multi-line text search, the new text scrolling, 
[grid] enhancements, tk_messageBox detail, , panedwindow stretch and 
hide, full-screen toplevels, [wm attributes] on Unix, tabulation control 
in [text].  Even without Tile, these changes will get some of the
loudest complaints about Tk off the table.

8.5 is getting to be a perpetually receding target.  We approve 
functionality for it, wait for it, by the time we have it implemented, 
we've approved more new functionality that we have to wait for, repeat 
until everyone is banging heads in frustration.

Conceded, it isn't even close to being all we hoped for.  But what
ever is?  There comes a time that you have to shoot the engineers and
ship the product.

And yes, I'm all for "9.0 in February, or whenever Tile and oo are ready."
Let's have a release cycle and not a tar pit.
--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tile-dev] Release plans

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

On Tue, Oct 03, 2006 at 09:58:29AM -0700, Jeff Hobbs wrote:
> Oscar Bonilla wrote:
> > On Oct 3, 2006, at 9:43 AM, Jeff Hobbs wrote:
> > > problem.  Noone is playing nag-meister.  Another issue is that noon=
e is
> > > pointing out a "critical" need for 8.5 - feature-wise or company =20
> > > backing.  So why nag?
> >=20
> > So what's the value of 8.5? I mean, if every single feature that is =20
> > existent in 8.5 has been back-ported to 8.4. What's 8.5's=20
> > raison d'=EAtre?
>=20
> Exactly - that is the best response so far for Larry's other question. =
 It has
> no raison d'=EAtre currently.  It is waiting for Ttk inclusion (which I=
 have
> mostly sandboxed, but is totally lacking doc and needs more tests) and
> (possibly) oo.  Each is a feature-defining release point.  8.5 also has
> {expand} and dict, but dict is backported and {expand} is not release-d=
efining
> in itself.  There are of course many more changes already:
> 	http://wiki.tcl.tk/10630

There is a fair amount of stuff there.

Personally, I'd vote for getting Tile in there and calling it a release.
If the community focussed on that it could get done and there would at
least be some visible forward progress.
--=20
---
Larry McVoy                lm at bitmover.com           http://www.bitkee=
per.com