tcl-core — Tcl Core Team discussions about Tcl development

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

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

--------

I got this from the Python-URL! for this week (Jul 18).

http://www.python.org/pipermail/python-dev/2000-July/013059.html

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

gnome canvas paper

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

--------

http://www.usenix.org/events/usenix2000/freenix/quintero.html

Thought it of interest since the Gnome canvas started from the Tk one.
Maybe it contains some ideas we could backport.


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

[TCLCORE] Re: Joe English given CVS access

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

FYI:

Joe has CVS access to the documentation trees for Tcl/Tk, to do various
cleanup and work on the XML documentation project.

   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: improved 64-bit support

[Don B. <do...@pi...>]

It seems that no-one's name is beside the
"improved 64-bit support".
What is the status of this? Is someone working
on it, or has someone got some notes on what
needs to be done?

If no one is working on this currently I will
volunteer to work on it.



 


begin 600 Don Bowman (E-mail).vcf

`
end

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

[TCLCORE] Re: Petasis and Bonnet given extension write access

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

FYI, George Petasis has been given write access to the tkdnd module
(as maintainer) and Frederic Bonnet has been given write access to
tkgs (as maintainer).

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: Patch to fix CFLAGS problems.

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

I wrote up this patch to fix the problem with Tcl not respecting
the CFLAGS variable set in the users env. If nobody has a problem
with it, I will add commit it to the CVS (along with the equivalent
patch to tk and the windows builds for tcl and tk).

Mo DeJong
Red Hat Inc

Index: unix/Makefile.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/Makefile.in,v
retrieving revision 1.66
diff -u -r1.66 Makefile.in
--- Makefile.in	2000/06/06 04:39:49	1.66
+++ Makefile.in	2000/07/19 00:40:49
@@ -87,7 +87,7 @@
 #CFLAGS			= $(CFLAGS_DEBUG)
 #CFLAGS			= $(CFLAGS_OPTIMIZE)
 #CFLAGS			= $(CFLAGS_DEBUG) $(CFLAGS_OPTIMIZE)
-CFLAGS			= @CFLAGS@
+CFLAGS			= @CFLAGS_DEFAULT@
 
 # To disable ANSI-C procedure prototypes reverse the comment characters
 # on the following lines:
Index: unix/configure.in
===================================================================
RCS file: /home/cvs/external/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/19 00:40:49
@@ -28,6 +28,7 @@
 #------------------------------------------------------------------------
 
 AC_PROG_RANLIB
+SC_ENABLE_SYMBOLS
 SC_ENABLE_GCC
 AC_HAVE_HEADERS(unistd.h limits.h)
 
@@ -408,11 +409,7 @@
 #--------------------------------------------------------------------
 
 SC_CONFIG_CFLAGS
-
-SC_ENABLE_SYMBOLS
-
 TCL_DBGX=${DBGX}
-CFLAGS=${CFLAGS_DEFAULT}
 
 #--------------------------------------------------------------------
 #	The statements below check for systems where POSIX-style
@@ -558,12 +555,16 @@
 
 AC_SUBST(BUILD_DLTEST)
 AC_SUBST(CFLAGS)
+AC_SUBST(CFLAGS_DEFAULT)
+AC_SUBST(CFLAGS_DEBUG)
+AC_SUBST(CFLAGS_OPTIMIZE)
+AC_SUBST(CFLAGS_WARNING)
+AC_SUBST(EXTRA_CFLAGS)
 AC_SUBST(CFG_TCL_SHARED_LIB_SUFFIX)
 AC_SUBST(CFG_TCL_UNSHARED_LIB_SUFFIX)
 AC_SUBST(CFG_TCL_EXPORT_FILE_SUFFIX)
 AC_SUBST(TCL_DBGX)
 AC_SUBST(DL_OBJS)
-AC_SUBST(EXTRA_CFLAGS)
 AC_SUBST(LDFLAGS)
 AC_SUBST(MAKE_LIB)
 AC_SUBST(TCL_SHARED_BUILD)
Index: unix/tcl.m4
===================================================================
RCS file: /home/cvs/external/tcl/unix/tcl.m4,v
retrieving revision 1.23
diff -u -r1.23 tcl.m4
--- tcl.m4	2000/07/17 08:26:31	1.23
+++ tcl.m4	2000/07/19 00:40:50
@@ -408,22 +408,16 @@
 # Arguments:
 #	none
 #	
-#	Requires the following vars to be set:
-#		CFLAGS_DEBUG
-#		CFLAGS_OPTIMIZE
-#		LDFLAGS_DEBUG
-#		LDFLAGS_OPTIMIZE
-#	
 # Results:
 #
 #	Adds the following arguments to configure:
 #		--enable-symbols
 #
 #	Defines the following vars:
-#		CFLAGS_DEFAULT	Sets to CFLAGS_DEBUG if true
-#				Sets to CFLAGS_OPTIMIZE if false
-#		LDFLAGS_DEFAULT	Sets to LDFLAGS_DEBUG if true
-#				Sets to LDFLAGS_OPTIMIZE if false
+#		CFLAGS_DEBUG
+#		CFLAGS_OPTIMIZE
+#		CFLAGS_DEFAULT	Set to $(CFLAGS_DEBUG) or
+#				Set to $(CFLAGS_OPTIMIZE)
 #		DBGX		Debug library extension
 #
 #------------------------------------------------------------------------
@@ -431,14 +425,24 @@
 AC_DEFUN(SC_ENABLE_SYMBOLS, [
     AC_MSG_CHECKING([for build with symbols])
     AC_ARG_ENABLE(symbols, [  --enable-symbols        build with 
debugging symbols [--disable-symbols]],    [tcl_ok=$enableval], [tcl_ok=no])
+    CFLAGS_DEBUG=-g
+    CFLAGS_OPTIMIZE=-O
     if test "$tcl_ok" = "yes"; then
-	CFLAGS_DEFAULT="${CFLAGS_DEBUG}"
-	LDFLAGS_DEFAULT="${LDFLAGS_DEBUG}"
+        if test -z "$CFLAGS" ; then
+            CFLAGS=${CFLAGS_DEBUG}
+            CFLAGS_DEFAULT='$(CFLAGS_DEBUG)'
+        else
+            CFLAGS_DEFAULT=${CFLAGS}
+        fi
 	DBGX=g
 	AC_MSG_RESULT([yes])
     else
-	CFLAGS_DEFAULT="${CFLAGS_OPTIMIZE}"
-	LDFLAGS_DEFAULT="${LDFLAGS_OPTIMIZE}"
+        if test -z "$CFLAGS" ; then
+            CFLAGS=${CFLAGS_OPTIMIZE}
+            CFLAGS_DEFAULT='$(CFLAGS_OPTIMIZE)'
+        else
+            CFLAGS_DEFAULT=${CFLAGS}
+        fi
 	DBGX=""
 	AC_MSG_RESULT([no])
     fi
@@ -512,17 +516,11 @@
 #                       The name of the built export / import file which
 #                       should be used to link to the Tcl shared library.
 #                       Empty if Tcl is unshared.
-#	CFLAGS_DEBUG -
-#			Flags used when running the compiler in debug mode
-#	CFLAGS_OPTIMIZE -
-#			Flags used when running the compiler in optimize mode
 #
 #	EXTRA_CFLAGS
 #
 #	Subst's the following vars:
 #		DL_LIBS
-#		CFLAGS_DEBUG
-#		CFLAGS_OPTIMIZE
 #--------------------------------------------------------------------
 
 AC_DEFUN(SC_CONFIG_CFLAGS, [
@@ -603,8 +601,6 @@
     TCL_TRIM_DOTS='`echo ${VERSION} | tr -d .`'
     ECHO_VERSION='`echo ${VERSION}`'
     TCL_LIB_VERSIONS_OK=ok
-    CFLAGS_DEBUG=-g
-    CFLAGS_OPTIMIZE=-O
     if test "$using_gcc" = "yes" ; then
 	CFLAGS_WARNING="-Wall -Wconversion -Wno-implicit-int"
     else
@@ -1192,9 +1188,6 @@
     fi
 
     AC_SUBST(DL_LIBS)
-    AC_SUBST(CFLAGS_DEBUG)
-    AC_SUBST(CFLAGS_OPTIMIZE)
-    AC_SUBST(CFLAGS_WARNING)
 ])
 
 #--------------------------------------------------------------------

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

[TCLCORE] Re: XML manpage conversion -- update

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

Hello,

I've done a little more work on the NROFF->XML->HTML
man page conversion; most of the cross-references are
working now.

In the process, a few other markup errors have turned up.
Could I get write access to the CVS repository, or would
you prefer a patch file?  I'd also like to add some of
the missing SEE ALSO sections and enhance the KEYWORDS
listings.

The TMML package (DTD and XSL specs for HTML output)
is close to being (alpha-)releasable; probably next
week sometime.

Haven't worked on back-converting the XML to NROFF --
I'm waiting for the Tcl-XML 2.0 release to stabilize
first.


--Joe English

  jen...@fl...

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

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