From: Donald G P. <dg...@em...> - 2002-08-13 14:28:10
|
> TIP #106: ADD ENCODING ABILITIES TO THE DDE COMMAND=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Extend the [dde] command by the option _-encoding_. For example:=20 >=20 > dde -encoding system execute CS CS {[Set(Var,"=C4pfel"]} Does this mean that dde execute CS CS [encoding convertto system {[Set(Var,"=C4pfel"]}] =09 does not work properly? If that's the case, I'd think that's a bug that needs fixing. Fix the bugs so that separate primitive commands can be composed effectively. Use composition via command substitution to combine primitives into more complex behavior, rather than creating ever more complex commands. =09 | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: <ke...@ac...> - 2002-08-13 16:57:28
|
vi...@sa... said: > I don't understand the problem here. Surely 'dde' should always use > the system encoding (except, perhaps if a '-binary' flag were given), > in just the same way that the clipboard, the filesystem, the native > dialogs and everything else uses the system encoding. We have sacrificed a lot here for compatibility with Win95/98. On NT/2k/XP, there are full 'W' versions of all the DDE calls, and you can transfer everything UCS-16. The 'A' versions, by the way, use the system 8-bit encoding; that's cp1252 on US windows but other codepages on international ones. Win98 also does more than the book says it does in terms of Unicode and DDE. If we can have a separate code path for Win95, then there's a lot of opportunity to clean this up. I do not see a convincing reason for the DDE encoding to be anything other than the system 8-bit encoding or UCS-16. (Application bugs may also require some sort of raw binary, alas.) -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@ac... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Jeff H. <JeffH@ActiveState.com> - 2002-08-16 07:02:20
|
> We have sacrificed a lot here for compatibility with Win95/98. > On NT/2k/XP, there are full 'W' versions of all the DDE calls, and > you can transfer everything UCS-16. Oh, too true. I only pulled out the win32s support just before 8.3. There are bugs in Tcl/Tk due solely to attempts to be compatible across all Win* platforms. > Win98 also does more than the book says it does in terms of Unicode > and DDE. If we can have a separate code path for Win95, then there's > a lot of opportunity to clean this up. It may be coming to the point post-8.4 that we say Win95 is just not a supported platform. To Microsoft it is already dead, and FWIW it is already not a supported platform for ActiveState across the languages. Jeff |
From: Harald O. <har...@el...> - 2002-08-19 09:04:55
|
Dear Kevin, dear Darley, about your e-mails, just some general points: * If you want to transfer Data from one TCL interpreter to another you need unicode. Fill a Variable with some greek characters (set A \u394) and request it via DDE - it will work (and you will see it if your windows can display greek character sets which is the case since Win98 in the german version). This can not be done with the system coding because you can not represent the used character (Greek capital Delta). Thus transfering with the native character set will break this functionality (supposing you use cp1252). * if you want to transfer data to non-tcl programs most can only use the system encoding. It exists a clipboard format for wide characters but this is in my experiance rarely supported for DDE by other programs, at least not in my field in my surrounding (Industrial Logistics and western Europe). * The clipboard has a protocol which allows to interrogate the format. For this reasons, it is possible to propose a wide string and, if the application does not support it, a string with the system encoding. This is not the case for DDE communication. For that reason anybody uses CF_TEXT with the system encoding. Best regards, Harald Oehlmann |
From: <ke...@ac...> - 2002-08-16 15:00:17
|
har...@el... said: > If we fix it to work for external programs we will loose the > possibility to communicate with another tcl interpreter and exchange > non system-encodings characters. Nonsense. We need to fix it to use the wide-character versions of the DDE calls throughout, and simply pass UCS-16 everywhere. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@ac... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2003-03-17 16:34:10
|
Team, Vince Darley informs me that he considers TIP #113 ready for vote. Discussion appears to have been dormant. If no further discussion arises by noon, Eastern Standard Time (1700 UTC) on Friday, March 22, I plan to call the vote. Kevin -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2003-09-22 13:13:31
|
vi...@sa... said: > One example of why I far prefer the 'alternative' which this TIP > rejects. You want to bind Enter, but instead have to bind Mod4-Return. > Even the TIP authors were confused and wrote the wrong code! I commit that gaffe regularly, anyway, because I never can seem to remember that the key marked, 'Enter,' on my keyboard generates an X keysym named, '<Return>.' In my opinion, the proposed change makes that problem neither better nor worse. > Neither the TIP nor the patch cited makes clear what changes you > expect to make to Tk's man pages to explain the peculiar handling of > these keys. Perhaps it would be helpful to explain the differences > between the 'KP_Enter' alternative (man page becomes simpler if > anything) and what you propose. Hmm, it appears to me that either change would make the man page considerably longer, since it fails to stand on its own but refers to external documentation of the X Window System -- a peculiarity in this age when a majority of Tk's user base is on Windows. Proper documentation would enumerate the keysyms to be found on Windows (and Macintosh?). Of course, the problem with documenting the thing is that we struggle with platform dependencies. For what it's worth, I experimented with eXceed and the RealVNC client for Windows, and discovered that both come out of the box generating a <Return> event where I'd expect to see <KP_Enter>. (Perhaps they're configurable; this was just a quick test.) Even the Unix developers who have to deal with remote displays wind up grappling with this issue, and I don't have a really good solution. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Vince D. <vi...@sa...> - 2003-09-22 14:09:22
|
On Mon, 22 Sep 2003, Kevin Kenny wrote: > Hmm, it appears to me that either change would make the man page > considerably longer, since it fails to stand on its own but refers to > external documentation of the X Window System -- a peculiarity in this > age when a majority of Tk's user base is on Windows. Proper documentation > would enumerate the keysyms to be found on Windows (and Macintosh?). Sure, that would be nice, but I didn't think the TIP was proposing a thorough overhaul of Tk's 'bind/event/keysym' documentation. However... > Of course, the problem with documenting the thing is that we struggle with > platform dependencies. ...and since this TIP explicitly creates a new such platform dependency, I would hope the TIP is also going to document it. That's why I asked what that documentation would look like. I currently believe the new documentation will be quite ugly and make clearer why the TIP isn't a good idea as it stands, but, perhaps I'll be convinced otherwise when I see it! cheers, Vince. |
From: Benjamin R. <Ben...@ep...> - 2003-09-22 14:58:46
|
Hi Kevin, ke...@cr... (Kevin Kenny) writes: > Hmm, it appears to me that either change would make the man page > considerably longer, since it fails to stand on its own but refers > to external documentation of the X Window System As I see it, this one goes against the obvious intention of the X11 docs and headers, so IMO it should better be documented as an intentional deviation from X11 practices in the Tk man pages. > For what it's worth, I experimented with eXceed and the RealVNC > client for Windows, and discovered that both come out of the box > generating a <Return> event where I'd expect to see <KP_Enter>. Hm, that's curious. I'm rather inclined to just suspect those as bugs, maybe because the KF_EXTENDED flag is so badly (and vaguely) documented in the Windows API. In the docs that I have read, the flag didn't even have a name. benny |
From: <ke...@cr...> - 2003-10-15 18:37:21
|
vi...@sa... said: > This sounds like it is actually a command that is valuable for > production usage of Tcl, not just during development, which goes > against the previous discussion which claimed unload is only valuable > as a development-aid. Exactly the point of my earlier posting. To be clear: I have wanted [unload]-like functionality in production. I recognize that my application is unusual, and even given that, I might have [unloaded] something a handful of times (per workstation) in the last five years. Therefore, I don't think it is *often* valuable, but it is, as I've said, damned inconvenient not to have it on the (admittedly, extremely rare) occasions that I *do* want it. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2004-03-24 14:32:28
|
vi...@sa... said: > Can you have the TIP clarify what a Tk developer is supposed to do in > the future to write a x-platform application with different enter > keys? > As I understand things, the developer must do this: > bind ... <Return> "pressReturn" bind ... <KP_Enter> "pressEnter" ; # > only useful on Unix bind ... <Extended-Return> "pressEnter" ; # only > useful on Windows > Is this correct? The developer must now make two totally separate > bindings to ensure x-platform behaviour is correct? Alas, yes, that is correct. Alas, I've not found any other way to do it that doesn't break a ton of existing code that is written under the assumption (ubiquitous on Windows) that the two keys are the same. I'm betting that this will seldom be a problem in practice. If you want Windows users to use your app, you better not make the two Enter keys do separate things. It's an unusual app that worries about x-platform portability without also worrying about native look&feel. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Vince D. <vi...@sa...> - 2004-03-24 15:15:12
|
On Wed, 24 Mar 2004, Kevin Kenny wrote: > Alas, yes, that is correct. Alas, I've not found any other way to > do it that doesn't break a ton of existing code that is written under > the assumption (ubiquitous on Windows) that the two keys are the same. What happened to the option of turning 'KP_' into a modifier in the same way that 'Extended-' would be a modifier? That would of course also change behaviour on Unix, but in a good way (i.e. any application that didn't bother to bind any KP_ keys would automatically have those keys trigger the corresponding normal bindings). This would also remove the other bug with this TIP: that both before and after this TIP, 'bind ... KP_Enter $cmd' would do nothing at all on Windows. > I'm betting that this will seldom be a problem in practice. If you > want Windows users to use your app, you better not make the two Enter > keys do separate things. That's an argument as much for going with the status-quo and rejecting this TIP outright as it is /for/ this TIP! > It's an unusual app that worries about x-platform portability without > also worrying about native look&feel. As a generic sentiment this is true. With respect to the issue at hand I would say it's just not relevant at all: either the application has a valid separate use for Return vs Enter or it doesn't. In the first case, on all platforms it will bind them separately (ignoring the MS edict) and in the second case it will bind them the same, again on all platforms. As for MacOS X, to answer Benny's question, since we don't have a legacy issue, I would recommend making the code do the same as on X11. cheers, Vince. |
From: <ke...@cr...> - 2004-03-24 15:31:43
|
vi...@sa... said: > What happened to the option of turning 'KP_' into a modifier in the > same way that 'Extended-' would be a modifier? That's more or less where I'm trying to go with 'Extended-'. 'KP_' doesn't have much to recommend it over 'Extended-' because the key names don't all match. There are differences in that the KP_ symbols are all in CamelCase while some of the ones on the conventional keyboard are lowercase. Also, 'KP_Enter' doesn't match 'Return'. Modifying the code so that the X11 side would generate <Extended-> symbols as well would be (IMHO) a good thing. That part, however, is an incompatible change, and properly the subject of a separate TIP. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2004-04-07 17:06:23
|
vi...@sa... said: > Can you update the TIP with the recent discussion? This discussion is > quite pertinent, I believe (even if it was mostly negative about the > TIP's precise proposal, preferring alternative solutions to that > presented). As it stands the TIP does not accurately reflect the full > discussion at all, IMHO. I believe that the discussion to which you refer is in reference [4] at the bottom of the "Summary of Discussion" section, together with the messages that follow it. I invite all to reread the message threads that the references cite if they can't recall the discussions. I believe that I've linked to the significant ones. I recognize that the TIP is controversial, but don't see much hope of building a strong consensus around any alternative yet proposed. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Vince D. <vi...@sa...> - 2004-04-07 17:40:21
|
On Wed, 7 Apr 2004, Kevin Kenny wrote: > I believe that the discussion to which you refer is in reference [4] at > the bottom of the "Summary of Discussion" section, together > with the messages that follow it. I invite all to reread > the message threads that the references cite if they can't > recall the discussions. I believe that I've linked to the > significant ones. No, the discussion in your references [3] and [4] from 2003 is well summarised. It is the recent discussion (i.e. March 2004) which followed here: http://aspn.activestate.com/ASPN/Mail/Message/Tcl-core/2032516 that has not been summarised or referenced at all. For example, there is Benny's suggestion to your 'all' counterexample that the counterexample really contains a bug, since any key-binding ought to have ";break" to prevent exactly that problem. Do we guarantee backwards compatibility even with buggy code? Second there is the suggestion that if you really don't want the 'all' binding to fire if another binding has triggered, you could actually check for that manually (scan the bindtags list, etc). This would reduce the backwards incompatibility of an overall cleaner solution to effectively nothing. Third, the TIP contains no mention of what the result of this TIP is on the x-platform Tk developer. That they must now have this: bind ... <Return> "pressReturn" bind ... <KP_Enter> "pressEnter" ; # only useful on Unix bind ... <Extended-Return> "pressEnter" ; # only useful on Windows i.e. rather than making their life easier, it has been made more complex! (In fact the TIP as a whole seems to have a bias against anyone even considering writing the same application on multiple platforms, which seems v. odd for Tk) These are the sorts of issues that I think ought to have been summarised in the TIP section entitled "Summary of Discussion". sorry to be a pain! Vince. |
From: Benjamin R. <Ben...@ep...> - 2004-04-08 11:15:51
|
Hi Vince, Kevin, Vince Darley <vi...@sa...> writes: > i.e. rather than making their life easier, it has been made more > complex! Well, to be fair, the functionality is not there on Windows or Mac right now at all. So any decision is better than nothing IMO, because than we can finally go forward and implement something. > sorry to be a pain! Ditto. I appreciate the effort and patience that everybody has invested here. benny |
From: Vince D. <vi...@sa...> - 2004-04-08 11:43:51
|
On Thu, 8 Apr 2004, Benjamin Riefenstahl wrote: > Well, to be fair, the functionality is not there on Windows or Mac > right now at all. So any decision is better than nothing IMO, because > than we can finally go forward and implement something. Sure, and of course I'll end up using whatever comes out of this process, in the end. But, I just hate to see Tk complicated by special cases: "On Unix you must do... On Windows that doesn't do anything, however, so use ...., but only if you're using WinTk 8.5, since on Tk 8.4 (or Unix/Mac Tk-anything) it will throw an error...." All this to preserve a hypothetical backwards incompatibility for an unknown number of scripts that are arguably buggy! In some sense this complexity would be ok if there was some clearcut future plan which would later simplify things, but I haven't heard one of those articulated -- and the only such future plans I can think of would be a significant incompatibility. Vince. |
From: <ke...@cr...> - 2004-04-07 17:57:32
|
Can Donal or Don please add Vince's mail verbatim to the TIP's discussion summary? -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2004-08-10 13:29:26
|
Someone said (without attribution, quoted in a post by Vince Darley): > Can you describe this idea further? What is the string representation > of the object? Does it include all the tags, marks, etc? Given > 'everything is a string' it would have to include all info about the > BTree, which means you couldn't expect to operate on it with 'string', > 'append', in any very useful way. (The format would have to be more > like the result of '.text dump' I suppose). The text widget appears to be used for at least two distinct purposes. The first, its original purpose, is to display "rich text", "hypertext", "forms", whatever you want to call the content. For this, it is like the canvas in that it is a "Swiss Army Widget" - it's primarily a layout and character-rendering engine, and a generic container for other widgets. (In this form, it's also used as a "better label", as a "poor man's spreadsheet", and other things that seem limited only by the programmers' imaginations.) But the text widget is also Tk's only component for simple entry of text that spans multiple lines - its analogue to a browser's <textarea> or a text editor component. In that use, a text widget contains only plain text, and in that context, a peer widget (or a -textvariable option) makes eminent sense. In fact, I long ago did code (at http://wiki.tcl.tk/1917) that manages a text widget - assumed to have plain text content - and keeps it in sync with a Tcl variable. I would wonder - as a partly-baked idea - whether the widget that we now call 'text' would profitably admit of two variants - the current widget (not easily peer-able or clonable) and a restricted version that has a -textvariable option and allows cloning and peering. Seems that both are useful, in different ways. Certainly a plain-text textarea would allow the rudiments of multi-window editing. A further wrinkle might be to allow sharing of marks, tags and tag attributes, images and the undo stack, but to forbid embedded windows. That would allow significantly more multi-window editing, similar to what's available in Emacs or many IDE's. It would still avoid the nasty issues of cloning embedded widgets. I realise that this discussion doesn't entirely address where Brian is going with 169; I'm more just musing. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Jeff H. <jeffh@ActiveState.com> - 2004-08-10 16:47:49
|
Kevin Kenny wrote: > I would wonder - as a partly-baked idea - whether the widget > that we now call 'text' would profitably admit of two > variants - the current widget (not easily peer-able or > clonable) and a restricted version that has a -textvariable > option and allows cloning and peering. Seems that both are > useful, in different ways. > > Certainly a plain-text textarea would allow the rudiments of > multi-window editing. A further wrinkle might be to allow > sharing of marks, tags and tag attributes, images and the > undo stack, but to forbid embedded windows. That would allow > significantly more multi-window editing, similar to what's > available in Emacs or many IDE's. It would still avoid the > nasty issues of cloning embedded widgets. You seem to be implying that it would be just text - that is not sufficient IMO. The most common peering application is for editors, and text colorization / font-manipulation is a very common application there. You wouldn't want to have to do the same font/color mangling on each peer. I think the idea has some merit, but just raw text won't help very much. Then you add colors and multiple fonts ... then maybe someone wants images again ... where does the fine line get cut? Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos |
From: Vince D. <vi...@sa...> - 2004-08-11 18:12:41
|
On Tue, 10 Aug 2004, Kevin Kenny wrote: > Certainly a plain-text textarea would allow the rudiments of multi-window > editing. A further wrinkle might be to allow sharing of marks, tags and tag > attributes, images and the undo stack, but to forbid embedded windows. > That would allow significantly more multi-window editing, similar > to what's available in Emacs or many IDE's. It would still avoid the > nasty issues of cloning embedded widgets. Given we'd want everything except embedded windows, it seems unnecessary to split out the code into two pieces. Perhaps we should just define a behaviour for peer interactions with embedded windows (for example, each peer will display the area as blank), and document things carefully enough so that users expect the issue. At least that's the approach taken here: http://sourceforge.net/tracker/index.php?func=detail&aid=994629&group_id=12997&atid=312997 which is now a complete implementation, ready for Tk 8.5. An alternative would just have '.text peer create' throw an error if '.text' contains any embedded windows. But that seems a bit harsh. Vince. |
From: <ke...@cr...> - 2005-08-17 17:27:58
|
vi...@sa... said: > One possible problem with both '-tabs' and '-tabstyle' is the > ambiguity of the prefixes. Is that a problem for (a) option table > handling, and (b) backwards compatbility? If we had introduced an option that was *shorter* than an existing option, there would be a problem. Otherwise, no, there's no issue. '-tabs' is unambiguously itself; '-tabst' or anything longer is the new option. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Jeff H. <jeffh@ActiveState.com> - 2005-08-17 18:45:10
|
Kevin Kenny wrote: > vi...@sa... said: > > One possible problem with both '-tabs' and '-tabstyle' is the > > ambiguity of the prefixes. Is that a problem for (a) option table > > handling, and (b) backwards compatbility? > > If we had introduced an option that was *shorter* than an > existing option, there would be a problem. Otherwise, no, > there's no issue. '-tabs' is unambiguously itself; '-tabst' > or anything longer is the new option. Not exactly ... '-tab' before sufficed, now it will throw an error of 'ambiguous option ...'. Jeff |
From: <dg...@ni...> - 2005-08-18 19:23:33
|
Jeff Hobbs <jeffh@ActiveState.com>: > Not exactly ... '-tab' before sufficed, now it will throw an > error of 'ambiguous option ...'. State in the TIP we explicitly refuse to support such broken scripts. :P DGP |
From: Jeff H. <jeffh@ActiveState.com> - 2005-08-18 19:43:31
|
> Jeff Hobbs <jeffh@ActiveState.com>: > > Not exactly ... '-tab' before sufficed, now it will throw an error of > > 'ambiguous option ...'. > > State in the TIP we explicitly refuse to support > such broken scripts. :P I actually favor this, at least versus the synonyms. We had the same issue with grid when it was Tcl_Obj-ified, and what it exposed really was more a bug. Jeff |