Home > Archive > Tcl > August 2007 > What's the most important thing lacking in your Tcl toolbox?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What's the most important thing lacking in your Tcl toolbox?
|
|
| Larry W. Virden 2007-08-13, 10:20 pm |
| Over the years, I've seen many people post about how tcl should have
this or that to compete with this language or that framework.
That's not what this posting is about.
What this thread is about - hopefully - is identifying areas in which
you, as a tcl developer, have a need, but have been unsuccessful in
locating a solution.
Maybe it is a tool, or maybe it is an extension. Maybe it is an
example or a tutorial.
I hope that people feel free to post a quick note mentioning specific
needs that you have, and that other readers feel free to chime in with
suggestions for meeting those needs.
For instance, if someone were to post that they have a need for
calculating some specific checksum for some particular kind of data,
and someone else knows of a place where that kind of code might be
found, feel free to post the location. Or, if you don't know of a
place, but perhaps have created a page over at http://wiki.tcl.tk/
that discusses the issue, feel free to mention that.
What I hope to see in this thread are those undiscovered gems that I
am certain reside out there around the net, or strategies for solving
the problems, along with, hopefully, some updates on the wiki to help
future developers.
Thanks!
| |
| Bryan Oakley 2007-08-13, 10:20 pm |
| Larry W. Virden wrote:
> I hope that people feel free to post a quick note mentioning specific
> needs that you have, and that other readers feel free to chime in with
> suggestions for meeting those needs.
For me, the biggest missing piece is the ability to take the contents of
a text widget and print it out while retaining most of the formatting.
Every commercial product I've worked on that was implemented in Tk has
struggled with the lack of a decent printing solution.
--
Bryan Oakley
http://www.tclscripting.com
| |
| Synic 2007-08-13, 10:20 pm |
| Larry W. Virden <lvirden@gmail.com> wrote:
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
Most of the things on my wishlist are GUI interface matters:
* Some more of the Tk widgets going into Tile would be good. Having a
platform native spinbox and text widget would be useful, for example.
No doubt these things will be added in due course :-).
* A way to have a completely flat button widget in either Tk or Tile
on Mac OS X in button bars. Specifying -relief, etc, in Tk doesn't work
at present.
* Freshening some of the other Tile widgets on Mac. In particular,
notebook tabs are looking increasingly unusual.
* Handling of .icns files in the Img package could be handy.
* A standard API for handling printing. The back-end would be different
per platform in terms of setup, but, it would be useful to have a Tcl
script be able to call something like:
set lpt [::printer::use default]
lpt print $data
.... and have the data sent down the wire to whatever's on the other end
in whatever way their OS handles it normally.
No need for info from per-platform printer dialogs, lets just have an API
which lets us manipulate them:
set allprinters [::printer::get all]
set lptinfo [::printer::get default info]
set allprintersinfo [::printer::get all info]
::printer::set default [lindex [::printer::get all] 0]
| |
| Bryan Oakley 2007-08-13, 10:20 pm |
| Synic wrote:
> Larry W. Virden <lvirden@gmail.com> wrote:
>
> Most of the things on my wishlist are GUI interface matters:
>
> * Some more of the Tk widgets going into Tile would be good. Having a
> platform native spinbox and text widget would be useful, for example.
> No doubt these things will be added in due course :-).
What's a "platform native text widget"? It's just a big white (or
whatever) square. Are you thinking about a bunch of built-in controls
for bold, italics, etc?
--
Bryan Oakley
http://www.tclscripting.com
| |
| Synic 2007-08-13, 10:20 pm |
| Bryan Oakley <oakley@bardo.clearlight.com> wrote:
> Synic wrote:
>
> What's a "platform native text widget"? It's just a big white (or
> whatever) square. Are you thinking about a bunch of built-in controls
> for bold, italics, etc?
Nah. I mean, as in handling of the widget border, as far as 3D effect
and highlight colour go.
Even after matching highlight colours, etc, there's a noticeable
difference between the way borders are handled between the Tk text
widget and the single line ttk::entry widget. It's something especially
visible on Mac and present on Windows. Not too noticeable on X11, IIRC.
| |
|
| Larry W. Virden wrote:
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
>
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
I have done great things with Tcl in the past so it is one of the most
complete tools that I have used. Having said that, I think the following
could be added and/or improved:
1) Increase the efficiency and flexibility of smtp and smtpd. Pehaps
this is
more of a tutorial type of thing.
2) Handling for other messaging protocols like instant messaging. Perhaps
this exists already and I am simply unaware of it.
3) Tutorials or introductory use cases for many packages (soap, tile,
etc.).
Is that 3 points or just one?
| |
| pedietz@west.com 2007-08-13, 10:20 pm |
| TCL has built in event handlers, easy writing to sockets, easy http...
but...
1) writing TCL web serverices via SOAP is not at all easy.
G.Lester's 'Web Services For Tcl' is a start, but it only works for
tclhttpd.
The world is XML and SOAP 5 years ago and tcl is still lacking.
2) tdom8.1 is the best xml parser (but it's been sitting in CVS for 2+
years) and has no release date...
3) tcl 8.5 needs to be released.
| |
| Alan Anderson 2007-08-13, 10:20 pm |
| "Larry W. Virden" <lvirden@gmail.com> wrote:
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
Printing. For example, to produce a formatted report, I currently
resort to using HTML and a separate program. Printing graphics is still
problematic.
| |
| Michael Schlenker 2007-08-13, 10:20 pm |
|
> 2) Handling for other messaging protocols like instant messaging. Perhaps
> this exists already and I am simply unaware of it.
Some of them exist (there is a tcl based messenger for MSN (amsn), a tcl
nased messenger for aols IM procotol (oscar8) and the jabber clients
tkabber and coccinella at least.
Michael
| |
| Darren New 2007-08-13, 10:20 pm |
| Bryan Oakley wrote:
> What's a "platform native text widget"? It's just a big white (or
> whatever) square.
Errr, not hardly. :-) On Windows, it has all kinds of features that
systems that reimplement text boxes on their own are missing (Tcl and
Firefox/Thunderbird being the ones that annoy me most).
--
Darren New / San Diego, CA, USA (PST)
The primary use of XML is as a technique
to avoid documenting your interchange formats.
| |
| slebetman@yahoo.com 2007-08-13, 10:20 pm |
| On Aug 13, 11:43 pm, "Larry W. Virden" <lvir...@gmail.com> wrote:
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
>
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
>
> I hope that people feel free to post a quick note mentioning specific
> needs that you have, and that other readers feel free to chime in with
> suggestions for meeting those needs.
>
> For instance, if someone were to post that they have a need for
> calculating some specific checksum for some particular kind of data,
> and someone else knows of a place where that kind of code might be
> found, feel free to post the location. Or, if you don't know of a
> place, but perhaps have created a page over athttp://wiki.tcl.tk/
> that discusses the issue, feel free to mention that.
>
> What I hope to see in this thread are those undiscovered gems that I
> am certain reside out there around the net, or strategies for solving
> the problems, along with, hopefully, some updates on the wiki to help
> future developers.
>
This will sound like a broken record: Printing! At this stage I don't
care anymore about Classic Mac printing. Just support Windows GDI and
CUPS. Currently I use the GDI and Printer extension on Windows and
Canvas Postscript output and Ghostscript for other platforms but it's
clumsy to have to write printing related code twice. In addition the
Canvas + Ghostscript solution is clumsy in it's own right. Guiding
users to install Ghostscript can be tedious.
| |
| spam@controlq.com 2007-08-13, 10:20 pm |
|
Is TkTable going to be part of 8.5 core?
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
| |
|
| Darren New <dnew@san.rr.com> wrote:
> Bryan Oakley wrote:
>
> Errr, not hardly. :-) On Windows, it has all kinds of features that
> systems that reimplement text boxes on their own are missing (Tcl and
> Firefox/Thunderbird being the ones that annoy me most).
For me, it's not so much about features as presentation. Used amongst
the other Tile widgets, the text widget's border can look a little out
of place.
This sort of thing doesn't matter so much for users of X11 and Windows,
but, many Mac users are extremely anal about look and feel and can
dismiss an application out of hand on those grounds alone.
| |
| Arjen Markus 2007-08-14, 4:42 am |
| On 13 aug, 17:43, "Larry W. Virden" <lvir...@gmail.com> wrote:
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
....
> What I hope to see in this thread are those undiscovered gems that I
> am certain reside out there around the net, or strategies for solving
> the problems, along with, hopefully, some updates on the wiki to help
> future developers.
>
> Thanks!
Something I miss (but I am working on that ;)) is an easy
way to wrap Fortran libraries (*). Critcl is a fine solution for
C and I know of SWIG. But what matters to me is a way to access
those thousands of Fortran (or FORTRAN (**)) libraries out there,
for instance the Netlib collection.
Another thing, more or less related, is this:
Suppose I have a library (either Fortran or C or ...) that I
access from Tcl and I would like to use Tcl to manage the
memory that is involved. That seems like a good idea to me,
but I do not know what is involved: how to make sure
it all goes well with reference counts, the moment in time, etc.
I guess, I would like a tutorial on that issue.
Regards,
Arjen
(*) Only a slightly broken record ;)
(**) Allow me this small bit of pendantry
| |
| davidnwelton@gmail.com 2007-08-14, 4:42 am |
|
> 1) writing TCL web serverices via SOAP is not at all easy.
>
> G.Lester's 'Web Services For Tcl' is a start, but it only works for
> tclhttpd.
>
> The world is XML and SOAP 5 years ago and tcl is still lacking.
Sometimes if you ignore things long enough, they'll go away. It seems
that 'REST' is what people are talking about these days, and all that
is is HTTP.
| |
| Mark Janssen 2007-08-14, 4:42 am |
| On 14 aug, 03:57, "slebet...@yahoo.com" <slebet...@gmail.com> wrote:
> On Aug 13, 11:43 pm, "Larry W. Virden" <lvir...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
> This will sound like a broken record: Printing! At this stage I don't
> care anymore about Classic Mac printing. Just support Windows GDI and
> CUPS. Currently I use the GDI and Printer extension on Windows and
> Canvas Postscript output and Ghostscript for other platforms but it's
> clumsy to have to write printing related code twice. In addition the
> Canvas + Ghostscript solution is clumsy in it's own right. Guiding
> users to install Ghostscript can be tedious.
Not to look for excuses, but do you know any (scripting) language that
supports printing for multiple platforms as a library or out of the
box?
Mark
| |
| Mark Janssen 2007-08-14, 4:42 am |
| On 13 aug, 17:43, "Larry W. Virden" <lvir...@gmail.com> wrote:
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
>
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
>
> I hope that people feel free to post a quick note mentioning specific
> needs that you have, and that other readers feel free to chime in with
> suggestions for meeting those needs.
>
> For instance, if someone were to post that they have a need for
> calculating some specific checksum for some particular kind of data,
> and someone else knows of a place where that kind of code might be
> found, feel free to post the location. Or, if you don't know of a
> place, but perhaps have created a page over athttp://wiki.tcl.tk/
> that discusses the issue, feel free to mention that.
>
> What I hope to see in this thread are those undiscovered gems that I
> am certain reside out there around the net, or strategies for solving
> the problems, along with, hopefully, some updates on the wiki to help
> future developers.
>
> Thanks!
And to add my own 2c. What I have missed recently is http 1.1 (or at
least http supporting keepalives) this is required for some
authenticating proxies for instance. There are some changed versions
of the http package which include this, but it would be nice if the
core http supports it.
Mark
| |
| Torsten Reincke 2007-08-14, 4:42 am |
|
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
Printing! Printing in the core (or as an extension, but it must be
useable on all platforms)! Printing for the people!
And a BLT that works on all platforms and Tcl versions (Aqua, 8.5, and
such).
Torsten
| |
| Matthias Kraft 2007-08-14, 8:13 am |
| pedietz@west.com schrieb:
> The world is XML and SOAP 5 years ago and tcl is still lacking.
Stable languages do not need to rush after every hype. Once the hype
has settled take a look what is left and build something stable for
it.
XML is almost everywhere and we have tdom, which is flexible and
stable as far I am concerned. I cannot tell anything about SOAP
though.
> 2) tdom8.1 is the best xml parser (but it's been sitting in CVS for 2+
> years) and has no release date...
.... you missed recent development here: we are approaching a 0.8.2
release: go for http://www.tdom.org/files/, download and test the
latest RC...
> 3) tcl 8.5 needs to be released.
Yes :-)
kind regards
--
Matthias Kraft
Software AG, Germany
| |
| Bryan Oakley 2007-08-14, 8:13 am |
| Synic wrote:
> Darren New <dnew@san.rr.com> wrote:
>
>
>
> For me, it's not so much about features as presentation. Used amongst
> the other Tile widgets, the text widget's border can look a little out
> of place.
Out of curiosity, did you try packing the text widget inside a
ttk::entry or ttk::frame widget to get the desired look?
| |
| Bryan Oakley 2007-08-14, 8:13 am |
| Torsten Reincke wrote:
>
>
> Printing! Printing in the core (or as an extension, but it must be
> useable on all platforms)! Printing for the people!
Frankly, I'd be satisfied if we only had printing on one or two
platforms. And if we had two or three different interfaces, that would
be fine too.
I suspect part of the holdup is that someone may know a way to make it
work on one platform but not on others so nothing is done.
Yeah, it would be nice if we had a uniform, perfectly functioning print
command that worked cross-platform, but I'd rather have something less
uniform than nothing at all.
| |
| Larry W. Virden 2007-08-14, 8:13 am |
| On Aug 13, 7:28 pm, Alan Anderson <arand...@insightbb.com> wrote:
> "Larry W. Virden" <lvir...@gmail.com> wrote:
>
>
> Printing. For example, to produce a formatted report, I currently
> resort to using HTML and a separate program. Printing graphics is still
> problematic.
I encourage everyone for whom printing is an issue to contribute
thoughts, problem areas, suggestions, etc. over at http://wiki.tcl.tk/printing
| |
| Neil Madden 2007-08-14, 8:13 am |
| Synic wrote:
> Darren New <dnew@san.rr.com> wrote:
>
> For me, it's not so much about features as presentation. Used amongst
> the other Tile widgets, the text widget's border can look a little out
> of place.
Have you tried -highlightthickness 0? That seems to do the job for me on
OS X.
-- Neil
| |
| suchenwi 2007-08-14, 8:13 am |
| I'm missing:
- ability to rotate text on canvas
- ability to rotate photo images (at least in 90-degree steps)
The second can be done in pure Tcl, but a solution on Tk's C side is
probably much faster.
| |
| minuit00@hotmail.fr 2007-08-14, 8:13 am |
| As you can find SSH client library for python and Ruby,
a multi-platform SSH client library/package for tcl would be nice.
| |
| Donal K. Fellows 2007-08-14, 8:13 am |
| On Aug 14, 4:02 am, s...@controlq.com wrote:
> Is TkTable going to be part of 8.5 core?
No. But any binary distribution of Tk without making Tktable available
too is a bit incomplete in my view. :-)
Donal.
| |
| Donal K. Fellows 2007-08-14, 8:13 am |
| Synic wrote:
> * A way to have a completely flat button widget in either Tk or Tile
> on Mac OS X in button bars. Specifying -relief, etc, in Tk doesn't work
> at present.
With Tile/Ttk it should be possible to do this by setting the right
style (i.e. if you tell a button to be a toolbar button, it should
look right for the style of toolbar buttons for the current theme). If
it doesn't work currently, raise a bug report. :-)
> * A standard API for handling printing. The back-end would be different
> per platform in terms of setup, but, it would be useful to have a Tcl
> script be able to call something like:
>
> set lpt [::printer::use default]
> lpt print $data
>
> ... and have the data sent down the wire to whatever's on the other end
> in whatever way their OS handles it normally.
The problems with printing are actually quite nasty. The problem is
that there are two totally different approaches to doing printing, and
Tk only supports one of them (and only partially at that!) While on
standard Unix systems printing is done by sending postscript into the
'lpr' program, on Windows printing is done by drawing using a special
context. And to cap it all, only the [canvas] supports postscript
generation anyway. Fixing it all requires *real* work.
> No need for info from per-platform printer dialogs, lets just have an API
> which lets us manipulate them:
>
> set allprinters [::printer::get all]
> set lptinfo [::printer::get default info]
> set allprintersinfo [::printer::get all info]
> ::printer::set default [lindex [::printer::get all] 0]
Oh, and the other problem is that different platforms have different
interaction styles (blocking vs. non-blocking) for their standard
dialogs. Messy!
Donal.
| |
| Donal K. Fellows 2007-08-14, 7:10 pm |
| David Welton wrote:
> Sometimes if you ignore things long enough, they'll go away. It seems
> that 'REST' is what people are talking about these days, and all that
> is is HTTP.
Sounds like we're about ready for the backlash against REST. :-) To be
a little bit serious, the problem with REST is that it's hard to
automatically understand the artefacts it deals with. In particular,
knowing how to synthesize URLs for document fragments is non-trivial;
there needs to be some way of marking such things up, but when that
happens you jettison the light-weight-ness of REST. To date, these
sorts of things have tended to be ignored by virtue of making
interfaces to the real REST part out of custom javascript, giving
mashups but no easy route to deeper integration.
And rumours of SOAP's death do seem exaggerated.
Donal.
| |
| Donal K. Fellows 2007-08-14, 7:10 pm |
| pedi...@west.com wrote:
> 3) tcl 8.5 needs to be released.
Yes.
Donal.
| |
| Donal K. Fellows 2007-08-14, 7:10 pm |
| Richard Suchenwirth wrote:
> - ability to rotate photo images (at least in 90-degree steps)
I've got bits and pieces of this, but haven't had the time to
reformulate it into a decent piece of code. It's not *very* hard, but
it does take time and I've been short of that for the past few
years...
Donal.
| |
| Arjen Markus 2007-08-14, 7:10 pm |
| On 14 aug, 15:10, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
wrote:
>
> Oh, and the other problem is that different platforms have different
> interaction styles (blocking vs. non-blocking) for their standard
> dialogs. Messy!
>
> Donal.
Not to mention the fact that the standard dialogue that
pops up on Windows when you print something depends on the
printer too. Try printing to a file for instance (as is often
needed when printing a picture so that you can import it
in a document):
Sometimes you can specify a file name (typing it), sometimes
a file selection dialogue pops up, sometimes you have no
control whatsoever and you have to guess where the thing
ends up!
(Okay, an inaccurate description, but that is at least
my experience: lots of variations and it is very hard to
control)
Regards,
Arjen
| |
| Peter Dalgaard 2007-08-14, 7:10 pm |
| suchenwi <richard.suchenwirth-bauersachs@siemens.com> writes:
> I'm missing:
> - ability to rotate text on canvas
Me too. And proper clipping, at least to rectangular regions. (No,
putting a sheet on top with a hole in it is not quite good enough!
There can be multiple viewports.)
--
O__ ---- Peter Dalgaard ุster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
| |
| Neil Madden 2007-08-14, 7:10 pm |
| Larry W. Virden wrote:
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
There are relatively few areas for me these days. Some things I could
have done with recently:
1. A really good, fast, generic database API along the lines of the
interface provided by SQLite. (I started using SQLite but have now
switched to MySQL).
2. A good way of specifying, reading and writing binary file formats. I
currently hand-coded a Tcl parser for a complex 3rd-party binary file
format but it's a major bottleneck in my code (to be fair, mainly
because I'm not very clever about avoiding [s ]ing all over a 300MB
file). Having a generic C-coded file parser would be a major win (even
better if it can mmap() the file). Such a parser would typically be
based on offsets and byte (octet) counts rather than syntactic delimiters.
3. Packages for RDF and OWL - mainly thinking in terms of the data model
here rather than parsing (which is just XML). This should cover parsing
(mostly just XML parsing), generation (xmlgen/tdom), and querying: both
TBox and ABox queries (e.g., via a DIG interface).
4. Tk widget-wise a lot of what I want now exists: good OpenGL widgets,
TkHTML, TkTable, Tile, etc. I sometimes wish for a slightly higher-level
toolkit layer which takes care of a lot of stuff like setting up default
menu entries (About, Help, Quit, Save, Open etc) and setting up most of
the scaffolding for things like drag-n-drop, printing, etc.
-- Neil
| |
| Darren New 2007-08-14, 7:10 pm |
| Synic wrote:
> For me, it's not so much about features as presentation.
Until the features are things like "everywhere I need to type text, it
works, except in the textentry boxes of *your* applications." Then the
features become a lot more important.
--
Darren New / San Diego, CA, USA (PST)
The primary use of XML is as a technique
to avoid documenting your interchange formats.
| |
| slebetman@yahoo.com 2007-08-14, 7:10 pm |
| On Aug 14, 7:19 pm, Bryan Oakley <oak...@bardo.clearlight.com> wrote:
> Torsten Reincke wrote:
>
>
> Frankly, I'd be satisfied if we only had printing on one or two
> platforms. And if we had two or three different interfaces, that would
> be fine too.
>
Actually, since the Mac, Linux and the majority of Unices out there
are using CUPS we really only need to support 2 platforms: Windows GDI
and CUPS. But I'd still prefer a unified interface for both. It's fine
to include platform specific commands for when you really need it but
for the most part I shouldn't have to worry about it when writing
quick hacks. Kind of like the file related commands and Tk.
| |
| Bryan Oakley 2007-08-14, 7:10 pm |
| slebetman@yahoo.com wrote:
> On Aug 14, 7:19 pm, Bryan Oakley <oak...@bardo.clearlight.com> wrote:
>
> Actually, since the Mac, Linux and the majority of Unices out there
> are using CUPS we really only need to support 2 platforms: Windows GDI
> and CUPS. But I'd still prefer a unified interface for both. It's fine
> to include platform specific commands for when you really need it but
> for the most part I shouldn't have to worry about it when writing
> quick hacks. Kind of like the file related commands and Tk.
>
Oh, I agree that in an ideal world it would have a unified interface.
It's just that there are at least three problems to solve: solving the
printing problem on windows, solving the printing on CUPS-based systems,
and abstracting the interface so it works on both. If we omit that last
part, we've cut the problem down by 1/3 (give or take an order of
magnitude...). And if we can only solve it for one platform, printing
just on windows, or just on CUPS-based systems would still be a win.
My current hope is that tkhtml3 becomes production-ready some day and we
can leverage its ability to accurately render html and css. If we could
solve the problem of dumping the raw, rendered bits from a tkhtml widget
to a printer it would become a somewhat straight-forward exercise to
convert a text widget dump to html+css, feed it to a hidden tkhtml
widget, and then send that to a printer.
--
Bryan Oakley
http://www.tclscripting.com
| |
|
| Neil Madden <nem@cs.nott.ac.uk> wrote:
> Synic wrote:
>
> Have you tried -highlightthickness 0? That seems to do the job for me on
> OS X.
My current "just adequate if the users don't look closely" solution is
keeping -highlightthickness 1 and changing the border colour to a similar
lightblue to platform native.
Unfortunately, Tk's border is unantialiased with square corners, platform
native is antialiased with rounded corners.
| |
|
| Bryan Oakley <oakley@bardo.clearlight.com> wrote:
>
> Out of curiosity, did you try packing the text widget inside a
> ttk::entry or ttk::frame widget to get the desired look?
I didn't try ttk::entry one as I wouldn't imagine the ttk::entry could
be make itself appear active and trigger its blue border highlight if
it's the other Tk text widget that really *is* active.
I wouldn't think the ttk::frame widget would produce that platform native
antialiased rounded corner blue border when the text widget is
highlighted either. Same for ttk::labelframe.
| |
|
| Darren New <dnew@san.rr.com> wrote:
> Synic wrote:
>
> Until the features are things like "everywhere I need to type text, it
> works, except in the textentry boxes of *your* applications." Then the
> features become a lot more important.
Oh, the features are important, but, I haven't found the text widget
lacking anything in particular that stands out for me.
My only beef with the text widget wanting to see it Tile-ified rather
than being left behind as we all move on from crusty old Tk widgets to
our shiny new themed ones...
| |
| Bryan Oakley 2007-08-14, 7:10 pm |
| Synic wrote:
> Bryan Oakley <oakley@bardo.clearlight.com> wrote:
>
> I didn't try ttk::entry one as I wouldn't imagine the ttk::entry could
> be make itself appear active and trigger its blue border highlight if
> it's the other Tk text widget that really *is* active.
>
> I wouldn't think the ttk::frame widget would produce that platform native
> antialiased rounded corner blue border when the text widget is
> highlighted either. Same for ttk::labelframe.
>
Instead of imagining it, spend a couple of minutes and try it. I don't
have an aqua machine handy or I'd give it a try. On windows the outline
looks right when I pack the text into a ttk::entry (with -padx 1 -pady
1), but ttk::entry widgets for me don't change appearance when they gain
focus so I can't tell what happens when focus goes to the embedded widget.
I bet you can make it work by manually controlling the -state option of
the ttk::entry widget when focus goes into the embedded text.
<shrug>
--
Bryan Oakley
http://www.tclscripting.com
| |
| lahl0600@student.miun.se 2007-08-14, 7:10 pm |
| On 14 Aug, 14:52, minui...@hotmail.fr wrote:
> As you can find SSH client library for python and Ruby,
> a multi-platform SSH client library/package for tcl would be nice.
I've played around a bit with this idea during the summer, although
I eventually concluded that driving command-line SSH would suffice
for my project. I did research the feasibility of it, however; it
turned out pretty much everything which I felt would be *hard* to do
in Tcl (DES, SHA, bignums) is already available in tcllib!
| |
| Neil Madden 2007-08-14, 7:10 pm |
| Synic wrote:
> Neil Madden <nem@cs.nott.ac.uk> wrote:
>
> My current "just adequate if the users don't look closely" solution is
> keeping -highlightthickness 1 and changing the border colour to a similar
> lightblue to platform native.
>
> Unfortunately, Tk's border is unantialiased with square corners, platform
> native is antialiased with rounded corners.
Hmmm... are we talking about the [text] widget here or an [entry]? I
thought we were talking about the text widget, in which case all the
text widgets I can think of on OS X (i.e., areas displaying large
amounts of text for viewing/editing) don't seem to have any border at
all. Could you describe the situation in a bit more detail as I've lost
the context now.
-- Neil
| |
| Darren New 2007-08-14, 7:10 pm |
| Synic wrote:
> Oh, the features are important, but, I haven't found the text widget
> lacking anything in particular that stands out for me.
Handwriting recognition? Speech recognition? Automatically popping up
the on-screen keyboard when it gets the focus? Various other features
for accessibility, tablet PCs, and so on?
Very *very* annoying when using Tcl on a tablet PC. Not unlike when you
run across an app when all the usual keyboard shortcuts (ctl-A,
cut/copy/paste, etc) don't work as expected.
--
Darren New / San Diego, CA, USA (PST)
The primary use of XML is as a technique
to avoid documenting your interchange formats.
| |
| Synic 2007-08-14, 10:10 pm |
| Bryan Oakley <oakley@bardo.clearlight.com> wrote:
> Synic wrote:
>
> Instead of imagining it, spend a couple of minutes and try it. I don't
> have an aqua machine handy or I'd give it a try. On windows the outline
> looks right when I pack the text into a ttk::entry (with -padx 1 -pady
> 1), but ttk::entry widgets for me don't change appearance when they gain
> focus so I can't tell what happens when focus goes to the embedded widget.
Didn't work for me... Code used:
package require tile
grid [ttk::frame .f] -row 1 -column 1 -sticky nsew
grid [ttk::entry .f.ent1] -row 1 -column 1 -sticky nsew -padx 5 -pady 5
grid [text .f.ent2 -highlightthickness 0] -row 1 -column 1 -sticky nsew -padx 5 -pady 5
grid rowconfigure . {1} -weight 1
grid columnconfigure . {1} -weight 1
grid rowconfigure .f {1} -weight 1
grid columnconfigure .f {1} -weight 1
> I bet you can make it work by manually controlling the -state option of
> the ttk::entry widget when focus goes into the embedded text.
There's probably a binding on the ttk::entry widget's Focus which handles
that, and I guess hunting through the Tile source is the way to find what
that processes are bound to it. But that's an "another day" job.
Cheers for the suggestions.
| |
| Bryan Oakley 2007-08-14, 10:10 pm |
| Synic wrote:
> Bryan Oakley <oakley@bardo.clearlight.com> wrote:
>
>
>
> Didn't work for me... Code used:
>
> package require tile
> grid [ttk::frame .f] -row 1 -column 1 -sticky nsew
> grid [ttk::entry .f.ent1] -row 1 -column 1 -sticky nsew -padx 5 -pady 5
> grid [text .f.ent2 -highlightthickness 0] -row 1 -column 1 -sticky nsew -padx 5 -pady 5
Well, that's not exactly what I had in mind. I suggested packing the
text widget inside an entry widget.
This actually looks pretty decent on my mac, is this the look you are after?
package require tile
ttk::entry .e1
ttk::entry .textContainer
text .t -borderwidth 0 -highlightthickness 0 \
-width 40 -height 4
bind .t <FocusIn> {.textContainer state focus}
bind .t <FocusOut> {.textContainer state {!focus}}
pack .e1 -fill x -side top -padx 4 -pady 4
pack .textContainer -fill x -side top -padx 4 -pady 4
pack .t -in .textContainer -padx 5 -pady 5
| |
| slebetman@yahoo.com 2007-08-14, 10:10 pm |
| On Aug 15, 12:44 am, Bryan Oakley <oak...@bardo.clearlight.com> wrote:
> slebet...@yahoo.com wrote:
>
>
> Oh, I agree that in an ideal world it would have a unified interface.
> It's just that there are at least three problems to solve: solving the
> printing problem on windows, solving the printing on CUPS-based systems,
> and abstracting the interface so it works on both. If we omit that last
> part, we've cut the problem down by 1/3 (give or take an order of
> magnitude...). And if we can only solve it for one platform, printing
> just on windows, or just on CUPS-based systems would still be a win.
>
> My current hope is that tkhtml3 becomes production-ready some day and we
> can leverage its ability to accurately render html and css. If we could
> solve the problem of dumping the raw, rendered bits from a tkhtml widget
> to a printer it would become a somewhat straight-forward exercise to
> convert a text widget dump to html+css, feed it to a hidden tkhtml
> widget, and then send that to a printer.
>
Currently I can already reliably print on Windows in a native-ish way
via the Printer and GDI extensions. The GDI extension is especially
nice since it mimics the canvas. So I can easily preview my output on
canvas before sending it to the printer. I can also print on Unix in a
native-ish manner provided I have a postscript printer by simply
dumping the canvas (though, scaling the page is not as nice as the GDI
+Printer solution).
Hmm.. I've just looked at their homepage again
http://www.schwartzcomputer.com/tcl-tk/tcl-tk.html and it appears that
the license of Printer is BSD-ish, in fact more liberal than BSD. But
the license of the GDI extension is very incompatible for inclusion
with the core. In fact parts of the GDI extension has Microsoft
copyright (the author cut and pasted code from MSVC sample projects).
The big missing part right now is native CUPS printing without going
through ghostscript. All the other bits and pieces are already
available (albeit with licensing problems).
| |
|
| Bryan Oakley <oakley@bardo.clearlight.com> wrote:
> Well, that's not exactly what I had in mind. I suggested packing the
> text widget inside an entry widget.
>
> This actually looks pretty decent on my mac, is this the look you are after?
>
> package require tile
>
> ttk::entry .e1
> ttk::entry .textContainer
> text .t -borderwidth 0 -highlightthickness 0 \
> -width 40 -height 4
> bind .t <FocusIn> {.textContainer state focus}
> bind .t <FocusOut> {.textContainer state {!focus}}
> pack .e1 -fill x -side top -padx 4 -pady 4
> pack .textContainer -fill x -side top -padx 4 -pady 4
> pack .t -in .textContainer -padx 5 -pady 5
The effect on the widget border itself looks good. But the text widget is
now limited to single-line of a limited length. Anything past "The cat sat
on the " is lost when running the above on my Mac...
To me, it looks like in getting the external border effect, it's setting
the focus to be the .textContainer entry widget rather than the .t text
widget which needs to have real focus for editing.
That's why I was saying before... I'd probably have to dig through the Tile
sources to see what's actually triggering the blue backgrounds in ttk::entry
when focus is applied, because we can't really switch focus away from the
text widget because then we can't actually use it ;-).
| |
|
| Synic <flavp+hfrarg@nhgbaf.arg.nh> wrote:
> The effect on the widget border itself looks good. But the text widget is
> now limited to single-line of a limited length. Anything past "The cat sat
> on the " is lost when running the above on my Mac...
[...]
Oh, wait a second...
http://pc.autons.net/stuff/interesting-bryan-effect.png
Still doesn't work, but, in a more interesting way :-)
| |
| Bryan Oakley 2007-08-15, 8:10 am |
| Synic wrote:
> Bryan Oakley <oakley@bardo.clearlight.com> wrote:
>
>
>
> The effect on the widget border itself looks good. But the text widget is
> now limited to single-line of a limited length. Anything past "The cat sat
> on the " is lost when running the above on my Mac...
Interesting. When you type in the four-line window on the bottom you can
only enter one line of text? Strange. On my mac it works exactly as
expected. The first entry widget is just a normal entry widget to use
for comparison.
I notice I forgot to turn -takefocus off for the underlying entry
widget, so you need to press <tab> twice when focus is in the widget at
the top. You can just click in the text widget though.
>
> To me, it looks like in getting the external border effect, it's setting
> the focus to be the .textContainer entry widget rather than the .t text
> widget which needs to have real focus for editing.
Not exactly. It's not setting focus anywhere, it's just setting the
state of the underlying entry widget to the "focus" state, which causes
its focus ring to display. The focus state is different than the actual
notion of which widget has focus.
>
> That's why I was saying before... I'd probably have to dig through the Tile
> sources to see what's actually triggering the blue backgrounds in ttk::entry
> when focus is applied,
It's the setting of the state to "focus". Tile widgets handle state a
bit differently than normal Tk.
> because we can't really switch focus away from the
> text widget because then we can't actually use it ;-).
>
It's very strange that you can't use it, because it works fine for me.
Here's a screenshot:
http://www.purl.org/net/oakley/ttkentry.gif
Oh well, it was just an experiment.
| |
| Joe English 2007-08-15, 7:17 pm |
| Donal K. Fellows wrote:
>David Welton wrote:
>
>Sounds like we're about ready for the backlash against REST. :-) To be
>a little bit serious, the problem with REST is that it's hard to
>automatically understand the artefacts it deals with. [...]
SOAP vs. REST is comparing apples and orangutans -- REST is
an abstract architectural style, while SOAP is a specific
(very large) family of concrete (and very complex) protocols.
A better comparison would be SOAP vs. a concrete RESTful
protocol like GData.
>knowing how to synthesize URLs for document fragments is non-trivial;
>there needs to be some way of marking such things up, but when that
>happens you jettison the light-weight-ness of REST. To date, these
>sorts of things have tended to be ignored by virtue of making
>interfaces to the real REST part out of custom javascript, giving
>mashups but no easy route to deeper integration.
That's probably true for many REST-style protocols, especially
the simpler ones since they tend to be informally, vaguely,
and incompletely specified. But not universally -- AtomPub and
GData are two good examples at the other end of the spectrum.
And veering back on topic, support for REST-style web services
is an area that I find lacking in Tcl. The core http package is
insufficient for a lot of things you need to do on the client
side of a REST transaction, and on the server side tcllib's
ncgi.tcl is much more awkward to use than it needs to be.
That's something I think could be improved.
--Joe English
| |
| Joe English 2007-08-15, 7:17 pm |
| Mark Janssen wrote:
>
>Not to look for excuses, but do you know any (scripting) language that
>supports printing for multiple platforms as a library or out of the
>box?
That's an excellent question. Are there any languages,
toolkits, or frameworks out there with good printing support?
The main obstacle to good printer support in Tcl is that
nobody knows how to do it. If somebody, anybody, has figured
this out, then we can solve the bulk of the problem just by
stealing their design.
--Joe English
| |
| Stephan Kuhagen 2007-08-15, 7:17 pm |
| Joe English wrote:
> That's an excellent question. Are there any languages,
> toolkits, or frameworks out there with good printing support?
Yes: http://doc.trolltech.com/4.3/printing.html
They use native printer dialogs on all plattforms and have a really nice
device abstraction using a custom widget. You can draw and print text in a
page based manner and the print via the printer abstraction.
Regards
Stephan
| |
| Kevin Walzer 2007-08-15, 7:17 pm |
| Joe English wrote:
> Mark Janssen wrote:
>
> That's an excellent question. Are there any languages,
> toolkits, or frameworks out there with good printing support?
>
> The main obstacle to good printer support in Tcl is that
> nobody knows how to do it. If somebody, anybody, has figured
> this out, then we can solve the bulk of the problem just by
> stealing their design.
>
>
> --Joe English
wxWidgets does. It's a C++ library, but has scripting interfaces
(wxPython is the most well-known). And it seems to provide excellent
printing support across platforms, wrapping the native API on each
platform.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
| |
|
|
| Arjen Markus 2007-08-16, 8:10 am |
| On 15 aug, 20:37, jengl...@flightlab.com (Joe English) wrote:
> Mark Janssen wrote:
>
>
> That's an excellent question. Are there any languages,
> toolkits, or frameworks out there with good printing support?
>
> The main obstacle to good printer support in Tcl is that
> nobody knows how to do it. If somebody, anybody, has figured
> this out, then we can solve the bulk of the problem just by
> stealing their design.
>
> --Joe English
I just did a few experiments with CUPS: the library - at least
superficially - is very easy to use. I wrote a small program
to find out what printers there are on the system I have
access to (one call to the CUPS library and some 20 lines
for declarations and printing) and then a small program to
print a file with default options - again one call to the CUPS
library.
In the past I had been unable to find out what printers (and
especailly what properties!) my system had, so I maintained a list in
a configuration file. But CUPS seems to provide a
lot of such information for the cost of a single call.
Of course this does not solve the basic problem: what information
do we want to print and how do we get into the right shape
(file)? But there is no need to go through hoops with lp or lpr
and their options, it seems.
Regards,
Arjen
| |
| Joe English 2007-08-17, 7:20 pm |
| Synic wrote:
>Most of the things on my wishlist are GUI interface matters:
>
>* Some more of the Tk widgets going into Tile would be good. Having a
>platform native spinbox and text widget would be useful, for example.
[ More on text widgets later ]
>* A way to have a completely flat button widget in either Tk or Tile
>on Mac OS X in button bars. Specifying -relief, etc, in Tk doesn't work
>at present.
You can do this with Tile pretty easily, since the
widget appearance is so simple in this case -- it's
basically just a label (image and text).
Something like:
style layout Toolbar.TButton {
Toolbar.TButton.padding -children {
Toolbar.TButton.label
}
}
style configure Toolbar.TButton -padding {... whatever looks right ... }
(The built-in Toolbutton layout on OSX will do something
like this in a future version.)
Then in application code:
ttk::button $tb.foo -image $fooIcon -text "Foo!" -compound top
Or, to better follow this w's OSX UI guidelines, generate
multiple icons and specify state-specific variants for -image,
like "-image [list $fooIcon disabled $grayFooIcon pressed $darkFooIcon]"
>* Freshening some of the other Tile widgets on Mac. In particular,
>notebook tabs are looking increasingly unusual.
Yeah, sorry about that. Tile's aqua theme appearance is
still circa OSX 10.2; I haven't been keeping up with Apple's
continual UI overhauls very well.
On that topic: if anyone knows how to draw 10.4-style "segmented
button" controls with the Carbon API, please let me know!
The ttk::notebook implementation is _almost_ capable of drawing
10.4-style notebooks, this is the only part that's missing.
--Joe English
| |
| Joe English 2007-08-17, 7:20 pm |
| Synic wrote:
>Bryan Oakley <oakley@bardo.clearlight.com> wrote:
>
>The effect on the widget border itself looks good. But the text widget is
>now limited to single-line of a limited length. Anything past "The cat sat
>on the " is lost when running the above on my Mac...
First thing I'd suggest is, instead of packing a [text] widget
inside a [ttk::entry], pack it inside a [ttk::frame] that's
configured to look like a ttk::entry: [ttk::frame $f -style TEntry].
Entry widgets don't work very well as containers -- they want to
control their own width and height for one, plus there's
a lot of other built-in behavior that you need to turn off
lest it get in the way. Frame widgets work better as containers,
since that's what they were designed for.
>To me, it looks like in getting the external border effect, it's setting
>the focus to be the .textContainer entry widget rather than the .t text
>widget which needs to have real focus for editing.
>
>That's why I was saying before... I'd probably have to dig through the Tile
>sources to see what's actually triggering the blue backgrounds in ttk::entry
>when focus is applied, because we can't really switch focus away from the
>text widget because then we can't actually use it ;-).
That's controlled by the 'focus' state bit, which in turn
is controlled by a built-in event handler. (See CoreEventProc
in generic/widget.c if you're curious about the details,
but basically: [$w state focus] gets set whenever the
widget gets the focus, [$w state !focus] whenever it
loses it. This happens automatically for all Tile
widgets.)
So one approach is to set (resp. clear) the wrapper widget's
'focus' bit whenever the text widget gets a <FocusIn> (resp.
<FocusOut> ) event.
The only other thing I can think of that you need to worry about
is getting the padding / borderwidth right, since that can
change from theme to theme. But if all you need to care about
is OSX, just measure it and hardcode that value.
--Joe English
| |
| Larry W. Virden 2007-08-23, 8:09 am |
| On Aug 22, 7:26 pm, Lan <l...@falleagle.net> wrote:
> Probably most of what I'm missing has already been written, so I'll
> say "knowledge of what's already available and where to find it." This
> forum helps, because people are always courteous when one asks. The
> wiki is very helpful if I already know a name or get lucky on a query.
> I get Uwe's newsletter and the c.l.t digest and scour them for things
> on my wish list, but that's hit or miss.
>
> I know that there has been extensive discussion of trying to emulate
> perl's CPAN, and because I haven't followed the discussion, I'll
> assume that it was thoughtful and there were practical reasons not to.
>
> So that's my contribuition to the question. I don't know how to find
> out what I don't know about.
I am uncertain whether a CPAN emulation would help you find what you
don't know about.
As for a repository of software, you might take a look at http://wiki.tcl.tk/teacup
.. It is definitely not CPAN. It is more like the ActivePerl module
repository. However, it is at least one group's attempt at providing a
repository.
The primary reason for not developing a full CPAN emulation seems to
me to be that those who are contributing to the community are all busy
with other things.
If some of those in the community who always have looked for a way to
contribute wanted to ban together to create such a thing, they could
do so.
| |
| tom.rmadilo@gmail.com 2007-08-24, 4:27 am |
| On Aug 15, 11:33 am, jengl...@flightlab.com (Joe English) wrote:
> SOAP vs. REST is comparing apples and orangutans -- REST is
> an abstract architectural style, while SOAP is a specific
> (very large) family of concrete (and very complex) protocols.
> A better comparison would be SOAP vs. a concrete RESTful
> protocol like GData.
....
> And veering back on topic, support for REST-style web services
> is an area that I find lacking in Tcl.
Yes, REST appears to be HTTP/GET with an XML-like payload in return.
I'm not really sure myself what the benefit of this scheme is. XML
still has to be handled on both ends client/server. And the point of
REST is that things don't change on the server, at least not as a
result of the RESTful operation. If this characterization is correct,
and that is a big IF, it doesn't have much in common with SOAP,
although you might be able to describe the RESTful service as SOAP/
HTTP/GET, without all the additional overhead of SOAP.
For simple, read-only services, SOAP is probably too much, and it also
lacks a useful, transferable URL for the remote object. Said another
way, the SOAP engine on the server has to reconstruct the full path of
the object as an internal process, using a combination of URL, HTTP/
SOAP headers and POST payload, maybe including SOAP-HEAD headers,
proxies, and on and on. Obviously this is not something you can
bookmark, or even successfully program. REST boils all this down into
a simple URL, which could also be constructed by the server, to
represent the product of any SOAP request. Remembering that the
request should not have any effects on the server. I'm also not sure
if a RESTful service can specialize the result based upon the identity
of the requesting client.
So I'm wondering what is missing in Tcl, as an abstract concept there
is no problem, Tcl is a programming language, supports network client/
server operations, etc. Maybe a client API for handling a particular
protocol like GData? Are there any client/server examples/APIs from
other programming languages?
But it seems important to remember that modern web services are
intended to abstract out the programming environment, which should be
a big benefit for Tcl. Yes we are probably stuck with XML, but that is
far better than dealing with encoding/decoding every possible data
structure from every programming language exposed as SOAP-RPC.
| |
| Darren New 2007-08-24, 4:27 am |
| tom.rmadilo@gmail.com wrote:
> Yes, REST appears to be HTTP/GET with an XML-like payload in return.
Actually, REST is supposed to have URLs in the payload pointing to other
resources. The benefit is that proxies, caches, and so on can determine
not to fetch new data if you GET the same thing twice in quick succession.
> I'm not really sure myself what the benefit of this scheme is. XML
> still has to be handled on both ends client/server.
That's not fundamental to REST. That's just how people deliver the data.
> And the point of
> REST is that things don't change on the server, at least not as a
> result of the RESTful operation.
It doesn't change the server to issue a RESTful GET operation. A PUT,
POST, or DELETE will change the server.
> For simple, read-only services, SOAP is probably too much, and it also
> lacks a useful, transferable URL for the remote object.
That's what REST provides, yes.
> Remembering that the request should not have any effects on the server.
Incorrect. It's just that in the HTTP headers, where proxies and buffers
can see them, REST indicates whether the result can be buffered.
> I'm also not sure
> if a RESTful service can specialize the result based upon the identity
> of the requesting client.
Yes. Plus, you can use all the normal HTTP security stuff like SSL,
DIGEST-MD5, and so on. Unfortunately, it seems every REST service uses
their own authentication method, for some reason, rather than sticking
with the standards. (At least, most do some variation of HMAC, but pick
different things to HMAC and different places to put the result in.)
> So I'm wondering what is missing in Tcl,
Not a whole lot, really. I did a whole library to interface Tcl with
Amazon S3. It wasn't really that hard, except for the XML libraries not
really being fully functional with the 8.5a stuff at the time I was
doing that. That, and the fact that the http library invokes the event
loop even if you tell it to block, so I couldn't use that and also have
a blocking version.
I'm planning to release it to TclLib when 8.5 hits beta and I know the
syntax isn't going to change any more.
> But it seems important to remember that modern web services are
> intended to abstract out the programming environment, which should be
> a big benefit for Tcl. Yes we are probably stuck with XML, but that is
> far better than dealing with encoding/decoding every possible data
> structure from every programming language exposed as SOAP-RPC.
The main difference between REST and SOAP is that every REST interface
has to be coded from scratch in each language you want to use it from.
SOAP provides not only the wire format, but data structures for
describing the wire format at a sufficient detail that software can
generate the interface automatically for you. This also means that if
you *don't* have that automation, SOAP is a royal PITA to use, which is
why I interfaced to the AWS REST interface instead of the SOAP interface.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
| |
| minuit00@hotmail.fr 2007-08-24, 4:27 am |
| a good book - or more - related to tcl/tk 8.5
| |
|
| On Aug 14, 3:46 pm, Mark Janssen <mpc.jans...@gmail.com> wrote:
> On 13 aug, 17:43, "Larry W. Virden" <lvir...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
> And to add my own 2c. What I have missed recently is http 1.1 (or at
> least http supporting keepalives) this is required for some
> authenticating proxies for instance. There are some changed versions
> of the http package which include this, but it would be nice if the
> core http supports it.
>
> Mark
realbasic
| |
|
|
|
|
|