# ticketchng

login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Version 1.164 reinstates support for tcl8.3.
  If this version raises any problems - either bug me on the
  chat or raise a new bug.


login: wildcard_25
username: wildcard_25
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=596509

  Have corrected these. The problem is due to TAG priority. 
  Still have a couple of minor issues, not mentioned here, 
  to correct before applying a patch.


login: dev_null42a
username: dev_null42a
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1381097

  Under OS X 10.4.7, /usr/bin/wish8.4 does not appear to hang
  on the BWidget demo.  I could not get the lock up with
  fink's /sw/bin/wish either.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Test by Kevin:
  "I can't reproduce the bug--it was filed against 1.7 and I'm using 1.8. I'd close it as out of date"


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  I've hardcoded a fix for my usage.

  In proc ::smtp::initialize_ehlo, after the TLS code, I added:

     if [catch {smtp::talk $token 300 "AUTH PLAIN"} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 334}  {
         puts stderr "Bad response to AUTH PLAIN = '$response(diagnostic)'."
         catch {close $state(sd)}
         return {} 
     }    

     if [catch {smtp::talk $token 300 "A------------
  redacted----------------------hZGE="} result]  {
         array set response [list code 400 diagnostic $result args ""]
     } else {
         array set response $result
     }    
     if {$response(code) != 235}  {
         puts stderr "Bad response to the base64 password = 
  '$response(diagnostic)'."
         catch {close $state(sd)}
         return {}
     }    

  It took a bit of Googling to find out the format, the RFC didn't state it.

  FYI, you'd better give the user a choice of AUTH methods, because
  I first coded this for AUTH LOGIN and it seemed to work - gave a
  success for authorization - but it would fail to work if I was sending
  to a different domain (and it was a forward, not a POP box) that
  was handled by the same POP server. I don't know if this was a
  qmail quirk or not. Switching to AUTH PLAIN worked. If the (eventually)
  fixed smtp.tcl doesn't give a choice and it chooses the first one listed
  by the EHLO output, it would fail for local aliases at my provider.

  I'm suggesting to my provider to drop AUTH LOGIN from the EHLO output.


login: orwellian
username: orwellian
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=490034

  Update: regarding giving a choice of AUTH methods, it turns out
  that was a problem on my end, nevermind. It may or may not be
  a useful thing to be able to specify.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  The current CVS version of the smtp package has AUTH support
  for DIGEST-MD5, CRAM-MD5, LOGIN and PLAIN. It also supports
  the use of the STARTTLS extension to enable a secure link if
  you have the tls package available. This has been tested
  against sendmail, postfix and Microsoft's SMTP server.


login: eriklns
username: eriklns
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=113903
  Originator: NO

  Personally, I do not find this too funky at all. In fact, I'm inclined to go one step further and change the default for this option (-exportselection) into 0. 

  The documentation for this option says:
  "The default is usually for widgets to export selections." (meaning the X-selection)

  I question this statement. I haven't seen many applications that show this default behaviour. (Maybe it is a Unix tradition.)

  A combobox is primarily about selecting an item from a collection of items. This is unrelated to selecting a sequence of characters for a copy/paste operation, and we ought not confuse/mix these two different concepts. If users do want to set the X-selection too, they may choose to change the default.


login: jenglish
username: jenglish
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=68433
  Originator: NO

  Not my department.  Damon?

  FWIW: On X11, Gtk+ and Qt editable comboboxes do export the selection; ditto spinboxes and entry fields.  The only major toolkit I've encountered that doesn't do this is the one Mozilla-family tools use; there, entry fields appear to use a hybrid X11-style global primary selection combined with Windows-style independent selection (which I personally find very confusing.)


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  The patch seams reasonable to me too.
  Nevertheless, I have checked the behaviour on windows and linux with and without patch. It works fine for both cases.
  #- test script -
  pack [ComboBock .c]
  pack[ComboBox .n -exportselection 0]
  # set a selection in both using the mouse
  .c configure -exportselection 0

  In the first case, the selection is exported and removed if there is somewhere else a selection
  In the second case, the selection is local and not exported to other windows.

  I decided not to apply the patch.
  Please notify, if the patch helps anybody, no issue to put it in neither.


login: oehhar
username: oehhar
mimetype: text/plain
icomment:
  Thanky to Eric, I have got the point.
  One requires values to test it.
  Revised test script:
  -----
  pack [ComboBox .c -values {1 2 3}]
  pack [ComboBox .n -exportselection 0 -values {1 2 3}]
  -----
  When clicking on an item in the drop-down box, the result gets selected in the first case. In the second, it does not and the cursor is placed behind the entry.

  A matter of taste. Please post, if you like it or not.


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  The extra label options were dropped from the combobox and
  other widgets.  Place it in a LabelFrame.


login: georgeps
username: georgeps
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=585068

  This failure only occurs with Tk 8.5/HEAD.  I can't
  duplicate it with 8.4.6.

  With 8.4.6 this *does not* work:
  ctext::addHighlightClassForRegexp .ct comment navy {#[^\n]*\n}
  That same RE works properly in 8.5/HEAD.

  This RE always seems to work (and interestingly seems to
  avoid the endless loop with 8.5):
  ctext::addHighlightClassForRegexp .ct comment khaki {#[^\n\r]*}

  Time to file a bug for Tk I think.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Fixed. Extended textutil::expander to keep track of location
  and report it as part of errors. Fixed doctools to not snip
  the new location information. Changes have been committed to
  head.


login: phantomfive
username: phantomfive
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1076637

  An addendum:  The windows and linux machines are behind a
  firewall and are being masquaraded to a different ip
  address.  I don't know if that matters.
  Also, yahoo has a strange mail server.


login: patthoyts
username: patthoyts
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=202636

  Their mail server isn't that wierd. It appears to be RFC2821
  compliant at least.

  Here is what I'm using to test this:
   proc send {from to msg {server localhost} {port 25}} {
      set tok [mime::initialize -canonical text/plain -string
  $msg]
      smtp::sendmessage $tok -debug 1 \
          -servers [list $server] \
          -ports [list $port] \
          -header [list From "$from"] \
          -header [list To "$to"] \
          -header [list Subject "RFC 2821 test"] \
          -header [list Date "[clock format [clock seconds]]"]

      mime::finalize $tok
   }

  Note the -debug 1 -- this lets you check the SMTP
  conversation. For which I get
  Trying mx3.mail.yahoo.com...
  <-- 220 YSmtp mta260.mail.scd.yahoo.com ESMTP service ready
  --> EHLO zen (wait upto 300 seconds)
  <-- 250-mta260.mail.scd.yahoo.com
  <-- 250-8BITMIME
  <-- 250-SIZE 15990784
  <-- 250 PIPELINING
  --> MAIL FROM:<patthoyts@users.sourceforge.net> SIZE=265
  (wait upto 600 seconds)
  <-- 250 sender <patthoyts@users.sourceforge.net> ok
  --> RCPT TO:<XXXXXXXXX@yahoo.com> (wait upto 3600 seconds)
  <-- 250 recipient <XXXXXXXXX@yahoo.com> ok
  --> DATA (wait upto 300 seconds)
  <-- 354 go ahead
  --> . (wait upto 120 seconds)
  <-- 250 ok dirdel
  --> QUIT (wait upto 120 seconds)
  <-- 221 mta260.mail.scd.yahoo.com

  So it's not the yahoo server - it's something in the mime
  package -- perhaps you have an old version? I'm testing with
  mime 1.4 and smtp 1.4 here.


login: phantomfive
username: phantomfive
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=1076637

  The problem is fixed if I add the "From" field to the
  header.  When I send mail to hotmail the "From" field is
  added automatically, but sending mail to yahoo throws the
  error if there is no "From" field.

  I downloaded the latest versions of mime.tcl and smtp.tcl
  off the CVS last saturday (July 3rd).  Previously I had been
  using mime.tcl 1.4 and smtp 1.3.5 that came with the active
  tcl distribution.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  It is the 'calendar' module, somehow. It has no
  documentation, and that screws up the system for all modules
  that follow. The simplest way to repro the problem is

      ./sak.tcl nroff calendar FOO

  for any other module FOO, and the doc generation will barf.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  The commands were modeled after the core builtins [file
  split] / [file join], which exhibit the same sort of asymmetry.


login: andreas_kupries
username: andreas_kupries
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=75003

  Duplicate of [Tcllib SF Bug 948273].

  https://sourceforge.net/tracker/?func=detail&atid=112883&aid=948273&group_id=12883

  Already fixed in CVS head of Tcllib as of May 25, 2004.


login: schwarzkopf
username: schwarzkopf
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=159778

  which version of Tcl and what platform? I am using ASTcl
  8.4.7 on windows, and it works. I think the ability to do a
  package require struct::record was just added, so you might
  have an old tcllib (even if it does say 1.6)


login: hobbs
username: hobbs
mimetype: text/plain
icomment:
  Logged In: YES 
  user_id=72656

  Confirmed, the first line in _auto_complete prevents any
  matching when typing in uppercase chars.  Why is that there?


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  It might be obvious, but I do not see the issue on current branch [bwidget].
  Could you verify if it is already fixed ?

  Thank you,
  Harald


login: anonymous
mimetype: text/plain
icomment:
  I've checked the file you sent and the problem still exists. However the version you sent had version 1.9.1 in the pkgIndex.tcl whereas I've been using 1.9.6 and 1.9.7.

  If you look at the files in lang there are different numbers of newlines at the end as well as no.rc having Windows line endings whilst the others have Unix line endings. For freewrap the requirement is for there to be an empty line at the end, i.e. \n\n.  I can see below that es.rc and pl.rc are correct but the others are wrong (by the freewrap measure).

  $ for x in *.rc; do echo $x;  od -c $x| tail -3; done
  da.rc
  0002600   s   t       b   r   u   g   e   r   n   a   v   n       o   g
  0002620       p   a   s   s   w   o   r   d  \n
  0002632
  de.rc
  0002640   l   o   g   i   n       a   n   d       p   a   s   s   w   o
  0002660   r   d  \n
  0002663
  en.rc
  0002560   t   e   r       l   o   g   i   n       a   n   d       p   a
  0002600   s   s   w   o   r   d  \n
  0002607
  es.rc
  0002720   e       u   s   u   a   r   i   o       y       c   o   n   t
  0002740   r   a   s   e 361   a  \n  \n
  0002750
  fr.rc
  0002660       l   o   g   i   n       e   t       l   e       m   o   t
  0002700       d   e       p   a   s   s   e  \n
  0002712
  hu.rc
  0002700   a   s   z   n 303 241   l 303 263   n   e   v   e   t     303
  0002720 251   s       a       j   e   l   s   z 303 263   t  \n
  0002736
  nl.rc
  0002640   n   a   a   m       e   n       w   a   c   h   t   w   o   o
  0002660   r   d       i   n  \n
  0002666
  no.rc
  0002660   S   k   r   i   v       i   n   n       l   o   g   g   i   n
  0002700   n       o   g       p   a   s   s   o   r   d  \r  \n
  0002716
  pl.rc
  0002720   l   e   :           W   p   i   s   z       l   o   g   i   n
  0002740       i       h   a   s 305 202   o  \n  \n
  0002753


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  Thank you for the dietails "\n\n" was the hint.
  Fixed in commit [c4cfe0f45e].

  It is a FreeWrap bug but if the issue is so little, no problem.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  Thank you for the bug report.

  On the current bwidget branch, this shows another related issue:

  <verbatim>
  can't read "option": no such variable
  can't read "option": no such variable
      while executing
  "info exists pathopt($option)"
      (procedure "::Widget::which" line 23)
      invoked from within
  "::Widget::which $path -option $option"
      (procedure "Widget::varForOption" line 2)
      invoked from within
  "Widget::varForOption $path -values"
      (procedure "_create_popup" line 59)
      invoked from within
  "_create_popup $path"
      (procedure "_recreate_popup" line 27)
      invoked from within
  "_recreate_popup $path"
      (procedure "ComboBox::_mapliste" line 19)
      invoked from within
  "ComboBox::_mapliste .cb"
      ("uplevel" body line 1)
      invoked from within
  "uplevel \#0 $cmd"
      (procedure "ArrowButton::_release" line 17)
      invoked from within
  "ArrowButton::_release .cb.a.c"
      (command bound to event)
  </verbatim>

  This is fixed for me with checkin [7665445856091342a].

  Then, the issue does not arise any more for me.

  The resulting box looks a bit ugly on windows but that is as it is.

  Bug closed, please check checkin if ok for you, and complain if not.

  Thank you,
  Harald


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  Committed by checkin [97c7fd38ff].

  I would appreciate documentation and a sample to test functionality.

  Thank you,
  Harald


login: oehhar
mimetype: text/x-fossil-wiki
icomment:
  I have some remarks to the patch, here maked by #HaO:
  <verbatim>
          ## pretty sure this needs the \[list ... \] around it..
  	## HaO: well, this does not loop any more, as there is always only one element in the list
          foreach record [list [lrange $colors 1 end]] {
              set idx 0

              ## some files use symbolic names and have entries like:
              ## "a. s symbol1 c #000000 m white"
              ## I'm guessing this is a "in case this is a mono display, use the
              ## 'm' attribute for mono # fallback?? Fix: scan the list for
              ## the first 'c' entry, use the next entry for color RGB value
              set key [lindex $record $idx]
              while { ($key != "c") && ($key != "") } {
                  incr idx
                  set key [lindex $record $idx]
              }
              if { $key eq "c" } {
                  incr idx
                  set color [string tolower [lindex $record $idx]]
              }
              # HaO: color is undefined if key ne "c"
              set data(color-$key-$cname) $color
              if { [string equal -nocase $color "none"] } {
                  set data(transparent) $cname
              }
          }
  </verbatim>


login: oehhar
mimetype: text/plain
icomment:
  Mail by Matthias 06.09.2013 21:02 with 3 attachments:

  Hi Harald.

  Here's the latest patch. I found a few more issues. I had to re-write the structure somewhat, and introduce a new proc called "process_line", because, as you can see from the comments, I found at least one .xpm file where they counted the number of colors NOT including the "none" line. So, if we get to an undefined color, and there was a "none" definition, we try to process that line as a color definition instead. It makes at least one more .xpm file work.

  I have tried to write it using only [string equal] to compare strings, so may even work for Tcl 8.3, I'm not sure.


  This code now passes for every .xpm I found in /usr on my Slackware build - 5243 .xpm files, some quite large (whole toolbars as ONE .xpm image). I had to remap the color "opaque" to "black" for one. It also passes for the google chrome .xpm icon, and a few others at work that I tested (including the ones I'm interested in). It failed for some v1 xpm files (which have a 100% C structure), but the original code couldn't handle those either. Maybe in a month or two if I get bored :-)

  Using a tcl 8.5 build, it parses all 5243 files and creates an image out of them in approx 8-9 seconds on my system (i5-3570k around 4 Ghz). I also wrote a small app to display the .xpm files in a scrolled window. You can run them as:
  xpmt `find . -name "*.xpm"`
  to test the parsing of the files (it prints output every 100 images)
  or
  xpmv `find . -name "*.xpm"`
  to display the images (it was nice to see that they appeared to visually look correct!)

  Note: you'll have to edit xpmv/xpmt to fix up the auto_path and where it sources the xpm2image.tcl file from.

  Please let me know if you need anything else, or anything is unclear.

  Cheers,
  Mattias


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  I am sorry, I have a bad feeling removing those commands.

  I often got into the trap that the original BWidget code by Eric is well thought and apparently useless things have a reason.

  A widget creation causes many other actions in the background which are not clear to me in total.

  Sorry for this defensive response.

  Maybee someone may convince me to include the patch.

  Sorry,
  Harald


login: oehhar
username: oehhar
mimetype: text/x-fossil-wiki
icomment:
  Committed by checkin [5a776453e1].

  I would love to be able to test it but I just trust it is ok.

  I removed spanish acentuation characters in your name in changelog.
  Sorry, I want to keep it 7 bits.
  Pardon pour el informatica si tonto ;-)

  Thank you,
  Harald


