Prev: How to have access to all tcl procs and vars in a given interpreter
Next: Question about ttk_checkbutton widget
From: Jeff Godfrey on 8 May 2010 10:19
On 5/8/2010 4:09 AM, Arndt Roger Schneider wrote:

> The Tk canvas is not suiteable for what you try to achieve.

Well, as a general statement, I'd have to disagree. That is, I wrote
the previous versions of this app years ago using the Tk canvas and it's
worked remarkably well, until the data sets get overly large (which
isn't the norm, but does happen).

That version was really just a proof of concept and it's long over-due
for some improvements, which I've started on now. So, while I don't
agree with the general statement, I'm definitely stretching the
suitability of the canvas in some ways that make me uncomfortable.

Also, as mentioned previously, the apps connection to the canvas widget
is fairly loose, so I could easily replace it if there were a better
option. However, everything I've investigated so far has drawbacks -
including the canvas.

Thanks,

Jeff
From: Arndt Roger Schneider on 8 May 2010 12:36
Jeff Godfrey schrieb:

> On 5/8/2010 4:09 AM, Arndt Roger Schneider wrote:
>
>> The Tk canvas is not suiteable for what you try to achieve.
>
>
> Well, as a general statement, I'd have to disagree. That is, I wrote
> the previous versions of this app years ago using the Tk canvas and
> it's worked remarkably well, until the data sets get overly large
> (which isn't the norm, but does happen).
>

"overly large" is exactly the point.

> That version was really just a proof of concept and it's long over-due
> for some improvements, which I've started on now. So, while I don't
> agree with the general statement, I'm definitely stretching the
> suitability of the canvas in some ways that make me uncomfortable.
>
So getting it to work is not /urgent/?

> Also, as mentioned previously, the apps connection to the canvas
> widget is fairly loose, so I could easily replace it if there were a
> better option. However, everything I've investigated so far has
> drawbacks - including the canvas.

Well, I did read your comment on tkzinc text rotation and find it
hard to belief that rotating text in tkzinc does not work for you. I do have
tkzinc 3.3.2 installed under X11/osx with tk 8.4 and had/have similar
installations under aqua; no trouble whatsoever with transformations.
If you have a license issue with tkzinc, that is a serious obstacle.

Deduced from former postings: You are trying to work with a very large
amount of
(grouped) objects, apply transformations (rotation, zooming) onto those
objects.

Perhaps not all your requirements can be met in tkzinc/tkpath/...
either, but perhaps
some of your requirements are *worthwhile* to integrate them in these
packages!

For instance: Using an excessive amount of tags to search and group objects;
replaced with explizit defined IDs for graphical objects. like ...

set ID [$cv add rect myrect ...]
# ID 's value is "myrect"

.... pre-defined IDs are needed for SVG conversion, too.

-roger
From: Donald Arseneau on 11 May 2010 00:09
On May 7, 2:06 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:

> > make an image out of any text and use that to detect where the "ink"
> > is.
>
> I'm interested; how do you do that ?
>
> I know about the 'window' image format from the Img package, but
> unfortunately it works only by grabbing the really displayed

I had thought either the Img or BLT facility did the trick, but
it seems not.

Even the canvas postscript route produced high-level postscript
that does not exactly match the canvas rendering. It could be
used, with a constricted pipeling through ghostscript or some
other renderer to make an approximate bitmap that could then
be used by Tcl.
From: Alexandre Ferrieux on 11 May 2010 05:39
On May 11, 6:09 am, Donald Arseneau <a...(a)triumf.ca> wrote:
> On May 7, 2:06 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> wrote:
>
> > > make an image out of any text and use that to detect where the "ink"
> > > is.
>
> > I'm interested; how do you do that ?
>
> > I know about the 'window' image format from the Img package, but
> > unfortunately it works only by grabbing the really displayed
>
> I had thought either the Img or BLT facility did the trick, but
> it seems not.
>
> Even the canvas postscript route produced high-level postscript
> that does not exactly match the canvas rendering.  It could be
> used, with a constricted pipeling through ghostscript or some
> other renderer to make an approximate bitmap that could then
> be used by Tcl.

Yes. It looks like Roger's suggestion of tkPath is the only method
satisfying all the conditions:

- works with vanilla canvas items, not new commands like pixane
- really offscreen, not screen snapshot like Img

Side note: maybe it would make sense to integrate at least some parts
of TkPath in Tk. In addition to this offscreen rendering issue, it
exposes the advanced Cairo-like graphical primitives that are now
becoming popular through HTML5's <canvas> tag. Just a matter of
keeping up with the Javascript competition...

-Alex
First  |  Prev  | 
Pages: 1 2 3
Prev: How to have access to all tcl procs and vars in a given interpreter
Next: Question about ttk_checkbutton widget