Re: [PD] tooltips in pd-extended 0.43
On Mar 12, 2012, at 13:00, Mathieu Bouchard 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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
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 :
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___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
- Original Message - > From: Jonathan Wilkes > To: Mathieu Bouchard > Cc: pd-list List > Sent: Saturday, March 10, 2012 2:13 PM > Subject: Re: [PD] tooltips in pd-extended 0.43 > > > > - Original Message - >> From: Mathieu Bouchard >> To: Jonathan Wilkes >> Cc: Hans-Christoph Steiner ; pd-list List > >> 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. Oops, I meant there's no way that would happen with the current 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 >> > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
- Original Message - > From: Mathieu Bouchard > To: Jonathan Wilkes > Cc: Hans-Christoph Steiner ; pd-list List > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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. 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. 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 ?... 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. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
- Original Message - > From: Hans-Christoph Steiner > To: Ivica Ico Bukvic > Cc: 'Jonathan Wilkes' ; 'pd-list List' > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
> 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. While there may be "better," neither of them will be best when one relies on the Tcl/tk's implementation that delivers inconsistent results (which is BTW yet another frustrating form of cognitive load whose scope is significantly larger than either of the ones discussed below). > > 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. One's interruption, is other person's expectation. If I have tooltips enabled, I am expecting them to pop-up. Whether they do that in the bottom left corner or next to my cursor is irrelevant in terms of cognitive overhead associated with a pop-up action itself, except that one that is not co-located bears additional workload akin to that of shifting your gaze away from the road to check on your cell phone who is calling... > > 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. In my experience, I found that new users really need that guidance. If not, they can always turn the pop-up off. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] 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 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. Best wishes, ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
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 > To: Jonathan Wilkes > Cc: Hans-Christoph Steiner ; pd-list List > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
- Original Message - > From: Mathieu Bouchard > To: Jonathan Wilkes > Cc: Hans-Christoph Steiner ; pd-list List > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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. 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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
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 wrote: > > > > > - Original Message - > > From: Hans-Christoph Steiner > > To: Jonathan Wilkes > > Cc: pd-list List > > 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 > >>> To: Hans-Christoph Steiner > >>> 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tooltips in pd-extended 0.43
- Original Message - > From: Hans-Christoph Steiner > To: Jonathan Wilkes > Cc: pd-list List > 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 >>> To: Hans-Christoph Steiner >>> 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
Re: [PD] 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. .hc On 03/06/2012 02:54 PM, Jonathan Wilkes wrote: > - Original Message - >> From: Jonathan Wilkes >> To: Hans-Christoph Steiner >> 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
Re: [PD] tooltips in pd-extended 0.43
- Original Message - > From: Jonathan Wilkes > To: Hans-Christoph Steiner > 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 > tips.tar.gz Description: application/gzip ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
- Original Message - > From: Hans-Christoph Steiner > To: Jonathan Wilkes > Cc: Max ; pd list ; Ben > Baker-Smith > Sent: Sunday, January 15, 2012 5:34 PM > Subject: Re: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF [...] > > Fixing <> is probably a bigger thing than I can manage for > the Pd-extended 0.43 release, but patches are welcome. So the question of > the > moment is: are the tooltips usable enough to leave them in? Do they cause any > problems? > > .hc Yes they are usable. Problems are: * aforementioned loadbanging problem with formatting the label correctly * if you select an object, get a tooltip on it, then delete it before generating a event, the tooltip will persist until you mouse over (and leave) some other object * a little tricky to generate a outlet tooltip for iemgui outlets (small "hotspot" area for some reason) * since iemguis don't have a classwide tag for the object you can't get tooltips for them (only for their xlets) unless you make a label and position it on top of the iemgui Some things to be improved: * if the canvas goes below the bottom of the screen the tooltip should probably be shown on the lowest part of the canvas still showing * delay for the tooltip (dis)appearance could probably be tweaked * the "Edit mode" finger pointer has to be a little bit above the xlet to trigger the activeborder. Also, you can still be pointing at the activebordered xlet but not be over a hotspot that would trigger drawing a connection, which is annoying. * Something like [osc~] takes a float or signal to its left inlet, but it'd also be nice to display what those data types are supposed to mean in the context of the object. So instead of: "Inlet 0 of osc~: float signal" Something like "Inlet 0 of osc~ (frequency): float signal" Not sure how to change the PDDP tag to accommodate that: INLET_0 float signal ? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 13, 2012, at 12:59 AM, Jonathan Wilkes wrote: > - Original Message - > >> From: Hans-Christoph Steiner >> To: Jonathan Wilkes >> Cc: Max ; pd list ; Ben >> Baker-Smith >> Sent: Thursday, January 12, 2012 11:20 PM >> Subject: Re: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF >> >> >> On Jan 12, 2012, at 10:08 PM, Jonathan Wilkes wrote: >> >>> - Original Message - >>> From: Hans-Christoph Steiner To: Jonathan Wilkes Cc: Max ; pd list >> ; Ben Baker-Smith Sent: Thursday, January 12, 2012 8:50 PM Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote: > - Original Message - >> From: Max >> To: Jonathan Wilkes >> Cc: Richie Cyngler ; pd list ; Ben Baker-Smith >> Sent: Wednesday, January 11, 2012 7:09 AM >> Subject: Re: [PD] no pd?? WTF >> >> And that's not the end of the vicious cycle. >> Students who saved their money to buy a Max license are often >> unwilling to >> accept that their work could have been done as easy in Pd, and sometimes even >> better and/or easier. > > If you think of free > software as an ethical issue like I do and are talking about free >> programs that have a > proprietary alternative, there is still an important division >> between those programs that are > free and superior to their proprietary counterparts on practical >> grounds, and those that > don't have the same feature set as their proprietary >> counterparts (but are still quite good). > > In terms of ease of patching, Pd is clearly in the latter camp-- >> Max has infinite undo, a > "Tidy Up" that actually _does_ something useful, and a >> set of externals that allows to make > multiple connections at once and lots of other shortcuts (maybe >> these are part of the core now, > I'm not sure). Plus tooltips, anchors to resize >> guis/boxes/messages, and probably lots of > other things that make patching easier. > > I use Pd and free software (almost) exclusively, but we should be >> clear about which features > are available and which are not. Excellent point. Speaking of, is your tooltips patch fully functional in Pd-extended >> 0.43? I believe it is included, right? It would be great to ship with that >> working. >>> >>> There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s >> pd-this-canvas.pd] >>> the label doesn't get the right width. I tried using the >> <> virtual event and it didn't >>> work, and then I think you said that the patch should be finished drawing >> before <> >>> happens. >>> >>> I could just use after idle or update idletasks but those are heavily >> critiqued on the tcl wiki... >> >> 'update' is bad news, but 'after idle' is fine. It just might >> lead to tricky bugs since things will not necessarily execute in the order >> you >> might think. > > The "tricky bugs" warning was what made me not want to use 'after idle'. I > think > in another thread you agreed that <> should get triggered after the > patch is drawn, so a quick and dirty solution would put 'after idle' right > before > the <> virtual event in the relevant proc (with a comment that this > isn't > the best solution). If that sounds like a bad idea, then the tooltips patch > shouldn't > be included until <> works correctly. > > Unless there's another solution I'm not thinking of... Fixing <> is probably a bigger thing than I can manage for the Pd-extended 0.43 release, but patches are welcome. So the question of the moment is: are the tooltips usable enough to leave them in? Do they cause any problems? .hc "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
- Original Message - > From: Hans-Christoph Steiner > To: Jonathan Wilkes > Cc: Max ; pd list ; Ben > Baker-Smith > Sent: Thursday, January 12, 2012 11:20 PM > Subject: Re: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF > > > On Jan 12, 2012, at 10:08 PM, Jonathan Wilkes wrote: > >> - Original Message - >> >>> From: Hans-Christoph Steiner >>> To: Jonathan Wilkes >>> Cc: Max ; pd list > ; Ben Baker-Smith >>> Sent: Thursday, January 12, 2012 8:50 PM >>> Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF >>> >>> >>> On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote: >>> - Original Message - > From: Max > To: Jonathan Wilkes > Cc: Richie Cyngler ; pd list >>> ; Ben Baker-Smith > Sent: Wednesday, January 11, 2012 7:09 AM > Subject: Re: [PD] no pd?? WTF > > And that's not the end of the vicious cycle. > Students who saved their money to buy a Max license are often > unwilling >>> to > accept that their work could have been done as easy in Pd, and >>> sometimes even > better and/or easier. If you think of free software as an ethical issue like I do and are talking about free > programs >>> that have a proprietary alternative, there is still an important division > between those >>> programs that are free and superior to their proprietary counterparts on practical > grounds, >>> and those that don't have the same feature set as their proprietary > counterparts (but >>> are still quite good). In terms of ease of patching, Pd is clearly in the latter camp-- > Max has >>> infinite undo, a "Tidy Up" that actually _does_ something useful, and a > set of >>> externals that allows to make multiple connections at once and lots of other shortcuts (maybe > these are >>> part of the core now, I'm not sure). Plus tooltips, anchors to resize > guis/boxes/messages, >>> and probably lots of other things that make patching easier. I use Pd and free software (almost) exclusively, but we should be > clear >>> about which features are available and which are not. >>> >>> Excellent point. >>> >>> Speaking of, is your tooltips patch fully functional in Pd-extended > 0.43? I >>> believe it is included, right? It would be great to ship with that > working. >> >> There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s > pd-this-canvas.pd] >> the label doesn't get the right width. I tried using the > <> virtual event and it didn't >> work, and then I think you said that the patch should be finished drawing > before <> >> happens. >> >> I could just use after idle or update idletasks but those are heavily > critiqued on the tcl wiki... > > 'update' is bad news, but 'after idle' is fine. It just might > lead to tricky bugs since things will not necessarily execute in the order > you > might think. The "tricky bugs" warning was what made me not want to use 'after idle'. I think in another thread you agreed that <> should get triggered after the patch is drawn, so a quick and dirty solution would put 'after idle' right before the <> virtual event in the relevant proc (with a comment that this isn't the best solution). If that sounds like a bad idea, then the tooltips patch shouldn't be included until <> works correctly. Unless there's another solution I'm not thinking of... -Jonathan > > .hc > > > > As we enjoy great advantages from inventions of others, we should be glad of > an > opportunity to serve others by any invention of ours; and this we should do > freely and generously. - Benjamin Franklin > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 10:08 PM, Jonathan Wilkes wrote: > - Original Message - > >> From: Hans-Christoph Steiner >> To: Jonathan Wilkes >> Cc: Max ; pd list ; Ben >> Baker-Smith >> Sent: Thursday, January 12, 2012 8:50 PM >> Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF >> >> >> On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote: >> >>> - Original Message - From: Max To: Jonathan Wilkes Cc: Richie Cyngler ; pd list >> ; Ben Baker-Smith Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling >> to accept that their work could have been done as easy in Pd, and >> sometimes even better and/or easier. >>> >>> If you think of free >>> software as an ethical issue like I do and are talking about free programs >> that have a >>> proprietary alternative, there is still an important division between those >> programs that are >>> free and superior to their proprietary counterparts on practical grounds, >> and those that >>> don't have the same feature set as their proprietary counterparts (but >> are still quite good). >>> >>> In terms of ease of patching, Pd is clearly in the latter camp-- Max has >> infinite undo, a >>> "Tidy Up" that actually _does_ something useful, and a set of >> externals that allows to make >>> multiple connections at once and lots of other shortcuts (maybe these are >> part of the core now, >>> I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages, >> and probably lots of >>> other things that make patching easier. >>> >>> I use Pd and free software (almost) exclusively, but we should be clear >> about which features >>> are available and which are not. >> >> Excellent point. >> >> Speaking of, is your tooltips patch fully functional in Pd-extended 0.43? I >> believe it is included, right? It would be great to ship with that working. > > There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s > pd-this-canvas.pd] > the label doesn't get the right width. I tried using the <> virtual > event and it didn't > work, and then I think you said that the patch should be finished drawing > before <> > happens. > > I could just use after idle or update idletasks but those are heavily > critiqued on the tcl wiki... 'update' is bad news, but 'after idle' is fine. It just might lead to tricky bugs since things will not necessarily execute in the order you might think. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
- Original Message - > From: Hans-Christoph Steiner > To: Jonathan Wilkes > Cc: Max ; pd list ; Ben > Baker-Smith > Sent: Thursday, January 12, 2012 8:50 PM > Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF > > > On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote: > >> - Original Message - >>> From: Max >>> To: Jonathan Wilkes >>> Cc: Richie Cyngler ; pd list > ; Ben Baker-Smith >>> Sent: Wednesday, January 11, 2012 7:09 AM >>> Subject: Re: [PD] no pd?? WTF >>> >>> And that's not the end of the vicious cycle. >>> Students who saved their money to buy a Max license are often unwilling > to >>> accept that their work could have been done as easy in Pd, and > sometimes even >>> better and/or easier. >> >> If you think of free >> software as an ethical issue like I do and are talking about free programs > that have a >> proprietary alternative, there is still an important division between those > programs that are >> free and superior to their proprietary counterparts on practical grounds, > and those that >> don't have the same feature set as their proprietary counterparts (but > are still quite good). >> >> In terms of ease of patching, Pd is clearly in the latter camp-- Max has > infinite undo, a >> "Tidy Up" that actually _does_ something useful, and a set of > externals that allows to make >> multiple connections at once and lots of other shortcuts (maybe these are > part of the core now, >> I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages, > and probably lots of >> other things that make patching easier. >> >> I use Pd and free software (almost) exclusively, but we should be clear > about which features >> are available and which are not. > > Excellent point. > > Speaking of, is your tooltips patch fully functional in Pd-extended 0.43? I > believe it is included, right? It would be great to ship with that working. There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s pd-this-canvas.pd] the label doesn't get the right width. I tried using the <> virtual event and it didn't work, and then I think you said that the patch should be finished drawing before <> happens. I could just use after idle or update idletasks but those are heavily critiqued on the tcl wiki... -Jonathan > > .hc > > > > > "[W]e have invented the technology to eliminate scarcity, but we are > deliberately throwing it away to benefit those who profit from scarcity." > -John Gilmore > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote: > - Original Message - >> From: Max >> To: Jonathan Wilkes >> Cc: Richie Cyngler ; pd list ; Ben >> Baker-Smith >> Sent: Wednesday, January 11, 2012 7:09 AM >> Subject: Re: [PD] no pd?? WTF >> >> And that's not the end of the vicious cycle. >> Students who saved their money to buy a Max license are often unwilling to >> accept that their work could have been done as easy in Pd, and sometimes >> even >> better and/or easier. > > If you think of free > software as an ethical issue like I do and are talking about free programs > that have a > proprietary alternative, there is still an important division between those > programs that are > free and superior to their proprietary counterparts on practical grounds, and > those that > don't have the same feature set as their proprietary counterparts (but are > still quite good). > > In terms of ease of patching, Pd is clearly in the latter camp-- Max has > infinite undo, a > "Tidy Up" that actually _does_ something useful, and a set of externals that > allows to make > multiple connections at once and lots of other shortcuts (maybe these are > part of the core now, > I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages, and > probably lots of > other things that make patching easier. > > I use Pd and free software (almost) exclusively, but we should be clear about > which features > are available and which are not. Excellent point. Speaking of, is your tooltips patch fully functional in Pd-extended 0.43? I believe it is included, right? It would be great to ship with that working. .hc "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
