Perl/Tk Wishlist

First, thank you for the wonderful tool. I have found that Tk,
especially
with the Canvas widget, is a very useful tool for developing
cross-platform
applications. All of the features, such as being able to use graphics
primitives, dynamically update all properties of an object, to specify
the
exact properties of Canvas widgets, etc, to be absolutely essential to
being
able to design some applications.

I have created this wishlist of features that would be a benefit to
many projects.
Since I am mainly a perl programmer myself and I am unfamiliar and not
proficient with C or the Tk internals. I have tried to keep this list
as
short as possible, including mostly features that cannot be implemented

at the perl level (reasonably efficiently anyway) and needed to
implement what
I need myself  at the perl level, tools to make tools.

I believe that a good cross platform, general purpose graphics toolkit,
should provide access to both a high
level and low level graphics programming features (such as graphics
primitives). This gives the programmer the
freedom of using one of the high level widgets to quickly build an
application, yet, if one of the high level widgets does not fit their
needs,
also gives them the ability to construct their own widgets, and do it
in a cross platform, portable manner. Giving the
programmer, if they request it, a fine and absolute level of control
over
the interface is important. Futhermore, giving easy access to low level
features
, such as graphics primitives,
from the perl level would allow new Tk widgets to be more easily
created by
those not familiar with X or Tk internals. The Tk Canvas does this well
and I
suggest some features here to improve the flexibility of this.



I personally like the motif style of UI design. This is my own personal
taste. So I do hope that even if themes are implemented, the existing
look
and feel remains an avialable option.


Also, as a philosophy, we should keep in mind that the feature that one
programmer finds of no use is essential to another programmers needs.
Just
because a feature does not fit our own needs does not mean it is
unnecessary.

Agian, In this letter, I focus on tools that give the programmer some
low level
tools needed to construct higher level tools,
the basic tools that a programmer could use to easily construct new
features.
 
control
of an Toplevel or Frame widget, and manage its child windows, such as
with using ctwm and its -w option.

Perhaps this could be done through a -nomanage option
example:

$window->Frame(-nomanage=>1, -container=>1);

Make sure commands are avialable to get all window ids necessary for
this to be done, and perhaps also Tk should expose the functionality
of the XReparentWindow Xlib function to Tk programs.

Multiple
toplevel widgets could be created inside the parent window and the user
could
for instance start a window manager like ctwm in the parent window.
Windows owned by other applications could also be reparented into
them.

This feature may not be able to be used at all under native windows
GUI,
but perhaps
if Perl/Tk is compiled under cygwin to use the cywgin X server.

 



This allows a piece of text in the Tk Text widget
to be made uneditable, but not the whole widget.
 

Urgency: High  Ease of Implementation: Likely very simple

No entry or record is created for this object by Tk, and it will not be
refreshed  or updated by Tk, such as on an expose event (the user can
do this manually by catching an expose event if they wish), or when
other objects are redrawn. Yes, this does have uses.

Since no record of this object is kept by Tk, bbox and coords values
should
be returned when the object is created, values can be returned in key
value
pairs and hashified when they are returned, since they will not be able
to
be retrieved later. Very useful for text object where we do not know
the size of
object until it is created.

my ($self, %params)=$tk->create("Text", 2, 2, -nopersist=>1,
text=>"Hello");
$x1=$params{coords_x1};
$y1=$params{coords_y1};
$x2=$params{coords_x2};
$x2=$params{coords_y2};
$bx1=$params{bbox_x1};
$by1=$params{bbox_y1};
$bx2=$params{bbox_x2};
$bx2=$params{bbox_y2};

When a non-persistant object is drawn to a canvas, it overlays
everything else that
is already there, including persistant regular Canvas objects. It
is drawn over the top of any other objects in the Canvas, but an update
is
not performed by Tk for any of the other objects in the canvas. The
user, could
instead do the updating manually on the non-persistant object by
recording the position of the
objects and simply recreating the  objects on expose events or
when otherwise needed.
When Tk updates regular persistant Tk objects, and the non-persistant
objects
will not be redrawn they will be painted over when such updating
occurs.


This is useful in paint programs where keeping records of the object
locations and doing updating and layering of them is overkill for the
feature set desired.

This is similar to
the functionality provided by Xlib. Probably this would be used in a
Canvas
consisting entirely of non-persistant objects so the user could have
complete control
over redrawing and updating of all objects. Non-persistant objects
could be
mixed with normal ones, although that wouldnt work well, since no
attention would be paid to
redrawing the nonpersistant objects and since drawing nonpersistant
objects
would not trigger a redraw of persistant objects.


 
size of a
text object in a canvas, or else provide a function that does.

TK should provide a facility that accurately reports the coords of
objects.
 
(between
characters or around their margins), this should be
able to be disabled.
 

Urgency: High Ease of Implementation: Likely very simple

If a user wants to manually create copy and paste implementations this
would
allow them to do so, perhaps if they are using their own custom text
widgets.
 

Urgency: Somewhat Low / Ease: Possibly Difficult

Tk should allow the user to create an editable text box in the canvas
that is
like the regular Tk text box except it is a Canvas object and can have
a
transparent background and be layered with other Canvas objects. It
should support
text tags like Tk text box.

millueradfa@yahoo.com wrote:

> I personally like the motif style of UI design.

Yuck :)

> This is my own personal
> taste. So I do hope that even if themes are implemented, the existing
> look and feel remains an avialable option.

You probably need to address this to the Tcl newsgroup instead. While
themes are interesting to many Perl/Tk programmers, Tk development
happens by Tcl developers. Perl/Tk is just a port of Tk to give it a
Perl API.

> Also, as a philosophy, we should keep in mind that the feature that one
> programmer finds of no use is essential to another programmers needs.
> Just because a feature does not fit our own needs does not mean it is
> unnecessary.

Agreed.
 
> control
> of an Toplevel or Frame widget, and manage its child windows, such as
> with using ctwm and its -w option.

I'm not sure but the transient() method seems to attempt something of
this nature. I'm also not sure if it would be at all useful for a Frame,
but for a Toplevel I can see some potential. I have never used it
myself, though. Check out the Tk::Wm pods for more info.

> Make sure commands are avialable to get all window ids necessary for
> this to be done,

$top->id;

> and perhaps also Tk should expose the functionality
> of the XReparentWindow Xlib function to Tk programs.

You can embed other windows within Tk frames. Check out the -container
and -use options.

> Multiple
> toplevel widgets could be created inside the parent window and the user
> could
> for instance start a window manager like ctwm in the parent window.

Check out Tk::MDI on CPAN.

> Windows owned by other applications could also be reparented into
> them.

It is possible to embed non-Tk windows, but is a bit tricky. This has
been discussed multiple times before, and many posts have been made on
this newsgroup with sample code. Search the archives for more info.
 

Hmmm ... there was a post earlier today on the exact same topic.
Personally, I haven't given this much thought, so I can't comment on it.
 

hmm .. interesting .. what happens if you move the window or obscure it?

> ... Yes, this does have uses.

I'll take your word for it :)

> This is useful in paint programs where keeping records of the object
> locations and doing updating and layering of them is overkill for the
> feature set desired.

I don't get it. You don't explain much how having non-persistent objects
helps in paint programs. When working with a paint program, I expect to
be able to change the relative stacking of the objects, move them
around, and query their info. You want to lose all of this information?

> This is similar to
> the functionality provided by Xlib. Probably this would be used in a
> Canvas
> consisting entirely of non-persistant objects so the user could have
> complete control
> over redrawing and updating of all objects.

The user does currently have complete control of those actions.
 
>
> size of a
> text object in a canvas, or else provide a function that does.
>
> TK should provide a facility that accurately reports the coords of
> objects.

What do you think is wrong with the current coords() and bbox() methods?
 
>
> (between
> characters or around their margins), this should be
> able to be disabled.

That depends on your font. Check out Tk::Font docs for more info.
 

Tk::Clipboard is part of the latest Perl/Tk distribution.
 
>
>
> Urgency: Somewhat Low / Ease: Possibly Difficult
>
> Tk should allow the user to create an editable text box in the canvas
> that is
> like the regular Tk text box except it is a Canvas object and can have
> a
> transparent background and be layered with other Canvas objects. It
> should support
> text tags like Tk text box.

Interesting idea. You currently can embed widgets in a Canvas, so you
can have a real Tk::Text widget in there, but it's not what you want. I
suspect that with a bit of code, you can achieve your goal using the
Canvas text items. You'll have to keep track of boundaries, lines, etc
yourself though.

If you want a better canvas, check out Tk::Zinc. It is an OpenGL-based
replacement to Tk::Canvas.

My 2 cents,
--Ala

Ala Qumsieh wrote:
> millueradfa@yahoo.com wrote:
> 
>
> You probably need to address this to the Tcl newsgroup instead. While
> themes are interesting to many Perl/Tk programmers, Tk development
> happens by Tcl developers. Perl/Tk is just a port of Tk to give it a
> Perl API.

It's a pity that Tk development for the various language bindings
has been separated for so long.  It would have been to Tk's great
advantage, and subsequently the advantage of all languages that
use Tk, if more had been done to work at the real core level.

As it is, Tk does have themes now - Tcl/Tk that is, not Perl/Tk.
This is available through the tile extension:
http://tktable.sourceforge.net/tile/
This work is already in stable condition (it is in fact used in the
latest Perl Dev Kit 6.0 for the UIs).  It is being tracked for
inclusion in the Tk core for 8.5.  However, so are lots of other
things, so if people are interested in assisting in that effort,
feel free to join in the fray.

The plan is for Tk to get more elaborate at the core level for 8.5.
For Tcl/Tk users, and those who bound through Tcl, Tk has always had
a LOT of functionality - all in various extensions that you had to
go searching for on the net, or use a distribution like ActiveTcl.

You can use these things now with the Tcl::Tk module (available at
CPAN, author VKON, although I did all new low level xs code).  That
has some level of traditional Perl/Tk, but that itself could be
improved.
 
>
> Agreed.

True, but when placing things in the core, the idea is to have
features that most people will require, without some features that
require lots of code bloat, but are only used by 1% of programmers.
That said, we realize that Tk is lacking in many useful core
features that are common in UIs now, but only through one of many
extensions to Tk.  This is being addressed in 8.5.
 

You mean like dockable windows?  This feature will be in 8.5.
 

Ah yes, that's dockable windows, not sure what you meant above
then.

> You can embed other windows within Tk frames. Check out the -container
> and -use options.

This is more fragile than the new feature will be.
 
>
> Hmmm ... there was a post earlier today on the exact same topic.
> Personally, I haven't given this much thought, so I can't comment on it.

I've seen this request before.  It's easy to code up with the given
features of the text widget, but may be worth considering as a core
feature for simplicity.  Note that the text widget has already
gotten significant changes for 8.5 (now in alpha, which means
feature creep mode), like peered text widget and improved scrolling.

The other ideas are all good.  What isn't already available in some
form in the core could always be implemented and submitted for
inclusion through the TIP process.

--
Jeff Hobbs, The Tcl (and Tk) Guy
http://www.ActiveState.com/, a division of Sophos

On 11/8/04 7:51 AM, in article D_GdncBw-r4x9hLcRVn-1w@novus-tele.net, "Jeff
Hobbs" <jeffh@removethis.activestate.com> wrote:

> Ala Qumsieh wrote: 
<snip>
> You can use these things now with the Tcl::Tk module (available at
> CPAN, author VKON, although I did all new low level xs code).  That
> has some level of traditional Perl/Tk, but that itself could be
> improved.
>

Jeff -

Is there a Windows PPD file of this? Also, does that allow me to use
tcltkaqua libraries from Perl on OSX?

Robert

Robert Hicks wrote:
> Jeff Hobbs wrote: 
..
> Is there a Windows PPD file of this? Also, does that allow me to use
> tcltkaqua libraries from Perl on OSX?

We have to correct some build system test failures in order
for this to get updated as part of ActiveState's PPM module
set at http://ppm.activestate.com/.

As for tcltkaqua, yes, it does allow you to use that, so that
you get true native components (with tile as well) on OS X.
See this message for recent developments there:
http://aspn.activestate.com/ASPN/Ma...tcl-mac/2185892

--
Jeff Hobbs
http://www.ActiveState.com/, a division of Sophos