Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ANN: tooltip 0.0.1 (alpha)

20 views
Skip to first unread message

Mark G. Saye

unread,
Dec 15, 2003, 3:18:58 AM12/15/03
to
OK, I've been sitting on this for quite a while in the hopes of finding
a little time to finish it off, but in the spirit of the festive season,
here it is anyway.

http://wiki.tcl.tk/tooltip
http://wiki.tcl.tk/eWidgetsToolkit


tooltip package for Tcl/Tk

Description

tooltip is a package that provides a tooltip widget.

Features

* Creates a new tooltip widget.
* Creates own namespace as child of calling namespace.
* Exports main command tooltip::tooltip.
* Creates all commands and variables in own namespace
(does not pollute global, or parent, namespace).
* TIP 55 compliance for packaging and metadata.

Version

This is version 0.0.1 (alpha).

Changes

Please refer to the file CHANGELOG.txt included in the 'doc'
directory of the archive.

Requirements

* Tcl/Tk >= 8.3 (not tested with earlier versions)

Download

The package can be downloaded from:

http://www.speakeasy.org/~msaye/tk/tooltip/
http://www.speakeasy.org/~msaye/tk/tooltip/tooltip-0.0.1.tgz

Installation

Extract the archive file into your tcl package path. The package is
pure tcl code and requires no compilation.

Documentation

Please refer to the file tooltip.html or tooltip.txt included in the
'doc' directory of the archive.

Examples

Please refer to the files included in the 'examples' directory of
the archive.

Copyright

The tooltip package and all accompanying material is:

Copyright (C) 2003, Mark G. Saye <mark...@yahoo.com>

License

This package is released under the BSD license. Please refer to the
file LICENSE.html or LICENSE.txt included in the 'doc' directory of
the archive for information on usage and distribution of this
package, and for a DISCLAIMER OF ALL WARRANTIES.

Contact

Please send questions, comments, bug reports, patches, requests to:

Mark G. Saye <mark...@yahoo.com>

------------------------------------------------------------------------
Copyright (C) 2003, Mark G. Saye <mark...@yahoo.com>

--
Mark G. Saye
markgsaye @ yahoo.com

David N. Welton

unread,
Dec 15, 2003, 3:24:26 AM12/15/03
to

Cool! This would be an excellent candidate for tklib, if you were so
amenable...

--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/

Mark G. Saye

unread,
Dec 15, 2003, 11:09:48 AM12/15/03
to
David N. Welton wrote:
> Cool! This would be an excellent candidate for tklib, if you were so
> amenable...

Certainly. And hopefully the first of many contributions from me.

Jeff Hobbs

unread,
Dec 15, 2003, 12:58:05 PM12/15/03
to
David N. Welton wrote:
> Cool! This would be an excellent candidate for tklib, if you were so
> amenable...

FWIW, I already have a tooltip package being prepared for inclusion
in tklib that is rather full-featured. I'd like to know what Mark's
does, to see if there is not 100% overlap already (I can't find any
actual feature docs online).

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

David N. Welton

unread,
Dec 15, 2003, 1:01:49 PM12/15/03
to
Jeff Hobbs <je...@activestate.com> writes:

> David N. Welton wrote:
> > Cool! This would be an excellent candidate for tklib, if you were so
> > amenable...
>
> FWIW, I already have a tooltip package being prepared for inclusion
> in tklib that is rather full-featured. I'd like to know what Mark's
> does, to see if there is not 100% overlap already (I can't find any
> actual feature docs online).

It's worth having a look at, it's quite good, and has complete
documentation that should give you an idea of what it does.

If I had to complain about anything, I would prefer to have it a
little easier to just copy the tcl/ subdirectory into a subdirectory
of my own project (with a name I choose) and use it like that.

Mark G. Saye

unread,
Dec 15, 2003, 1:27:15 PM12/15/03
to Jeff Hobbs
Jeff Hobbs wrote:
> David N. Welton wrote:
>
>> Cool! This would be an excellent candidate for tklib, if you were so
>> amenable...
>
>
> FWIW, I already have a tooltip package being prepared for inclusion
> in tklib that is rather full-featured. I'd like to know what Mark's
> does, to see if there is not 100% overlap already (I can't find any
> actual feature docs online).

I've uploaded the documentation into:

http://www.speakeasy.org/~msaye/tk/tooltip/doc/
http://www.speakeasy.org/~msaye/tk/tooltip/doc/tooltip.html

to save you having to download and extract. I've tried to make the
documentation as complete as possible. I'm open to suggestions, though.
(And I know you're gonna say 'doctools' format, aren't you? ;-} )

I can also put up some screenshots, if you like.

Jeff, you may remember we had some brief discussion back in Sept. I
liked the nice simple API in your tooltip package, but wanted to support
a few extra features, such as:

- import settings from the options database
- configure many extra label options (such as bg/fg etc)
- tooltips on text tags (as well as canvas items)
- multiple display screens
- status message display (extended help)
- no global variables
- tooltips that follow the cursor (can be useful for large widgets)
- preferences for all tooltips, or by groups, or single widgets

I don't know that I've succeeded in doing everything I'd hoped (it's
been a while since I touched the code), but I wanted others to see what
I've been doing.

Mark G. Saye

unread,
Dec 15, 2003, 1:35:37 PM12/15/03
to David N. Welton
David N. Welton wrote:
> Jeff Hobbs <je...@activestate.com> writes:
>
>
>>David N. Welton wrote:
>>
>>>Cool! This would be an excellent candidate for tklib, if you were so
>>>amenable...
>>
>>FWIW, I already have a tooltip package being prepared for inclusion
>>in tklib that is rather full-featured. I'd like to know what Mark's
>>does, to see if there is not 100% overlap already (I can't find any
>>actual feature docs online).
>
>
> It's worth having a look at, it's quite good, and has complete
> documentation that should give you an idea of what it does.

Thanks, David.

> If I had to complain about anything, I would prefer to have it a
> little easier to just copy the tcl/ subdirectory into a subdirectory
> of my own project (with a name I choose) and use it like that.

I wanted to keep the file hierarchy in the structure proposed by TIP55.
It seems like quite a good system. Would putting a second pkgIndex.tcl
file inside the tcl/ subdirectory help? Or do you have any other
suggestions?

David N. Welton

unread,
Dec 15, 2003, 3:03:47 PM12/15/03
to
"Mark G. Saye" <mark...@yahoo.com> writes:

> > If I had to complain about anything, I would prefer to have it a
> > little easier to just copy the tcl/ subdirectory into a
> > subdirectory of my own project (with a name I choose) and use it
> > like that.

> I wanted to keep the file hierarchy in the structure proposed by
> TIP55. It seems like quite a good system. Would putting a second
> pkgIndex.tcl file inside the tcl/ subdirectory help? Or do you have
> any other suggestions?

Hrm. I see your point, but I think that in one way or the other, the
code should be very easy to get started with - no futzing.

Any idea why it wouldn't be working with a table from Tktable? It
works if I create a simple table from wish normally, but inside my
program it doesn't:-/

set titlelist [table $frame.titles -yscrollcommand \
[list $scroll set] -cols 2 -rows 0 -cache 1 \
-colstretchmode all -justify left -anchor w \
-state disabled -selecttype row \
-colstretchmode last \
-browsecommand [list $this titleselect %S %s]]
$titlelist width 0 4
bind $titlelist <KeyPress> [list gui::findletter $this %A]
$scroll configure -command [list $titlelist yview]

# Create a title tooltip.
tooltip::tooltip $titlelist -text "Ok... so far so good"

It works ok for buttons and other things in the program, but not with
the table...argh!

Thanks,

Mark G. Saye

unread,
Dec 15, 2003, 4:06:55 PM12/15/03
to David N. Welton

If the widget is disabled, the tooltip is never scheduled to appear.
Have a look in the proc tooltip::setup. I guess I should modify the
docs. It'll have to wait, though.

Also, if you want some info about what is happening, you can turn on
debugging with:

set :;tooltip::debug 3

or higher (currently 5 is the highest, 1 is the default, 0 is for no
output) before or after the "package require tooltip" command.

David N. Welton

unread,
Dec 15, 2003, 4:19:15 PM12/15/03
to
"Mark G. Saye" <mark...@yahoo.com> writes:

> If the widget is disabled, the tooltip is never scheduled to
> appear. Have a look in the proc tooltip::setup. I guess I should
> modify the docs. It'll have to wait, though.

Aha. That's the problem alright. I'm not sure about it... it's
definitely the wrong behavior for the program I'm writing. I want
information about the table cell I've got the mouse on.

David N. Welton

unread,
Dec 15, 2003, 4:25:20 PM12/15/03
to

Actually, I think I may need some more advice:

I commented out the line that disables tooltips on disabled items.

Ideally, I would like the tooltip to change whenever I am in a new
table cell, and I want to change the contents as well. Any ideas
about doing the first, or am I just better off at this point
extracting the code I need and going with it? As far as the second, I
guess what I would need is a -command option. I prefer that to
-variable, because it's more flexible, without having to use crutches
like trace.

Mark G. Saye

unread,
Dec 15, 2003, 6:13:00 PM12/15/03
to David N. Welton
David N. Welton wrote:
> Actually, I think I may need some more advice:
>
> I commented out the line that disables tooltips on disabled items.

Maybe we should try and make this a configuration option. It just seemed
natural that disabled widgets should not show tooltips. Maybe a
-enabledisabled option, or -showdisabled, or just -disabled ?

> Ideally, I would like the tooltip to change whenever I am in a new
> table cell, and I want to change the contents as well. Any ideas
> about doing the first, or am I just better off at this point
> extracting the code I need and going with it? As far as the second, I
> guess what I would need is a -command option. I prefer that to
> -variable, because it's more flexible, without having to use crutches
> like trace.
>

How do you see this working? Eval the -command option when the mouse
enters the widget? What if the -follow option is set? Should the tooltip
update itself if the cursor moves into another table cell? How would it
know when to update? For every <Motion> event? How much overhead would
that cause?

I'm not very familiar with tktable - is it possible to [bind] to
different table cells, the same way you can bind to text tags and canvas
ids/tags? If so (and it follows the same syntax as text/canvas), you
should be able to use the tooltip package as it stands now. (Having just
looked at the tktable docs, it seems not)

It should be easy enough to add in a -command option (with bind-style %
substitutions for X/Y cursor position?). Except that I'll be travelling
a fair bit over the holidays, and don't know how much hacking time I'll
get ;-}

Please keep the feature requests coming, though. I'd like to incorporate
as many as I can.

David N. Welton

unread,
Dec 16, 2003, 3:34:37 AM12/16/03
to
"Mark G. Saye" <mark...@yahoo.com> writes:

> David N. Welton wrote:

> > Actually, I think I may need some more advice: I commented out the
> > line that disables tooltips on disabled items.

> Maybe we should try and make this a configuration option. It just
> seemed natural that disabled widgets should not show tooltips. Maybe
> a -enabledisabled option, or -showdisabled, or just -disabled ?

I don't know what the general case might be, but I want to decide
myself whether the tooltip is good to go or not.

> > Ideally, I would like the tooltip to change whenever I am in a new
> > table cell, and I want to change the contents as well. Any ideas
> > about doing the first, or am I just better off at this point
> > extracting the code I need and going with it? As far as the
> > second, I guess what I would need is a -command option. I prefer
> > that to -variable, because it's more flexible, without having to
> > use crutches like trace.

> How do you see this working? Eval the -command option when the mouse
> enters the widget? What if the -follow option is set? Should the
> tooltip update itself if the cursor moves into another table cell?
> How would it know when to update? For every <Motion> event? How much
> overhead would that cause?

Hrm, actually when I think about it, this is overkill. I think I am
ok with changing the text via configure every time I select a new cell
in the table. I also need to move the tooltip though, and redisplay
it after the delay when a new cell is selected.

> It should be easy enough to add in a -command option (with
> bind-style % substitutions for X/Y cursor position?). Except that
> I'll be travelling a fair bit over the holidays, and don't know how
> much hacking time I'll get ;-}

Ok, no problem:-) Have a safe trip!

Ralf Fassel

unread,
Dec 16, 2003, 4:48:39 AM12/16/03
to
* "Mark G. Saye" <mark...@yahoo.com>

| It just seemed natural that disabled widgets should not show
| tooltips.

Sometimes I'd like to show _why_ a widget is disabled. A la `This
does foo, but only when the option bar is true'.

| > As far as the second, I guess what I would need is a -command
| > option. I prefer that to -variable, because it's more flexible,
| > without having to use crutches like trace.
| >
| How do you see this working? Eval the -command option when the mouse
| enters the widget?

When the tooltip is about to open. Eval the command and use the text
it returns for display.

| It should be easy enough to add in a -command option (with bind-style
| % substitutions for X/Y cursor position?).

That %-substs would be useful, too. That way one could e.g. check
where exactly the mouse is over a displayed GIF and act accordingly.

R'

David N. Welton

unread,
Dec 16, 2003, 9:38:43 AM12/16/03
to

I don't mean to be such a difficult beta tester, but there's another
thing that would be useful:-) The ability to manually set the geometry
in some way. I think that if I had that, I wouldn't be concerned
about the cursor going over other table cells, although I still
wouldn't mind that. That way, when a new cell is selected, I can
position the tooltip right under it.

Bryan Oakley

unread,
Dec 16, 2003, 10:26:59 AM12/16/03
to
David N. Welton wrote:

> "Mark G. Saye" <mark...@yahoo.com> writes:
>
>
>>David N. Welton wrote:
>
>
>>>Actually, I think I may need some more advice: I commented out the
>>>line that disables tooltips on disabled items.
>
>
>>Maybe we should try and make this a configuration option. It just
>>seemed natural that disabled widgets should not show tooltips. Maybe
>>a -enabledisabled option, or -showdisabled, or just -disabled ?
>
>
> I don't know what the general case might be, but I want to decide
> myself whether the tooltip is good to go or not.

The way I solve this in my own tooltip code is to have a command that is
called to massage the tooltip text before it is displayed. If the result
of the "massage" is a null string, it is not displayed. It looks
something like this to an application:

::tooltip::configure -command myTooltipCommand
::tooltip::enable .button "Tooltip text"
::tooltip::enable .menu "menuitem" "Tooltip text"
::tooltip::enable .canvas "id" "Tooltip text"
::tooltip::enable .text "tag" "Tooltip text"
...
# "widget" is the widget for which a tooltip is displayed
# "index" is a text tag, canvas tag or menu item for widgets
# of class Text, Canvas or Menu.
proc myTooltipCommand {widget index tooltip} {
...
if {$IWantToTurnOffThisTooltip} {
return ""
} elseif {$IWantToChangeThisTooltip} {
return "Hello, World!"
} else {
return $tooltip
}
}

This solution seems to work well in practice because it allows me, the
application developer, to choose at runtime whether or not to display a
tooltip in the event I want or need to modify the default behavior. Not
only that, but if I need to change the tooltip text at the moment it is
to be displayed I have that option too (for example, I could run the
text through a message catalog).

The original topic of this (sub)thread is making tooltips work on cells
in tkTable. My code allows tooltips to be associated with only a portion
of a widget (canvas item, text tag, menu item). If your tooltip package
supports such a notion it seems natural to extend that to include a
tktable row/cell. Combining that with a custom command that is run just
before displaying the tooltip would solve the problem.

msaye

unread,
Dec 21, 2003, 7:18:25 AM12/21/03
to David N. Welton
David N. Welton wrote:
> I don't mean to be such a difficult beta tester,

Not at all! Testing is only a good thing. ;-}

> but there's another
> thing that would be useful:-) The ability to manually set the geometry
> in some way. I think that if I had that, I wouldn't be concerned
> about the cursor going over other table cells, although I still
> wouldn't mind that. That way, when a new cell is selected, I can
> position the tooltip right under it.
>

Yeah, that's a sensible suggestion. I had planned to include an option
to specify the position of the tooltip relative to the cursor, but an
absolute position (or position relative to the widget) could be useful
too. The width/height would prob still have to be dynamic (to fit the
tooltip text), but the x/y position could be specified somehow. It's on
the list of features to add when I get 'round to it. Unfortunately, my
laptop hard-disk just crashed (just what I needed), so it'll have to
wait until Jan/Feb sometime.

Mark /

0 new messages