tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: [Fwd: tk dialog texts, german translaton, umlaut changes]

[Laurent D. <lau...@uf...>]

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

[TCLCORE] Re: Labeled frames (fwd)

[Eric M. <er...@aj...>]

Peter Spjuth is working on labeled frames for Tk 8.4.  Please read over
his thoughts on this below, and let's try to get some constructive
criticism back to him quickly.  My own comments follow Peter's proposal.

-------------------------------------------------------------------------
Hi!

I've started to work on adding labels to frames in Tk, and would appreciate
some input of what features people want. I've thought some about it and
below are my views of the subject.


1. Label contents.

This can be all from supporting a simple text to supporting all options of 
a normal label. I.e. some subset of the following standard options:
-text -font -justify -wraplength -underline
-textvariable -fg -bitmap -image

Instead of "-text", "-label" can be used, even though I can't understand
why one would want that. Personally I find it confusing that menuitems and
scales use "-label" when every other widget uses "-text" for the same thing.

Since I prefer a general solution, my goal is to support all of them.


2. Label placement.

I have looked at some widget sets to get a view of what is needed.
These widgets have the following settings for label placement:

BWidget, LabelFrame    : top, bottom, left, right
BWidget, TitleFrame    : left, center, right  
tixLabelFrame          : top, left, right, bottom, none, acrosstop
Iwidgets, labeledframe : ne,n,nw,se,s,sw,en,e,es,wn,w,ws

In addition, "TitleFrame" has a -baseline argument to set if the label
should be above, on, or below the border, and "labeledframe" has
-labelmargin to further control the placement.

I would choose to use -labelpos (ne,n,nw,se,s,sw,en,e,es,wn,w,ws) from 
Iwidgets and a variation of -baseline (inner, center, outer) from BWidget, 
which would be a nice general solution that covers all cases.

With "nw" as default for "-labelpos" and "center" as default for
"-baseline", a labeled frame as they are often used would be:
frame .f -text Hej -relief groove -bd 2


3. Frame padding

I think it's a useful feature to be able to add padding between the
frame border and the "child area". For this, these widgets use the
following options:

BWidget, TitleFrame    : -ipadx, -ipady
tixLabelFrame          : -padx, -pady
Iwidgets, labeledframe : -ipadx, -ipady

I think we should have them, and call them -padx/y. They are standard 
options and the behaviour here matches what I expect from them.


Comments?

/Peter

-------------------------------------------------------------------------

My primary concern with this proposal is that it seems too complex.  I
think that the support for labels on frames should be fairly minimalistic
-- specify an anchor (nw, n, ne, etc.), the text, and the font.  This
should address the most common uses (probably > 95% of all instances of
labeled frame usage).  I can't think of an instance of a labeled frame
that doesn't have the text vertically centered on the frame border, at
the top left side of the frame.  I don't think it's necessary to add
support for specifying the baseline for the label, or additional label
positioning tweaks.  I think that support for those features will just
make the widget harder to learn, harder to implement, and harder to
maintain.  If a programmer needs more flexibility in the positioning of
the label, they can always use the current method ([place] a label in the
right spot). I'm also not sure that we should immediately support
bitmap/images for the label.  This adds more complexity again, and I'm not
sure it's worth it.  I don't think I have ever seen a labeled frame that
used anything but text for the label.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: TkGS & TkDND imported into Tcl Dev Xchange NetCVS

[Jeffrey H. <jef...@aj...>]

TkGS, maintained by Bonnet and DeJong, and TkDND, maintained by Petasis,
have been imported and correctly added to the module list so that they
can be checked out under the names 'tkgs' and 'tkdnd' respectively.

One change was made to TkDND - the 'src' dir was renamed to 'generic'
to note that it has generic sources (next to the 'unix' and 'win'
sibling dirs that were already there).  I updated all instances of
'src/' that I could find before importing.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Does anyone see a problem with this threads related configure change?

[Mo D. <md...@cy...>]

I would like to remove the --enable-threads option from Tk
(and any other extensions for that matter). It does not
seem logical to be able to build Tcl without thread support
and Tk with thread support. Here is a patch that implements
this change, I want to make sure anyone that thinks it is
a bad idea gets a chance to object. This patch also
adds a TCL_THREADS variable to tclConfig.sh so that
extensions can find out if Tcl was compiled with
thread support.

Mo DeJong
Red Hat Inc

Index: unix/configure.in
===================================================================
RCS file: /cvsroot/tcl/unix/configure.in,v
retrieving revision 1.58
diff -u -r1.58 configure.in
--- configure.in	2000/05/03 00:15:10	1.58
+++ configure.in	2000/07/03 14:20:53
@@ -567,6 +567,7 @@
 AC_SUBST(LDFLAGS)
 AC_SUBST(MAKE_LIB)
 AC_SUBST(TCL_SHARED_BUILD)
+AC_SUBST(TCL_THREADS)
 AC_SUBST(SHLIB_CFLAGS)
 AC_SUBST(SHLIB_LD)
 AC_SUBST(STLIB_LD)
Index: unix/tcl.m4
===================================================================
RCS file: /cvsroot/tcl/unix/tcl.m4,v
retrieving revision 1.22
diff -u -r1.22 tcl.m4
--- tcl.m4	2000/04/14 06:42:41	1.22
+++ tcl.m4	2000/07/03 14:20:54
@@ -223,6 +223,27 @@
     AC_SUBST(TCL_BIN_DIR)
     AC_SUBST(TCL_SRC_DIR)
     AC_SUBST(TCL_LIB_FILE)
+
+
+    # We need to find out if Tcl was compiled with thread
+    # support. We can not build an extension with thread
+    # support if Tcl is not built with thread support.
+
+    AC_MSG_CHECKING([to see if Tcl was compiled with thread support])
+
+    if test "$TCL_THREADS" = "1"; then
+        # Define the following option so that they will
+        # be passed in the CFLAGS variable. We do not
+        # need to worry about THREADS_LIBS because that
+        # gets added to the LIBS variable.
+
+        AC_MSG_RESULT([yes])
+        AC_DEFINE(TCL_THREADS)
+        AC_DEFINE(_REENTRANT)
+        AC_DEFINE(_THREAD_SAFE)
+    else
+        AC_MSG_RESULT([no])
+    fi
 ])
 
 #------------------------------------------------------------------------
@@ -331,7 +352,10 @@
 #------------------------------------------------------------------------
 # SC_ENABLE_THREADS --
 #
-#	Specify if thread support should be enabled
+#	Specify if thread support should be enabled for Tcl. This
+#	macro can not be called from an extension's configure.in
+#	because it is not possible to build an extension with thread
+#	support if Tcl itself is not compiled with thread support.
 #
 # Arguments:
 #	none
@@ -347,6 +371,7 @@
 #	Defines the following vars:
 #		TCL_THREADS
 #		_REENTRANT
+#		_THREAD_SAFE
 #
 #------------------------------------------------------------------------
 
@@ -354,6 +379,13 @@
     AC_MSG_CHECKING(for building with threads)
     AC_ARG_ENABLE(threads, [  --enable-threads        build with threads],
 	[tcl_ok=$enableval], [tcl_ok=no])
+
+    # Make sure this macro is not getting include in an extensions
+    # configure.in by checking for the tcl.h include file.
+
+    if test ! -f ${TCL_SRC_DIR}/generic/tcl.h ; then
+        AC_MSG_ERROR([The --enable-threads macro can only be used in 
Tcl's configure.in])
+    fi
 
     if test "$tcl_ok" = "yes"; then
 	AC_MSG_RESULT(yes)
Index: unix/tclConfig.sh.in
===================================================================
RCS file: /cvsroot/tcl/unix/tclConfig.sh.in,v
retrieving revision 1.14
diff -u -r1.14 tclConfig.sh.in
--- tclConfig.sh.in	2000/06/20 21:30:34	1.14
+++ tclConfig.sh.in	2000/07/03 14:20:54
@@ -38,6 +38,9 @@
 # Flag, 1: we built a shared lib, 0 we didn't
 TCL_SHARED_BUILD=@TCL_SHARED_BUILD@
 
+# Flag, 1: we built Tcl with threads support, 0 we didn't
+TCL_THREADS=@TCL_THREADS@
+
 # The name of the Tcl library (may be either a .a file or a shared library):
 TCL_LIB_FILE='@TCL_LIB_FILE@'

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Tk patch

[<ldu...@sp...>]

Hi,

The following patch fixes a problem that was reported by George Petasis.

L

[TCLCORE] Re: tkDND release...

[Giorgos P. <pe...@II...>]

Dear Mr. Hobbs,

As both developers of the tkDND extension (me and Laurent) are
leaving for vacations, we have decided to make a release of our current
code in order to be in time for the tk8.4a2 release. We will be back
by the mid of August...

I also think that this is a good time to add tkDND to your cvs server.
Please inform me for the necessary steps I have to do before tomorrow 
(if any :-))

The current status of tkDND is as follows:

Currently only unix & windows versions are available.

Unix:
Everything is working. A few things missing from the Motif protocol.
No known bugs :-)

Windows:
Main functionality working. There are some known problems.

Code for both platforms is compiling with out warnings and does not
cause wish to crash.
Unix side is in C only and is TEA compliant (I hope :-)).
Tested under solaris & linux. Supported protocol is XDND
extended with Motif drops. Motif drag is not fully functional yet.

There is a man page and a few tutorials in the demo directory.
Currently no tests (how can something like this be tested?)

The windows code is not as well structured as the unix code, but we
plan a re-write from scratch. We are now at the process of reading 
the OLE dnd manuals :-)

Please inform me (pe...@ii...) what your plans for the extension are
ASAP. Is it going to actually be in tk8.4a2? My opinion is that at least the unix
code should be in order to gain feedback from end users...

The home page for tkDND is at http://www.iit.demokritos.gr/~petasis/tcl

Best regards,

George

RE: Translations strings in CVS

[Jeffrey H. <jef...@aj...>]

> In Dai, 13 Eiye 2000, Jeffrey Hobbs wrote:
> > There is a limitation on exactly how some characters can be sent to
> > the event mechanism, because it requires the X-style translated
> > name, but this seems to have been accepted OK for me (via C&P because
> > I can't directly type in that character):
> >
> > (tkcon) 53 % bind .t \373 { puts "K %K A %A"}
> > (tkcon) 54 % bind .t ? { puts "K %K A %A"}
> > (tkcon) 55 %
> 
> Well for me, under tkcon 1.6, 31 March 1999 does not work.
	...
> bad event type or keysym "?"

Actually, I fooled myself.  My original thoughts were correct in that
it requires the X-style name.  Eric added the new 'keysyms' page to
show all these.  This doesn't work in 8.3.1 WinHelp, but you can see
it in the Unix docs of 8.4a1 at:
	http://dev.scriptics.com/man/tcl8.4/TkCmd/keysyms.htm

>Main< (tkcon) 60 % puts \374
u
>Main< (tkcon) 61 % bind .t \374 { puts " u umlaut " }
>Main< (tkcon) 62 % bind .t <Alt-\374> { puts " u umlaut " }
bad event type or keysym "u"
>Main< (tkcon) 63 % format %o 252
374
>Main< (tkcon) 64 % bind .t <Alt-udiaeresis> { puts " u umlaut " }

You'll have to find out what the correct mapping for that greek
character is.  If I do:

>Main< (tkcon) 71 % scan ? %c
240

Then I can see that 240 in the table in the URL above gives 'eth',
and then we have:

>Main< (tkcon) 73 % bind .t <Alt-eth> { puts " eth " }
>Main< (tkcon) 74 % 

Of course, I can't type in the eth here...

This will be something that everybody has to deal with.  One heuristic
is that if [scan $char %c] >= 127, then you'll need to have a mapping
for that character.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

[TCLCORE] Re: RE: Translations strings in CVS

[Jeffrey H. <jef...@aj...>]

There is a limitation on exactly how some characters can be sent to
the event mechanism, because it requires the X-style translated
name, but this seems to have been accepted OK for me (via C&P because
I can't directly type in that character):

(tkcon) 53 % bind .t \373 { puts "K %K A %A"}
(tkcon) 54 % bind .t ð { puts "K %K A %A"}
(tkcon) 55 %

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

> -----Original Message-----
> From: Giorgos Petasis [mailto:pe...@ii...]
	...
> But the "Retry" button was now in greek. Tkcon, underlined the first character
> and while trying to impose a binding on the first letter (the greek
> p), an error
> occured: "bad event type or keysym "ð"".

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: FW: Q about managing open source development

[Jeffrey H. <jef...@aj...>]

Here are some responses to more comments from Jeff Law (former maintainer
of gcc development).  Insightful.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 9:07 PM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development 



  In message <NDB...@aj...>you
 write:
  > > So we contacted a group of folks, not necessarily all developers, that ha
  > d
  > > a long term interest in seeing GCC succeed and who were well respected
  > > in different communities that used GCC.   The steering committee basicall
  > y
  > > deals with political issues, not technical ones (which we leave in the ha
  > nds
  > > of the developers, where it belongs).  We've been very happy with the res
  > ults.
  > 
  > What is the difference between "political" and "technical" issues for you?
Political is anything non-technical :-)

ie, stuff like who's in charge of releases, when/who do we give global 
write access to the tree, how to deal with problem posters and dealing with
making sure that nobody's taking advantage of their position within the
project to push an agenda that is not in the project's best interest.

ie if Cygnus/Red Hat was to try and close development to not include its
competitors it's the steering committee's responsiblity to step in and
take appropriate action -- which would likely be revoking any write privs
for Cygnus/Red Hat folks that were taking advantage of their positions within
the project.

They're the 'or else'  behind the "play by the rules we've established or
else ..." way we run the project.


  > In creating the steering committee, is it functionally a figure-head group?
Nope.  They're not a figure-head group, but the hope is that there aren't
a lot of political kinds of things to do on a regular basis.  ie, most of
the work in a free software project *should* be technical.  Make the code
better (by whatever measurement of better is appropriate) -- not dealing with
infighting between developers :-)

  > We are trying to determine how to set up the technical future decision
  > making process, and thought that the steering committee would be used for
  > that.
It could.  It does to a small extent for GCC -- mostly in areas where
technical decisions have the potential for significant political consequences.

For example a technical direction which would ultimately undermine the FSF's
core goals/values would be one where the steering committee would have to 
step in and say "sorry, you can't do example, making sure that Cygnus/Red Hat
doesn't take advantage of having a large number of contributors and steer
the project away from its core goals.

It's definitely not a figure-head group, though in theory a steering
committee to deal with political issues shouldn't have a whole lot to
do in a technical free software project :-)  Though they do come up from
time to time.

Consider if there was some patches which made it easy for people to write
new front-ends or optimization passes that where not part of GCC (ie they
communicated with GCC via pipes/files).  That would undermine the FSF's
stated goals and the steering committee would have to get involved and
prevent such patches from being installed (and take appropriate action if
someone violated that decree).

  >   One model that the Apache Software Foundation uses is that incoming
  > ideas can be vetoed by a single member, and otherwise ideas must get at
  > least two supporting votes before getting in.  Who controls those kind of
  > feature related issues in gcc?
That's mostly hashed out on the development lists.  Sometimes the arguments
get a little heated, but they usually work themselves out.  We do not allow
a single member of either the technical community or the steering committee
to block actions.  That was done on purpose to prevent one person from 
instigating gridlock by just vetoing everything they didn't like.

That takes some time for people to get used to, but I think it's worked out
reasonably well.

Basically the core ideas behind the project stem from what was so badly
messed up in GCC development before the EGCS project was started.  Single
personalities were able to control/stall development simply by being
jerks and were able to move the project in what most developers considered
the wrong direction simply because those one or two people ultimately
controlled every aspect of the project including dissemination of information.

jeff

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Translations strings in CVS

[Giorgos P. <pe...@ii...>]

Hi all,

I have found a typo in the greek translations.
Attached you will find the updated file.

Also, in the version of tk I downloaded from cvs server 2 days ago,
when an error occurs, the button labeled "Details >>" does not
use the translated string. Is this now fixed?

Well, to say the truth it is a surpise to see messages in your native language.
I like it. And tk probably looks the LANG & LC_* vars under unix to automatically
use the correct language! If only the system encoding was set automatically too :-)

George

[TCLCORE] Re: Translations strings in CVS

[Giorgos P. <pe...@ii...>]

Hi all,

I was checking the massages for the greek language and I think that there is
a problem regarding the underlines & bindings.
Although the dialogs seem to work ok (at least the open/save that I tried),
the underlines appear at odd places (even under spaces :-))
But this is not the problem: I was using tkcon and when issued a 
tk command, the dialog appeared that said "this appears to be a tk command...".
But the "Retry" button was now in greek. Tkcon, underlined the first character
and while trying to impose a binding on the first letter (the greek p), an error
occured: "bad event type or keysym "ð"".

This may be a specific tkcon bug, but are we sure that there will be no problems 
in the tk core? In the messages for various languages is not defined a location
for placing underlines and using bindings. Tk seems to not support bindings for
non latin-1 characters, so should we modify things to not assign bindings 
under non english languages?

(Have I lost anything from previous discussions? :-))

George

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Translations strings in CVS

[<lau...@uf...>]

On 12 Jul, Giorgos Petasis wrote:
> Hi all,
> 
> I have found a typo in the greek translations.
> Attached you will find the updated file.
> 

Thanks.

> Also, in the version of tk I downloaded from cvs server 2 days ago,
> when an error occurs, the button labeled "Details >>" does not
> use the translated string. Is this now fixed?
> 

Hmm.... I thought that was fixed a long time ago. I'll look into it later
today.

> Well, to say the truth it is a surpise to see messages in your native language.
> I like it. And tk probably looks the LANG & LC_* vars under unix to automatically
> use the correct language! If only the system encoding was set automatically too :-)
> 

Yep. Once we get the -underline and key binding problem out of the way,
things should be real dandy.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Translations strings in CVS

[<lau...@uf...>]

On 12 Jul, Giorgos Petasis wrote:
> Hi all,
> 
> I was checking the massages for the greek language and I think that there is
> a problem regarding the underlines & bindings.

It's not really a "problem", it's more of an "issue". It hasn't been
implemented correctly yet. There have been some discussions on how to best
address this but all the proposals to fix things have met with skepticism
from one person or another. There is a thread in clt on the underline
problem that is raging right now.

I must admit that as time passes by, I'm getting a little bit edgier about
this because, even though the translations work fine, the bindings and
underlines are so badly broken that the translations become a hindrance more
than anything else. It'll be fixed soon, though. We just have to come up
with a proper scheme to do things. I also have to dig up some conversations
I had on the subject with Eric Melski and Mr. Takahashi.

> Although the dialogs seem to work ok (at least the open/save that I tried),
> the underlines appear at odd places (even under spaces :-))

Yeah, sucks rocks, really.

> But this is not the problem: I was using tkcon and when issued a 
> tk command, the dialog appeared that said "this appears to be a tk command...".
> But the "Retry" button was now in greek. Tkcon, underlined the first character
> and while trying to impose a binding on the first letter (the greek p), an error
> occured: "bad event type or keysym "ð"".
> 

That may have something to do with the above. Is the keysym above the greek
"P"? My Greek is kinda rusty... :-)

> This may be a specific tkcon bug, but are we sure that there will be no problems 
> in the tk core? In the messages for various languages is not defined a location
> for placing underlines and using bindings. Tk seems to not support bindings for
> non latin-1 characters, so should we modify things to not assign bindings 
> under non english languages?
> 
> (Have I lost anything from previous discussions? :-))
> 

Probably a bit.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Greek message files & tkDND...

[Giorgos P. <pe...@ii...>]

Hi all,

The last mail I sent you containing the Greek messages is working
fine under the tk version I downloaded yesterday from the cvs server.
The oriinal file, encoded in utf-8 does not. Please update your cvs server...

BTW, seems that there was an internal rearrangement in tkIconList widget
used internally by the open/save dialogs. Key navigation does not work any
more. I have also used the bug report system to submit it....

Now regarding the tkDND extension, the progress is as follows:

1) The unix side is working fine. There are still a problem regarding the drop
of multiple files from GNOME, where an additional " 0x00" is appended.
New features include the use of modifiers in bindings (an idea & implemetation
from Laurent Riesterer) like in tk (for example Control-Drag).
We haven't got the time to add code for enabling the drag source to specify 
cursor, and we left it for future work.

2) The windows side is updated, but there are still a few bugs. tkDND does not
cause wish to crash, but I expect some "advanced" features to misbehave.
Reading the specs of OLE dnd, seems that windows side will have
some limitations (notably the inability to use the "ask" and "private" actions).
Of course scripts that use these actions will still work (an error won't be raised)
but these actions would never be used for dnd under windows.
Both Laurent and I plan to rewrite the whole windows part, as the code is not
so well structured as is under unix (at least to my opinion :-)).
But we both are going to leave for vacations this week, and I think
that we have to make a release with the code we have, in order to catch
the 8.4a2 release at the end of the month.

You should expect the code by the end of this week.

Also, just curious, how do you plan to incorporate it into the tk core?
The code as is write now builds a loadable (stubs enabled under unix)
extension. Will it remain that way, or will be mixed with the tk core?

George

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: RE: Translations strings in CVS

[Giorgos P. <pe...@II...>]

Mr. Hobbs,

I used the scripts from Jan Nijtmans to convert my messages from utf-8
to \u sequences. I attach the new file, please update the tk core...

George

[TCLCORE] Re: Translations strings in CVS

[<lau...@uf...>]

On 11 Jul, Giorgos Petasis wrote:
>> As for the Hellenic, I just want to check to make sure that got
>> imported correctly.  The best thing about using \u00xx is that
>> it can't get garbled in something that doesn't understand high
>> bit chars.
> This is logical, although I suspect that tcl can understand them :-)
> And for those who don't know how to create these \u sequences, is
> there a simple procedure in tcl in order to translate them?
> 

Did you try Jan's utility? Does that work? My understanding is that if you
save stuff in the Unicode format, you're no supposed to have all the
conversion problems that you find when using UTF-8. But then, I'm new at
this.

> Sorry for the incovinience,
> 

It's no problem. We'll eventually get all of this right but it might take a
misstep or two along the way.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: RE: Translations strings in CVS

[Giorgos P. <pe...@ii...>]

In Äåõ, 10 Éïýë 2000, Jeffrey Hobbs wrote:
> Hellenic (el.msg) comes across in something
> that I can't view correctly on Windows or Unix (I do have
> bitstream cyberbit on Windows, but no specific Greek font).
I suppose I am the only one who used UTF-8 to encode the messages :-)
The file I sent was encoding using utf-8. I really cannot understand why to
use strange alternative ways in order to specify messages. My opinion is that
the message catalog should encode all its messages in utf-8 and use this encoding
when sourcing the files. Any way, I am willing to translate them into whatever
you want :-). 
Also, Laurent told me that he also had problems opening the files.
I attach the file again, this time is zipped with gzip.

> As for the Hellenic, I just want to check to make sure that got
> imported correctly.  The best thing about using \u00xx is that
> it can't get garbled in something that doesn't understand high
> bit chars.
This is logical, although I suspect that tcl can understand them :-)
And for those who don't know how to create these \u sequences, is
there a simple procedure in tcl in order to translate them?

Sorry for the incovinience,

George

[TCLCORE] Re: Translations strings in CVS

[Andreas K. <a.k...@we...>]

 
> Jeffrey Hobbs wrote:
> > My thoughts... I think local languages should attempt to truly
> > localize.  This may work best the way the Spanish msgs are done -
> > (as well as French) in that \u00xx is used for high bit encodings.
> > I think the German (and partly the Dutch) messages should use
> > umlauted chars and the S-sharp where appropriate (or does MS avoid
> > this as well?).

> > As for the Hellenic, I just want to check to make sure that got
> > imported correctly.  The best thing about using \u00xx is that
> > it can't get garbled in something that doesn't understand high
> > bit chars.

> > George - please verify (by checking the file back out of 8.4
> > CVS and trying it) that this didn't get garbled.
 
> I already noted this as well, and all I can say is that I fully
> agree with you.
 
> Attached is a small utility that can do the correction. Just try:
>       msgcv el.msg cp1253
>       msgcv ja.msg euc-jp

> and the result is two new files "el.msg.out" and "ja.msg.out"
> using the '\uXXXX' convention. It should be easy to apply
> this to the message files in CVS now. For german, the umlaut-
> correction should be done manually first.

I agree and will do it (Now that I know the umlaut-codes (:- Wiki)).


-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Re: Translations strings in CVS

[Jan N. <j.n...@ch...>]

Jeffrey Hobbs wrote:
> My thoughts... I think local languages should attempt to truly
> localize.  This may work best the way the Spanish msgs are done -
> (as well as French) in that \u00xx is used for high bit encodings.
> I think the German (and partly the Dutch) messages should use
> umlauted chars and the S-sharp where appropriate (or does MS avoid
> this as well?).
> 
> As for the Hellenic, I just want to check to make sure that got
> imported correctly.  The best thing about using \u00xx is that
> it can't get garbled in something that doesn't understand high
> bit chars.
> 
> George - please verify (by checking the file back out of 8.4
> CVS and trying it) that this didn't get garbled.

I already noted this as well, and all I can say is that I fully
agree with you.

Attached is a small utility that can do the correction. Just try:
      msgcv el.msg cp1253
      msgcv ja.msg euc-jp
and the result is two new files "el.msg.out" and "ja.msg.out"
using the '\uXXXX' convention. It should be easy to apply
this to the message files in CVS now. For german, the umlaut-
correction should be done manually first. The Dutch translation
is already in the correct format ;-)

Regards,
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/

Re: RE: Translations strings in CVS

[<ldu...@uf...>]

> I was just reviewing the msg catalog translation strings, and I had
> some questions.
> 
> There seems to be different methods used for encoding the files.
> The Spanish msgs use the \u00xx for extended chars, whereas the
> German msgs avoid them by using the lower ascii expansion
> (&uumlaut; == ue).  Hellenic (el.msg) comes across in something
> that I can't view correctly on Windows or Unix (I do have
> bitstream cyberbit on Windows, but no specific Greek font).
> 

I think it because not everyone used the same tools to create the
message catalogue. I used MSGEdit, I think a few others did too (most
likely, the ones that came out with \u00xx). Some used standard editors
which did the output however they felt was best.

> I know this was somewhat discussed, but it looks like no certain
> resolution was imposed.
> 

Uhm... imposed, no. Suggested, yes. I think George had said that the
files he had couldn't be read by the msgcat utility. So he did it how
best he could.

Jan sent us a note today saying he has a little utility that possibly
fixes the problem with George's file. If it does, George will hopefully
be able to send you another version of his translations.

L

Re: Translations strings in CVS

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii
 
> Jeffrey Hobbs wrote:
> > My thoughts... I think local languages should attempt to truly
> > localize.  This may work best the way the Spanish msgs are done -
> > (as well as French) in that \u00xx is used for high bit encodings.
> > I think the German (and partly the Dutch) messages should use
> > umlauted chars and the S-sharp where appropriate (or does MS avoid
> > this as well?).

> > As for the Hellenic, I just want to check to make sure that got
> > imported correctly.  The best thing about using \u00xx is that
> > it can't get garbled in something that doesn't understand high
> > bit chars.

> > George - please verify (by checking the file back out of 8.4
> > CVS and trying it) that this didn't get garbled.
 
> I already noted this as well, and all I can say is that I fully
> agree with you.
 
> Attached is a small utility that can do the correction. Just try:
>       msgcv el.msg cp1253
>       msgcv ja.msg euc-jp

> and the result is two new files "el.msg.out" and "ja.msg.out"
> using the '\uXXXX' convention. It should be easy to apply
> this to the message files in CVS now. For german, the umlaut-
> correction should be done manually first.

I agree and will do it (Now that I know the umlaut-codes (:- Wiki)).


-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

RE: Translations strings in CVS

[Jeffrey H. <jef...@aj...>]

I was just reviewing the msg catalog translation strings, and I had
some questions.

There seems to be different methods used for encoding the files.
The Spanish msgs use the \u00xx for extended chars, whereas the
German msgs avoid them by using the lower ascii expansion
(&uumlaut; == ue).  Hellenic (el.msg) comes across in something
that I can't view correctly on Windows or Unix (I do have
bitstream cyberbit on Windows, but no specific Greek font).

I know this was somewhat discussed, but it looks like no certain
resolution was imposed.

My thoughts... I think local languages should attempt to truly
localize.  This may work best the way the Spanish msgs are done -
(as well as French) in that \u00xx is used for high bit encodings.
I think the German (and partly the Dutch) messages should use
umlauted chars and the S-sharp where appropriate (or does MS avoid
this as well?).

As for the Hellenic, I just want to check to make sure that got
imported correctly.  The best thing about using \u00xx is that
it can't get garbled in something that doesn't understand high
bit chars.

George - please verify (by checking the file back out of 8.4
CVS and trying it) that this didn't get garbled.

Thanks,

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

[TCLCORE] Re: FW: Q about managing open source development

[Jeffrey H. <jef...@aj...>]

I thought I should share this with everyone on the core list as
we start considering how to open this process up.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 11:54 AM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development




  In message <NDB...@aj...>you
 write:
  > I got your name from Jim Ingham, who noted that you'd be a good person
  > to ask about experiences related to managing an open software development
  > effort (gcc).
As good as any I suppose :-)

  > I'm currently the lead maintainer and manager of Tcl/Tk,
  > but I've also been imbued with the responsibility by John Ousterhout
  > (the original author and CTO of Ajuba) to foster better community
  > involvement in the development.
Understood.

  > Tcl/Tk has always been open source and
  > invited people to hack on it, but in general the core parts have been
  > fairly strictly controlled over its lifetime (you could say it lies in
  > the Cathedral).  So my job is to move it more towards the Bazaar, while
  > trying to avoid the disadvantages of that development model.
Right.  That's the 'trick' of course -- to reap the benefits of a Bazaar
model without the code turning into a mess of spaghetti code.

  > The main ideas that have come up are opening direct CVS write access
  > to more people (it's already in public NetCVS), and creating a
  > steering committee.
Sound like the right steps.  The first (hopefully) leads to more active
participation from developers and a wider team of "core" contributors that
everyone trusts to do the right thing.

That's one of the key things you want to build up -- a larger group of
folks that you trust to do the right thing and to whom you can delegate
tasks (or better yet, they just pick them up because they need to be done).

That's also the first big pitfall -- get the wrong group of core folks and
you end up with a mess of code or personality conflicts that rip the project
apart (witness the *bsd* splinters over the years).

The other big pitfall is just learning to trust a wider range of folks and
even if you disagree with them sometimes to realize that if you can't design
and implement a better solution (usually due to time constraints), then
sometimes you have to let them go in a direction that maybe you wouldn't.

  > I noticed that the gcc steering committee was
  > formed of people "to represent the interests of [different] communities".
  > Did this prove to work well?  I am currently making the decision on
  > who should be considered for the steering committee (or on what basis).
This was both a practical and political move -- people have been more
comfortable knowing that it wasn't just Cygnus (or me) calling the shots.
It's been extremely valuable in dealing with RMS and some conspiracy theory
folks.

But is was also a very practical move -- in the past GCC had been controlled
by two people (RMS on the policial side, Kenner on the development side) and
experience had shown us that that model simply wasn't working and we had to
try something different.

So we contacted a group of folks, not necessarily all developers, that had
a long term interest in seeing GCC succeed and who were well respected
in different communities that used GCC.   The steering committee basically
deals with political issues, not technical ones (which we leave in the hands
of the developers, where it belongs).  We've been very happy with the results.

Overall, the biggest thing I've found is if you make the developers happy,
they'll want to contribute more time/energy.  That in turn allows the project
to grow.  If the developers are unhappy, then you have to find out why and
rectify the problem.

  > I'd appreciate it if you could share with me any insight on what to
  > watch out for, based on your experience, as I move forward with this.
  > Perhaps also what you would have done differently.
I (personally) would not have gotten buddy-buddy with RMS again, it's been
a major headache, but I was outvoted on that particular issue.  The lesson
is be very careful who you bring into the political decision process; people
who are not willing to compromise for the overall good of the project are
generally bad choices :-)

Good luck,
jeff


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: QT Developer Interview

[Jeffrey H. <jef...@aj...>]

I got this off slashdot.  It's part 4 of an interview with one of
the Qt Toolkit developers.  I picked this part, because it is where
he discusses (just shortly), his experiences with distributed
development in the Qt project:
	http://www.beopen.com/features/interviews/wallison_part4.html

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Final MSGedit fixes

[Jan N. <j.n...@ch...>]

lau...@uf... wrote:
> http://www.tu-harburg.de/~skfcz/msgedit.tar.gz
> 
> There is a bug with the program, though: some of the strings contain "\n"'s
> and msgedit saves these strings as "\\n". The saved files will need to be
> edited to correct this problem.

Here is, finally, the fix for the described problem. Just apply this
patch to the standard MSGedit distribution and everything should be O.K.

The cause of this problem was a wrong ordering of substitutions before
saving the string. The result was that in the case of '\n' the
backslash was doubled. Performing the double-backslash substitution
before the '\n'-substitution fixes everything.

Regards, 
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/