as if i remember Max in the olden days the inlet and outlet descriptors for objects were listed in the left bottom corner of the window. possible to give a choice for either way or is that too much coding overhead?

scott

On Tue, Mar 6, 2012 at 2:11 PM, Jonathan Wilkes jancsika@yahoo.com wrote:

----- Original Message -----

...

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-list List pd-list@iem.at Sent: Tuesday, March 6, 2012 4:05 PM Subject: Re: tooltips in pd-extended 0.43

I think that we should be pushing GUI stuff to the Tcl side of things as much as possible, plus I prefer the current tooltip display down on the lower right. I find that popups right next to the mouse are often

annoying.

I do, too, but every GUI toolkit and its brother hovers them to the side of the current mouse location.

-Jonathan

...

.hc

On 03/06/2012 02:54 PM, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: Jonathan Wilkes jancsika@yahoo.com To: Hans-Christoph Steiner hans@at.or.at Cc: Sent: Tuesday, March 6, 2012 2:53 PM Subject: tooltips in pd-extended 0.43

Hello, Hans asked me to write up an explanation of the new tooltips in

pd-extended

...

...

0.43. Attached are some patches that outline how they work. Just open tips-help.pd.

Tooltips get their tip information from the [pd META] subpatch inside

the help

...

...

patch for

the object. So if you want to have tooltips for your externals, or

set

...

of

...

...

abstractions, make

sure you have complete help patches for all of your object classes.

Hans-- Ivica modified my original patch in the most recent build of

pd-l2ork so

...

...

that the

tips follow the mouse, and he put the Enter/Leave logic on the c side

of things.

...

...

-Jonathan

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; pd-list List pd-list@iem.at Sent: Tuesday, March 6, 2012 5:26 PM Subject: Re: [PD] tooltips in pd-extended 0.43

Le 2012-03-06 à 14:11:00, Jonathan Wilkes a écrit :

...

I do, too, but every GUI toolkit and its brother hovers them to the side of

the current mouse location.

A function for setting the current tooltip of a certain window could look into user settings to figure out automatically whether a certain piece of text is to appear in a balloon vs in a label widget in a statusbar frame at the bottom of the window.

There are actually three possibilities-- balloon, statusbar, and window item at the bottom of the patch (which is the current pd-extended implementation).

As I said in the pd-l2ork thread related to this, I've combined two features-- canvas tips and objects tips-- into one concept, but maybe they should be broken out so that GUI-Class/GUI-plugin developers can choose one or the other.  (And still, the user could choose status bar vs. balloons.)

-Jonathan

Users would have the choice, while GUI-Class developers and GUI-Plugins developers wouldn't have to even think about it.

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

The window item is a canvas item and looks like the Firefox notification at the bottom left of

the browser-- it can overlap content of the page, but is transient (and gets out of the way of

the mouse if you happen to be mousing around in that area).  Firefox will put it on the bottom

right to get out of the way of the mouse, but I bounce mine at the top of the patch since patches

are more likely to be less wide than the browser window (which is typically full monitor width)

so the tip would probably take up the whole width in the first place.

Status bar would be like an extra widget (label I guess) running the full width of the window that is below the canvas, so it won't overlap the canvas but wouldn't leave after the tip goes away.

-Jonathan

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; pd-list List pd-list@iem.at Sent: Tuesday, March 6, 2012 6:00 PM Subject: Re: [PD] tooltips in pd-extended 0.43

Le 2012-03-06 à 14:40:00, Jonathan Wilkes a écrit :

...

There are actually three possibilities-- balloon, statusbar, and window

item at the bottom of the patch (which is the current pd-extended implementation).

I don't know what's the difference between the last two...

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

----- Original Message -----

From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; pd-list List pd-list@iem.at Sent: Saturday, March 10, 2012 1:07 PM Subject: Re: [PD] tooltips in pd-extended 0.43

Le 2012-03-06 à 15:38:00, Jonathan Wilkes a écrit :

...

Status bar would be like an extra widget (label I guess) running the full

width of the window that is below the canvas, so it won't overlap the canvas but wouldn't leave after the tip goes away.

How do I say that... Make sure that you don't create a situation in which people have to add more extra room in each patch to make space for something that may be transient but might overlap the wrong thing, e.g. the thing you're trying to edit or to have tip info about.

There's no way that would happen either way the current transient window item implementation.

Note that currently, patches save the window size, and not the canvas size. Perhaps it is time to move to saving a fudged canvas size, that is meant to be compatible with existing patches but is meant to compensate for a permanent status bar or any other additional structure.

Well, if anyone decides to use the status bar approach I guess they would need to take that into account.

The transient thing is harder to take into account... it is meant to both be used as a statusbar, and be counted as canvas space ?...

It is a canvas item on the same canvas as objects, etc.  Mine is a window item, I'm not sure if Ivica kept it that way but in both instances it's an item that exists on the canvas and gets deleted when the tip goes away.

I don't know, I think that canvas space is somewhat more touchy to manage in pd than in firefox, and I would think that it's not that much about full-width... the full-height seems at least as important... and the fact that pd patches always state their own size, while web pages rarely do... and pd patches more often rely on it... and it's often because they have no real means to do otherwise.

I have no idea what this means.  Try out the tooltips and see how they interact with the canvas.  I am in no way resizing the canvas nor the window.

-Jonathan

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

Le 2012-03-10 à 11:13:00, Jonathan Wilkes a écrit :

...

I don't know, I think that canvas space is somewhat more touchy to manage in pd than in firefox, and I would think that it's not that much about full-width... the full-height seems at least as important... and the fact that pd patches always state their own size, while web pages rarely do... and pd patches more often rely on it... and it's often because they have no real means to do otherwise.

I have no idea what this means.  Try out the tooltips and see how they interact with the canvas.  I am in no way resizing the canvas nor the window.

I was trying to talk about both the statusbar approach and the transient approach at the same time, sorry.

I'll try it... eventually... but these days, all I do with pd is a bit of music and that still makes me too lazy to get out of ext 42.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

On Mar 6, 2012, at 9:04 PM, Ivica Ico Bukvic wrote:

...

I think that we should be pushing GUI stuff to the Tcl side of things as much as possible, plus I prefer the current tooltip display down on the lower right. I find that popups right next to the mouse are often annoying.

I agree, except I don't want to push this notion to the point where unpredictable nature of tcl/tk's canvas implementation entirely hampers or limits tool's productivity and provides a half-baked feature. E.g. it's impossible to highlight nlets or show tooltips when trying to patch a cord because tcl/tk's canvas keeps "current" tag on the object that was last clicked on, and yet arguably this is where a new user needs tooltips the most. Selection of nlets and their detection is finicky at best, is very unforgiving (you really need to nail that pixel on the screen to get it), and the list goes on.

Also, the status bar tooltips are really not very intuitive and from the HCI perspective represent a considerable increase in cognitive load over text bubbles because one's eyes have to move at times relatively far from the point with which the tooltip is associated (heck, it is not even that obvious to which object it belongs to if there are two objects located near the cursor). Even a long arrow from an object to a status bar tooltip can cause a considerably higher cognitive load than a co-located tooltip. There is a reason why co-located tooltips exist even in browsers in addition to the somewhat arcane status bar model.

The only context where I see the status bar approach as the optimal way to display tooltips is when the tooltip emanates from a manual invocation that Jonathan pointed out earlier where it makes perfect sense to post it in one uniform place that is not dependent on the mouse position and thus potentially misleading.

Even better, off load this to a GUI plugin, then people can choose the method that works best for them. But I still like Jonathan's original implementation the best.

I find that the slightly increased load of moving my eyes down to the lower left corner a worthy sacrifice for not being interrupted by a popup bubble. Interruptions also increase cognitive load, and should be reserved for things that are the most important.

Most of the time, most users will not need the popup describing the inlet, so most of the time it'll just be an interruption.

.hc

Mistrust authority - promote decentralization. - the hacker ethic

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Ivica Ico Bukvic ico@vt.edu Cc: 'Jonathan Wilkes' jancsika@yahoo.com; 'pd-list List' pd-list@iem.at Sent: Wednesday, March 7, 2012 12:08 AM Subject: Re: [PD] tooltips in pd-extended 0.43

On Mar 6, 2012, at 9:04 PM, Ivica Ico Bukvic wrote:

...

...

I think that we should be pushing GUI stuff to the Tcl side of things

as

...

...

much as possible, plus I prefer the current tooltip display down on the lower right.  I find that popups right next to the mouse are often

annoying.

...

I agree, except I don't want to push this notion to the point where

unpredictable nature of tcl/tk's canvas implementation entirely hampers or limits tool's productivity and provides a half-baked feature. E.g. it's impossible to highlight nlets or show tooltips when trying to patch a cord because tcl/tk's canvas keeps "current" tag on the object that was last clicked on, and yet arguably this is where a new user needs tooltips the most. Selection of nlets and their detection is finicky at best, is very unforgiving (you really need to nail that pixel on the screen to get it), and the list goes on.

...

Also, the status bar tooltips are really not very intuitive and from the

HCI perspective represent a considerable increase in cognitive load over text bubbles because one's eyes have to move at times relatively far from the point with which the tooltip is associated (heck, it is not even that obvious to which object it belongs to if there are two objects located near the cursor). Even a long arrow from an object to a status bar tooltip can cause a considerably higher cognitive load than a co-located tooltip. There is a reason why co-located tooltips exist even in browsers in addition to the somewhat arcane status bar model.

...

The only context where I see the status bar approach as the optimal way to

display tooltips is when the tooltip emanates from a manual invocation that Jonathan pointed out earlier where it makes perfect sense to post it in one uniform place that is not dependent on the mouse position and thus potentially misleading.

Even better, off load this to a GUI plugin, then people can choose the method that works best for them.  But I still like Jonathan's original implementation the best.

I find that the slightly increased load of moving my eyes down to the lower left corner a worthy sacrifice for not being interrupted by a popup bubble.  Interruptions also increase cognitive load, and should be reserved for things that are the most important.

Most of the time, most users will not need the popup describing the inlet, so most of the time it'll just be an interruption.

This is a tough problem because the user experience of creating a patch is a lot more like a paint program than it is a code editor.  And in paint programs like Gimp there are no tooltips on the canvas, where the user must always be able to see as much of the image as possible without distraction.

There are, however, tooltips on the static toolbars, where they are much appreciated since Gimp relies so much on icons.  In that vein maybe there should be some way to have "Run mode" tooltips for GUI objects.  There I think it would make a lot more sense to implement them as some of the original tooltip patches do, where you can define a "tip" method for that particular class that lets the user specify what should be displayed (e.g., "Volume", "Reset", "Toggle Syrup").

-Jonathan

.hc

---

Mistrust authority - promote decentralization.  - the hacker ethic

On Mar 12, 2012, at 13:00, Mathieu Bouchard matju@artengine.ca wrote:

Le 2012-03-06 à 21:04:00, Ivica Ico Bukvic a écrit :

...

I agree, except I don't want to push this notion to the point where unpredictable nature of tcl/tk's canvas implementation entirely hampers or limits tool's productivity and provides a half-baked feature.

I found Tk to be quite predictable...

...

E.g. it's impossible to highlight nlets or show tooltips when trying to patch a cord because tcl/tk's canvas keeps "current" tag on the object that was last clicked on,

... but then I never tried using a tag named "current". Here's a relevant piece of DesireData :

Both of my comments refer to the implementation that is currently in Pd-ext vs. what I have come up with.

Also, what you're suggesting is essentially doubling the work that is already done inside C (again, assuming that one simply applies what you are proposing to the existing C code). C code already has getrect function that takes care of things like fuzzy logic, particularly when trying to connect a cord to an inlet where code already selects nearest inlet (at least it does in pd-l2ork).

I do understand that moving this into tcl/tk domain is ultimately a good thing as it strives toward separation of the GUI from the engine. However, since I am particularly interested in making sure that even interim solutions are as robust and as possible, I decided to alter the system to rely on the C implementation as that has proven to be a more robust (or perhaps I should say more complete and less redundant) approach than the original version.

In addition, and I think I may have already pointed this out earlier, FWIW I am also not convinced that having one system serve both headless runtime mode and network-based GUI editor is a good thing, particularly now that we have libpd. I am much more interested in having direct GUI implementation plus a separate (and if need be GUI-less) runtime client, as dealing with networked GUI has been a huge overhead for the pd-dev community both in terms of implementing new features as well as fixing existing bugs. If one agrees with this approach, then spending time on migrating things into tcl/tk domain may not be the time best spent...

def Canvas identify_target {x y f} { set c [$self widget] set cx [expr $x*$@zoom] set cy [expr $y*$@zoom] set stack [$c find overlapping [expr $cx-2] [expr $cy-2] [expr $cx+2] [expr $cy+2]] # reversing the stack is necessary for some things # not reversing the stack is also necessary for some other things # we have to figure out something. set stack [lreverse $stack] set target "" foreach tag $stack {set target [$self target $x $y $f $tag]; if {[llength $target] > 1} {break}} if {[llength $target] > 1} {return $target} {return [list "nothing"]} }

def Canvas target {x y f tag} is a much longer method, which looks at tags of a canvas-item to figure out where it comes from.

...

and yet arguably this is where a new user needs tooltips the most. Selection of nlets and their detection is finicky at best, is very unforgiving (you really need to nail that pixel on the screen to get it), and the list goes on.

In that code, I detect using a square of 5x5 pixels in size, where $cx $cy is the centre of it. This allows fuzzier detection. This is not necessarily the best solution, but that's what we came up with.

---

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC