Tcl / Tk 8.6.9 Release Candidates

[Don Porter]

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/

are the files making up a Release Candidate of the collection
of items making up the 8.6.9 releases of Tcl/Tk and bundled packages.

This collection includes release candidates of packages

Itcl 4.1.2
Thread 2.8.4
sqlite3 3.25.2
tdbc* 1.1.0

It is expected that these RCs will become the actual release November 9,
unless testing leads to reports of problems of release-blocking
magnitude. Please do test, and let us know what troubles you find.

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[jm....@orens.fr]

Hello,

As I'm not sure my remarks about ttk doc where wrong and not agreed, I reiterate, just in case they were unintentionally lost.

In ttk 8.6.9 doc, *STANDARD* OPTIONS of :
- ttk::button
- ttk::checkbutton
- ttk::menubutton
- ttk::radiobutton
- ttk::separator
- ttk::sizegrip

should'nt mention "-state" option, because if this option is queried via ttk' cget command, in some circonstances a wrong value may be returned.

see analysis + demo in : https://groups.google.com/forum/#!topic/comp.lang.tcl/u6Jx1Pa1VTQ

(apologies for the noise if I'm wrong)

Best regards

Jean-Marie

[Francois Vogel]

Le 05/11/2018 à 19:30, jm....@orens.fr a écrit :
>
> As I'm not sure my remarks about ttk doc where wrong and not agreed, I reiterate, just in case they were unintentionally lost.
>
> In ttk 8.6.9 doc, *STANDARD* OPTIONS of :
> - ttk::button
> - ttk::checkbutton
> - ttk::menubutton
> - ttk::radiobutton
> - ttk::separator
> - ttk::sizegrip
>
> should'nt mention "-state" option, because if this option is queried via ttk' cget command, in some circonstances a wrong value may be returned.

Honestly I just don't understand your point. Am I alone?

"standard" options, in my understanding, are options that are available
for several (many) widgets. That's all. They are documented in one
single place, which is ttk::widget. There is no link between that idea
and any command, and the "state" command is not specific in that respect.

F.

[jm....@orens.fr]

I regret to not have filled a bug (better place for discussing this)

I was not refeering to ttk::widget man page wich is fine to me, but the 6 afored-mentioned man pages wich are not.

In these 6 man pages mixing STANDARD paragraph and COMPATIBILITY paragraph of another man page (ttk::widget) for -state option is confusing.

In the big set of options/commands of ttk, my (different) understanding of STANDARD wasn't "available-but-sometime-doesn't-work" but "regular-thing" (wich works).

Hope to be better understood.

Jean-marie

[Andreas Leitgeb]

jm....@orens.fr <jm....@orens.fr> wrote:
> In ttk 8.6.9 doc, *STANDARD* OPTIONS of :
> - ttk::button
> - ttk::checkbutton
> - ttk::menubutton
> - ttk::radiobutton
> - ttk::separator
> - ttk::sizegrip
> should'nt mention "-state" option, because if this option is
> queried via ttk' cget command, in some circonstances a wrong
> value may be returned.

There may be different legit opinions about a manpage that
first "says" something generally, and only later "corrects"
it.

Some users may only skim over ttk::button until they see -state mentioned
as a standard option and jump to the manpage of those standard options.
Those will miss the paragraph "COMPATIBILITY OPTIONS" that specifies
the specific limitations("write only") of -state in the context of
ttk::button.

Maybe, those standard options with "something more to say about"
could be tagged with a footnote marker and a footnote (still within
the paragraph of "STANDARD OPTIONS") that says that the standard
definition is to be taken with a grain of salt...

[Brad Lanam]

On Monday, November 5, 2018 at 5:31:32 AM UTC-8, Don Porter wrote:
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/
>
> are the files making up a Release Candidate of the collection
> of items making up the 8.6.9 releases of Tcl/Tk and bundled packages.

And on the good news front, I ran my application's tests on Mac OS X 10.12.6
and windows (gcc, mingw) with 8.6.9 (Tcl & Tk) and no obvious issues.
Only ran some simple spot checks on Linux and it seems fine.

[Nicolas]

hi,
while compiling Tcl8.6.9_rc2, I got those warnings:
https://pastebin.com/b2RF3pbP

and for Tk8.6.9_rc3:
https://pastebin.com/HCG7A3Gi
https://pastebin.com/VKfcTbJY
https://pastebin.com/2aUKX3tv

best regards,
nicolas

[Francois Vogel]

Le 06/11/2018 à 00:10, jm....@orens.fr a écrit :
> Le lundi 5 novembre 2018 20:59:44 UTC+1, Francois Vogel a écrit :
>> Le 05/11/2018 à 19:30, jm....@orens.fr a écrit :
>>>
>>> In ttk 8.6.9 doc, *STANDARD* OPTIONS of :
>>> - ttk::button
>>> - ttk::checkbutton
>>> - ttk::menubutton
>>> - ttk::radiobutton
>>> - ttk::separator
>>> - ttk::sizegrip
>>>
>>> should'nt mention "-state" option

OK, this is something precise that I understand.

So you are suggesting that in these man pages the *link to the -state
option* (because it actually is a link) be removed? How can then the
user know that this widget provides this option if it disappears from
the man page describing the widget?

> I was not refeering to ttk::widget man page wich is fine to me, but the 6 afored-mentioned man pages wich are not.
>
> In these 6 man pages mixing STANDARD paragraph and COMPATIBILITY paragraph of another man page (ttk::widget) for -state option is confusing.

In fact what you're saying here does no apply to ttk::button or
ttk::checkbutton or ttk::menubutton. In those man pages, the -state
widget option is *only* described through a link to the description in
ttk::widget. These man pages do *not* mix STANDARD paragraph and
COMPATIBILTIY paragraph. Not in the 8.6.9-rc3 version, at least.

ttk::checkbutton and ttk::radiobutton describe possible *states* of this
widget, but not the -state *option* (except through the link to
ttk::widget).

ttk::separator and ttk::sizegrip do not tell about -state at all
(because there is no such option for a separator or sizegrip).

In all my answers I'm talking about the man pages as in the bleeding
edge of core-8-6-branch, which are the same as what is included Tcl/Tk
in 8.6.9-rc3. Remember the links to the tickets I have posted earlier in
this thread. These tickets induced changes in the man pages compared to
what is in 8.6.8.

Definitely I'm lost with what you're saying. Perhaps the best would be
you propose a patch, but note such a patch *must* be based on the latest
man pages. I definitely think you are still looking at some older
version, probably 8.6.8.

Thanks,
Francois

[jm....@orens.fr]

Hi François,

If I knew something about doc formats I would send a patch.

Checked doc of rc 8.6.9 again

Previous remarks corrected : only 4 man pages are involved :

-ttk::button
-ttk::checkbutton
-ttk::menubutton
-ttk::radiobutton

In "human-reading" form, bellow are the changes I propose for clarifying ttk STANDARD vs COMPATIBILITY options in rc 8.6.9 doc (bigger maze than I saw it at first glance) :

1) In each of the 4 mentioned man pages, 2 lines (+ associated link) should be deleted :

a) TOC part - STANDARD OPTIONS section

-> delete "-state, state, State" line (+ associated link)

b) STANDARD OPTION paragraph

-> delete "-state, state, State" line (+ associated link)


2) In the TOC part of only ttk::button man page,

-> removal done in rc 8.6.9 vs 8.6.8 of item "COMPATIBILITY OPTIONS + its sub-item "-state, state, State" should be *canceled* and stay there in 8.6.9

-> associated link should to point to ttk::widget COMPATIBILITY OPTIONS paragraph (*different* from the link that is in 8.6.8 doc)


3) In the TOC part of only ttk::checkbutton + ttk::menubutton + ttk::radiobutton

-> add item "COMPATIBILITY OPTIONS + its sub-item "-state, state, State" + associated links pointing to ttk::widget COMPATIBILITY OPTIONS paragraph to make them consistent with 2)


4) The rc 8.6.9 removal of COMPATIBILITY OPTIONS paragraph (was at bottom of man page in 8.6.8 doc) is OK to me as related pointers will exist in TOC part of the same page (if agreement on 2) + 3)).


Jean-Marie

[jm....@orens.fr]

> 4) The rc 8.6.9 removal of COMPATIBILITY OPTIONS paragraph (was at bottom of man page in 8.6.8 doc) is OK to me as related pointers will exist in TOC part of the same page (if agreement on 2) + 3)).

This 4) is about ttk::button man page

Jean-marie

[Don Porter]

On 11/05/2018 08:31 AM, Don Porter wrote:
>
> Now available at
>
>     https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/

> It is expected that these RCs will become the actual release November 9,
> unless testing leads to reports of problems of release-blocking
> magnitude.  Please do test, and let us know what troubles you find.

Several useful reports have come in and prompted work to improve and
correct. We will not have a release on November 9. New release
candidates should be available soon and will be announced here when ready.

Thank you for your help.

[Harald Oehlmann]

Am 08.11.2018 um 20:32 schrieb Don Porter:
> On 11/05/2018 08:31 AM, Don Porter wrote:
>>
>> Now available at
>>
>>      https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/
>
>> It is expected that these RCs will become the actual release November
>> 9, unless testing leads to reports of problems of release-blocking
>> magnitude.  Please do test, and let us know what troubles you find.
>
> Several useful reports have come in and prompted work to improve and
> correct. We will not have a release on November 9. New release
> candidates should be available soon and will be announced here when ready.
>
> Thank you for your help.
>

Thank you to, highly appreciated,
Harald

[Kevin Walzer]

On 11/8/18 2:32 PM, Don Porter wrote:
> On 11/05/2018 08:31 AM, Don Porter wrote:
>>
>> Now available at
>>
>>      https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/
>
>> It is expected that these RCs will become the actual release November
>> 9, unless testing leads to reports of problems of release-blocking
>> magnitude.  Please do test, and let us know what troubles you find.
>
> Several useful reports have come in and prompted work to improve and
> correct. We will not have a release on November 9. New release
> candidates should be available soon and will be announced here when ready.
>
> Thank you for your help.
>

Still finding a late-blooming bug on the Mac port, not quite ready even
after the latest merge...hopefully this will be quick.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Nicolas]

Hi Guys,
as release is delayed, is it possible to add code to detect dark/light mode switching in macOS10.14?
when using dark mode, menubar items are all black...

thank you in advance,
best regards,
Nicolas

[Nicolas]

Le vendredi 9 novembre 2018 05:00:27 UTC+1, kw a écrit :

and thank you for the fix of crash due to key events in dialog window :)

++

[Kevin Walzer]

On 11/9/18 1:18 AM, Nicolas wrote:
> as release is delayed, is it possible to add code to detect dark/light mode switching in macOS10.14?
> when using dark mode, menubar items are all black...

We've added a virtual event that fires when this is done--see the README
file in the source code.

[Nicolas]

ah cool!!
for now my app crash when I switch light/dark mode... even without the new bindings... so I cannot try...

just another thing regarding Tk as framework on OSX,
my app is using Tcl_ThreadQueueEvent() to add stuff to event loop.
neither on linux, win or x11 on macos stuff are fired unless I call Tcl_ThreadAlert()

with Tk as a framework, stuff are fired without this call.
is it by design?

best regards,
nicolas

[Francois Vogel]

OK, thanks for your patient explanations of your point. I think I get it
now (and I understand you are really looking at the latest man pages
from the rc).

You are proposing that:

- the -state option be no longer mentioned in the "STANDARD OPTIONS"
section of ttk::* man pages

- a "COMPATIBILITY OPTIONS" section be created in each of these
ttk::* man pages

- in that "COMPATIBILITY OPTIONS" section, a link be created to the
-state option as described in the "COMPATIBILITY OPTIONS" section of
ttk::widget

- alternatively, no "COMPATIBILITY OPTIONS" section would be created
but the TOC would still mention the -state option and point to ttk::widget.


I don't think we should do this, and here is why.

The man pages are written as source code in nroff language, and are
later compiled to html and other formats. In this process, links are
created between pages and so on. In particular, the TOC section is
created automatically during this compilation step, by scanning the
existing content sections of the man page. This means there can be no
TOC entry without a corresponding content section.

Also, all options listed under "STANDARD OPTIONS" are links to areas in
the ttk:widget man page that describe each of these options.

"STANDARD OPTIONS" are options that are available for several ttk
widgets. They have to be understood as opposed to "WIDGET-SPECIFIC
OPTIONS". This is the key: _STANDARD means the opposite of WIDGET-SPECIFIC_.

"STANDARD OPTIONS" are described at exactly one place (in ttk::widget).
The widgets that feature such a standard option (e.g. -state) list this
standard option in their man page (in the "STANDARD OPTIONS" section,
which creates it also in the TOC section owing to the compilation
process of the man page). They do not describe this standard option in
their man page (this would be a duplication of the description from
ttk::widget).

In contrast, "WIDGET-SPECIFIC OPTIONS" are described directly in the man
page of the widget. They are not links to the ttk::widget man page.
Indeed, linking to somewhere else would not make sense since these
options are specific (i.e. unique) to the considered widget.

It is logical that "WIDGET-SPECIFIC OPTIONS" be described in the man
page of the widget they belong to, and that "STANDARD OPTIONS" be
described at a single common place for all widgets that feature them.

Among the "STANDARD OPTIONS", there are options that are available to
some kinds of widgets, but not to all widgets. For instance there are
options available for scrollable widgets only. These options are still
standard (because they apply to more than one widget), but they make
sense for certain widgets only (a class of widgets, in this example
those which can be scrolled). Because these options are standard, they
are described in the ttk::widget man page.

The "COMPATIBILITY OPTIONS" section of the ttk::widget man page is just
another case of standard options that are available for some widgets
only. Because these options are standard, they are described in the
ttk::widget man page.

In conclusion I think the man pages are just fine as they are now.

Regards,
Francois

[Don Porter]

On 11/5/18 8:31 AM, Don Porter wrote:
> Now available at
>
>     https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/
>
> are the files making up a Release Candidate of the collection
> of items making up the 8.6.9 releases of Tcl/Tk and bundled packages.

An updated set of RC files are now in place.

> This collection includes release candidates of packages
>
>     Itcl    4.1.2
>     Thread    2.8.4
>     sqlite3    3.25.2
>     tdbc*    1.1.0

The updated files now include sqlite-3.25.3

> It is expected that these RCs will become the actual release November 9,
> unless testing leads to reports of problems of release-blocking
> magnitude.  Please do test, and let us know what troubles you find.

The new release date target is November 16.

[Andreas Leitgeb]

Francois Vogel <fvogelne...@free.fr> wrote:
> I don't think we should do this, and here is why.

Just humbly asking, if you happened to see my post on that topic.

My suggestion was to add a marker like "(*)" to each of the standard
options whose general definition doesn't fully apply to the widget.

e.g.:

STANDARD OPTIONS
-class -cursor -style(*)
-takefocus -xscrollcommand

See the ttk_widget manual entry for details on the standard options.

For options marked with (*) mind overriding remarks specific to
this widget below.


(better verbiage welcome)

[Francois Vogel]

Le 13/11/2018 à 18:14, Andreas Leitgeb a écrit :
> My suggestion was to add a marker like "(*)" to each of the standard
> options whose general definition doesn't fully apply to the widget.
>
> e.g.:
>
> STANDARD OPTIONS
> -class -cursor -style(*)
> -takefocus -xscrollcommand
>
> See the ttk_widget manual entry for details on the standard options.

Is it really useful to add this little star and written redirection to
ttk::widget since clicking one of these options indeed opens the
ttk::widget man page? I don't think so.

Moreover the automatic processing of the source code would need to be
improved to trim out the (*) from the option name when creating the link
to the option in ttk::widget. Not worth the effort IMO.

> For options marked with (*) mind overriding remarks specific to
> this widget below.

Is there still such cases in the latest man pages? It would mean that an
option is BOTH referred to in the "STANDARD OPTIONS" section and in the
"WIDGET-SPECIFIC SECTION".

Practical checking (if I didn't miss something) shows that it still
happens only in the following case:

ttk::label, -text (same description in both ttk::widget and in the
"WIDGET-SPECIFIC SECTION" of ttk::label)
--> <TODO>: remove the entry from the "WIDGET-SPECIFIC SECTION"

I can easily fix this.

Otherwise I don't see what further change is needed.

Regards,
Francois

[Andreas Leitgeb]

Francois Vogel <fvogelne...@free.fr> wrote:
> Le 13/11/2018 à 18:14, Andreas Leitgeb a écrit :
>> My suggestion was to add a marker like "(*)" to each of the standard
>> options whose general definition doesn't fully apply to the widget.
>> e.g.:
>> STANDARD OPTIONS
>> -class -cursor -style(*)
>> -takefocus -xscrollcommand
>>
>> See the ttk_widget manual entry for details on the standard options.
>>

>> For options marked with (*) mind overriding remarks specific to
>> this widget below.

> Moreover the automatic processing of the source code would need to be
> improved to trim out the (*) from the option name when creating the link
> to the option in ttk::widget. Not worth the effort IMO.

I admit (after looking into the unrendered manpage source) I can't
even estimate the effort, so whatever I thought of may indeed not
be worth that effort.

[Francois Vogel]

Le 13/11/2018 à 21:27, Francois Vogel a écrit :
> option is BOTH referred to in the "STANDARD OPTIONS" section and in the
> "WIDGET-SPECIFIC SECTION".
>
> Practical checking (if I didn't miss something) shows that it still
> happens only in the following case:
>
> ttk::label, -text  (same description in both ttk::widget and in the
> "WIDGET-SPECIFIC SECTION" of ttk::label)
>     --> <TODO>: remove the entry from the "WIDGET-SPECIFIC SECTION"
>
> I can easily fix this.

Done:

https://core.tcl-lang.org/tk/info/99351b032bca9c26

Regards,
F.