Re: [PD] list item picker widget
Hi, here is menu by Pierre Guillot: https://forum.pdpatchrepo.info/topic/10867/a-menu-made-with-the-graphical-data-structures. Cheers Ingo On 11.02.21 13:37, Roman Haefeli wrote: > Hi > > I'm curious what types of list item pickers widgets exist in Pd realm. > I imagine a widget that lets you select an item from a arbitrary length > list that only displays the picked item and thus uses little screen > estate when not in active use. > > I don't know any but the kludgy ones I made myself. I'd be specially > interested in patched ones as opposed to externals, though externals > would be interesting to know about, too. Maybe there is something made > of data structures? > > > Roman > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
I mean there is no way to detect hovering or a mouse key release. I think there's [mousestate] or maybe something in one of the iem libraries (?), and if I remember correctly, structs can declare if a mouse is over them. I don't know how to make a struct report mouse hovering. If it is possible, can you elaborate this? probably I was dreaming, or it's something I suggested privately to Miller, but it's not there. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Fri, 2021-02-12 at 09:31 +0100, João Pais wrote: > > > I mean there is no way to detect > > hovering or a mouse key release. > > I think there's [mousestate] or maybe something in one of the iem > libraries (?), and if I remember correctly, structs can declare if a > mouse is over them. I don't know how to make a struct report mouse hovering. If it is possible, can you elaborate this? Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget - [declare] lib paths
In some recent and proposed updates to declare and the loader, the movement is toward being able to load both compiled and abstraction libraries without having to use both -lib & -path, but we are not there yet: https://github.com/pure-data/pure-data/pull/440 <https://github.com/pure-data/pure-data/pull/440> In many ways, -stdpath and -stdlib is legacy but of course will most likely not be removed or explicitly deprecated unless there is a real need. It is however highly encouraged *not* to use them, ie. no longer having users manage stuff inside the macOS Pd .app bundle. In your case with netpd and bundled resources, then I imagine they are still quite useful. :) > On Feb 16, 2021, at 2:37 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 2 > Date: Tue, 16 Feb 2021 14:37:19 +0100 > From: Roman Haefeli mailto:reduz...@gmail.com>> > To: Pd-List mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] list item picker widget - [declare] lib paths > Message-ID: <mailto:f592ac96dd0de66fa4679b609eb2e7096e9e2864.ca...@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Thanks for the full picture, Dan. > > I guess the main point is that when Pd users go along the defaults, > they need patches to use -path and -lib. > > Even more, -lib and -path _also_ work for stuff installed in any of the > standard search paths like /extra. Assuming that people use a > recent version of Pd, there can be no harm in using -lib and -path. > They cover more use cases. Thus, I'd say using -lib and -path should be > considered the canonical way of loading libraries. > > Roman Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget - [declare] lib paths
Thanks for the full picture, Dan. I guess the main point is that when Pd users go along the defaults, they need patches to use -path and -lib. Even more, -lib and -path _also_ work for stuff installed in any of the standard search paths like /extra. Assuming that people use a recent version of Pd, there can be no harm in using -lib and -path. They cover more use cases. Thus, I'd say using -lib and -path should be considered the canonical way of loading libraries. Roman On Tue, 2021-02-16 at 14:09 +0100, Dan Wilcox wrote: > I don't know if this is purely "canonical", but this is how it works: > > The Document's path was added to provide a default location for deken > to download externals, ~/Documents/Pd. It is purely optional but > builds on the existing search path functionality. The idea is help > beginners manage search paths and move away from installing stuff to > extra or ~/pd-externals, etc. It is implemented as a gui plugin which > is included with Pd. The source is in the Pd tcl folder. > > If the Documents path is used, an "externals" subfolder is created > and added to the search paths, so installing something via deken, > should only require [declare] -path and/or -lib for usage. Basically, > if an abstraction-only library is in ~/Documents/Pd/externals ala > ~/Documents/Pd/externals/extname, then it should be found with > [declare -path extname] assuming the user is using the Documents path > *and* has installed the "extname" external to the default location > via deken. You can, of course, manually add external folders as well. > > Additionally, you can restrict declare to only look in relative paths > when adding folders relative to a patch by prepending . or .. to the > beginning, ie [declare -path ./extname] will only look for a folder > named "extname" in the same folder as the patch, without looking in > any of the user or "standard" search paths. > > > On Feb 16, 2021, at 12:00 PM, pd-list-requ...@lists.iem.at wrote: > > > > Message: 2 > > Date: Tue, 16 Feb 2021 10:33:52 +0100 > > From: João Pais > > To: pd-list@lists.iem.at > > Subject: Re: [PD] list item picker widget - [declare] lib paths > > Message-ID: > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > > > I'm not quite sure what the canonical declaration style is, > > > > -lib/- > > > > path or -stdlib/-stdpath. I guess the former will work better > > > > for > > > > Pd's own default setup. > > > I should say this is true since 0.50 or so. Before that, > > > -stdlib/- > > > stdpath was the common thing to use. > > What would be then the canonical now, no "-std"? I can change that > > easily in my patches, but would be good to have it confirmed. > > > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget - [declare] lib paths
I don't know if this is purely "canonical", but this is how it works: The Document's path was added to provide a default location for deken to download externals, ~/Documents/Pd. It is purely optional but builds on the existing search path functionality. The idea is help beginners manage search paths and move away from installing stuff to extra or ~/pd-externals, etc. It is implemented as a gui plugin which is included with Pd. The source is in the Pd tcl folder. If the Documents path is used, an "externals" subfolder is created and added to the search paths, so installing something via deken, should only require [declare] -path and/or -lib for usage. Basically, if an abstraction-only library is in ~/Documents/Pd/externals ala ~/Documents/Pd/externals/extname, then it should be found with [declare -path extname] assuming the user is using the Documents path *and* has installed the "extname" external to the default location via deken. You can, of course, manually add external folders as well. Additionally, you can restrict declare to only look in relative paths when adding folders relative to a patch by prepending . or .. to the beginning, ie [declare -path ./extname] will only look for a folder named "extname" in the same folder as the patch, without looking in any of the user or "standard" search paths. > On Feb 16, 2021, at 12:00 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 2 > Date: Tue, 16 Feb 2021 10:33:52 +0100 > From: João Pais mailto:jmmmp...@gmail.com>> > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] list item picker widget - [declare] lib paths > Message-ID: <mailto:e362b696-301a-ee0d-e4d9-a5db6ee32...@gmail.com>> > Content-Type: text/plain; charset=utf-8; format=flowed > >>> I'm not quite sure what the canonical declaration style is, -lib/- >>> path or -stdlib/-stdpath. I guess the former will work better for >>> Pd's own default setup. >> I should say this is true since 0.50 or so. Before that, -stdlib/- >> stdpath was the common thing to use. > What would be then the canonical now, no "-std"? I can change that > easily in my patches, but would be good to have it confirmed. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget - [declare] lib paths
I'm not quite sure what the canonical declaration style is, -lib/- path or -stdlib/-stdpath. I guess the former will work better for Pd's own default setup. I should say this is true since 0.50 or so. Before that, -stdlib/- stdpath was the common thing to use. What would be then the canonical now, no "-std"? I can change that easily in my patches, but would be good to have it confirmed. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
Em ter., 16 de fev. de 2021 às 00:17, Alexandre Torres Porres < por...@gmail.com> escreveu: > what I see it happens now is that both need to to click back on the pd > canvas window before you can click on bangs and stuff. > for the record, I didn't see this issue with ceammc's [ui.menu] > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
Em seg., 15 de fev. de 2021 às 20:27, Roman Haefeli escreveu: > On Sat, 2021-02-13 at 19:47 -0300, Alexandre Torres Porres wrote: > > what about the compiled externals? > > I only tried [flatgui/popup] and [tof/menubutton]. The former looks tk- > ish and also expands over the patch canvas, which is good for large > item lists. It's not very customizable, though. [menubutton] works > really well and is quite customizable, but not fonzsize. Both do not > suffer from not receiving clicks when overlapping other GUI widgets. > what I see it happens now is that both need to to click back on the pd canvas window before you can click on bangs and stuff. > > However, I still had to cook my own. There are too many little details > regarding customization and behavior and most likely future wishes... yeah, I wanna make my own too, that is more flexible/customizable and that fixes issues from these other 2 compiled externals (and now I found this new issue). Anyway, hopefully I can meet your needs :) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Sat, 2021-02-13 at 19:47 -0300, Alexandre Torres Porres wrote: > what about the compiled externals? I only tried [flatgui/popup] and [tof/menubutton]. The former looks tk- ish and also expands over the patch canvas, which is good for large item lists. It's not very customizable, though. [menubutton] works really well and is quite customizable, but not fonzsize. Both do not suffer from not receiving clicks when overlapping other GUI widgets. However, I still had to cook my own. There are too many little details regarding customization and behavior and most likely future wishes... https://netpd.org/~roman/tmp/netpd-gui-dropdown.zip Roman > signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Sun, 2021-02-14 at 21:59 +0100, Roman Haefeli wrote: > > I'm not quite sure what the canonical declaration style is, -lib/- > path or -stdlib/-stdpath. I guess the former will work better for > Pd's own default setup. I should say this is true since 0.50 or so. Before that, -stdlib/- stdpath was the common thing to use. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Sun, 2021-02-14 at 11:21 +0100, João Pais wrote: > > > > > > For [jp.menu] to load properly, I had to [declare -path ggee -path > > list-abs]. I think that could be done within [jp.menu] itself. > > Strange, that should be necessary in my computer as well. I'll have > to > check it. Ok, I should have checked better. [jp.menu] indeed [declare]s everything, just not in the top-most patch. So my report was bogus. Sorry for that. Now I understand why it didn't load for me while it does for you. I adapted my Pd setup to new school and download Deken packages to $HOME/Pd/externals which was automatically created and added to Pd's search path. This works with [declare -path] and [declare -lib] style declares. However, [jp.menu] uses [declare -stdlib zexy -stdpath ggee -stdpath list-abs] which works if you have the externals installed in /extra. That's probably what you do, so it works for you. I'm not quite sure what the canonical declaration style is, -lib|-path or -stdlib|-stdpath. I guess the former will work better for Pd's own default setup. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
you mean to show the dropdown under the selected item, probably repeating it? Is there a "common" software where I could see the behaviour? Is there a common software where I don't see that behaviour? https://en.wikipedia.org/wiki/Drop-down_list I don't think it is such a big deal that we need to find the "truth" here, but I thought listing selectable items _below_ the selected item is much more common. Cannot prove that, though. I'll add it to the list, but I'm not sure how soon I'll be able to get to it. I was going to open an issue about not using any [declare]s, but I couldn't find a public repo for jmmmp. Is there one? I don't think so, there is so few feedback that I assumed basically I do these only for me. How can you know if people cannot post issues? My contact is in all patches and help files, it's not that hard. I can try to make one. You don't have to, just because of me. Since jmmmp is available through Deken, people might want to report issues. Ask yourself if you want that or not. I think whatever you decide is fine. It's not a bad idea and it isn't hard, so I can try to add it - the next version should soon be out, I'm almost finished adapting Landini to Pd. Which declare issue? I imagine I only used other jmmmp objects, but I thought that they would all open automatically. No, they don't. Also, the README mentions that other libraries are involved. However, the objects in the jmmmp library do not declare what they actually use. For [jp.menu] to load properly, I had to [declare -path ggee -path list-abs]. I think that could be done within [jp.menu] itself. Strange, that should be necessary in my computer as well. I'll have to check it. The most complex abstractions use the simpler ones such as [f+], so it would be better not to split the objects (or to be careful with them). I hear you. I didn't just copy something from jmmmp expecting it work out of its context. However, it is my understanding that a library should declare its own dependencies and not expect a user of this library to do it. I do that always, or it wouldn't work on my own system. But something went amiss here. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
yes, that is a problem. It can be minimized according to the creation order, but from empiric experience in my clicktracker I have 2 dropdown menus very near to other menus and gui elements, which don't get clicked. Somehow that works fine there. I could try to find out why and add it to the help patch. I think when jp.menu was launched, someone suggested a global switch, so that it assures all other menus stay closed when one is open. And one problem will always be that the programmer must reserve space in the canvas for a full expanded menu - unless he/she does a dynamic canvas, based on the menu's dimensions and list size. I found an important difference between [guilla/dropdownMenu] and [jmmmp/jp.menu]. The former uses sliders as buttons while the latter uses scalars of data structures. The problem with sliders is that (like any other regular GUI widget in Pd) the lowest one gets the click if there is an overlap. When [dropdownMenu] is placed right on top of other GUI stuff, in expanded view you can either not click the items or you cannot see them, depending on which order [dropdownMenu] was created relative to the other stuff. Thus, [dropdownMenu] doesn't help in saving screen estate. It seems with expanded view of [jp.menu] covering other stuff, you can still click the listed items, though the widgets below gets the click, too. It's not ideal, but one can at least "protect" other stuff by registering whether [jp.menu] is expanded or not. It turns out it's a science to get this right. Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and accou ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
what about the compiled externals? Em sáb., 13 de fev. de 2021 às 17:56, Roman Haefeli escreveu: > On Thu, 2021-02-11 at 15:05 -0300, Alexandre Torres Porres wrote: > > If you want a vanilla dropdown, Henri made one here > > https://github.com/HenriAugusto/guilla > > I found an important difference between [guilla/dropdownMenu] and > [jmmmp/jp.menu]. The former uses sliders as buttons while the latter > uses scalars of data structures. The problem with sliders is that (like > any other regular GUI widget in Pd) the lowest one gets the click if > there is an overlap. When [dropdownMenu] is placed right on top of > other GUI stuff, in expanded view you can either not click the items or > you cannot see them, depending on which order [dropdownMenu] was > created relative to the other stuff. Thus, [dropdownMenu] doesn't help > in saving screen estate. > > It seems with expanded view of [jp.menu] covering other stuff, you can > still click the listed items, though the widgets below gets the click, > too. It's not ideal, but one can at least "protect" other stuff by > registering whether [jp.menu] is expanded or not. > > It turns out it's a science to get this right. > > Roman > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Thu, 2021-02-11 at 15:05 -0300, Alexandre Torres Porres wrote: > If you want a vanilla dropdown, Henri made one here > https://github.com/HenriAugusto/guilla I found an important difference between [guilla/dropdownMenu] and [jmmmp/jp.menu]. The former uses sliders as buttons while the latter uses scalars of data structures. The problem with sliders is that (like any other regular GUI widget in Pd) the lowest one gets the click if there is an overlap. When [dropdownMenu] is placed right on top of other GUI stuff, in expanded view you can either not click the items or you cannot see them, depending on which order [dropdownMenu] was created relative to the other stuff. Thus, [dropdownMenu] doesn't help in saving screen estate. It seems with expanded view of [jp.menu] covering other stuff, you can still click the listed items, though the widgets below gets the click, too. It's not ideal, but one can at least "protect" other stuff by registering whether [jp.menu] is expanded or not. It turns out it's a science to get this right. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Fri, 2021-02-12 at 09:44 +0100, João Pais wrote: > > > you mean something like [jmmmp/jp.menu]? > > Exactly. Thanks for the pointer. That's definitely what I was > > looking > > for. Picking something can be done really quick, which is nice. One > > small caveat: I personally find it confusing, when the drop-down > > covers > > the selected item. I'd place the drop-down below the selected item, > > so > > that selected item is always shown. Maybe it's just a matter of > > taste? > > you mean to show the dropdown under the selected item, probably > repeating it? Is there a "common" software where I could see the > behaviour? Is there a common software where I don't see that behaviour? https://en.wikipedia.org/wiki/Drop-down_list I don't think it is such a big deal that we need to find the "truth" here, but I thought listing selectable items _below_ the selected item is much more common. Cannot prove that, though. > > I was going to open an issue about not using any [declare]s, but I > > couldn't find a public repo for jmmmp. Is there one? > > I don't think so, there is so few feedback that I assumed basically I > do > these only for me. How can you know if people cannot post issues? > I can try to make one. You don't have to, just because of me. Since jmmmp is available through Deken, people might want to report issues. Ask yourself if you want that or not. I think whatever you decide is fine. > Which declare issue? I imagine I only used other jmmmp objects, but > I > thought that they would all open automatically. No, they don't. Also, the README mentions that other libraries are involved. However, the objects in the jmmmp library do not declare what they actually use. For [jp.menu] to load properly, I had to [declare -path ggee -path list-abs]. I think that could be done within [jp.menu] itself. > The most complex > abstractions use the simpler ones such as [f+], so it would be > better > not to split the objects (or to be careful with them). I hear you. I didn't just copy something from jmmmp expecting it work out of its context. However, it is my understanding that a library should declare its own dependencies and not expect a user of this library to do it. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
you mean something like [jmmmp/jp.menu]? Exactly. Thanks for the pointer. That's definitely what I was looking for. Picking something can be done really quick, which is nice. One small caveat: I personally find it confusing, when the drop-down covers the selected item. I'd place the drop-down below the selected item, so that selected item is always shown. Maybe it's just a matter of taste? you mean to show the dropdown under the selected item, probably repeating it? Is there a "common" software where I could see the behaviour? I was going to open an issue about not using any [declare]s, but I couldn't find a public repo for jmmmp. Is there one? I don't think so, there is so few feedback that I assumed basically I do these only for me. I can try to make one. Which declare issue? I imagine I only used other jmmmp objects, but I thought that they would all open automatically. The most complex abstractions use the simpler ones such as [f+], so it would be better not to split the objects (or to be careful with them). ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
It's possible to build one with data structures. There may be one from me or others on the pd forum. But it's really a pain to build. I'm not even so worried about the pain of building, but about how you can make something that feels good and intuitive to use given the limited HID data you get from Pd. I mean there is no way to detect hovering or a mouse key release. I made menu widgets that required the user to keep the mouse key pressed while dragging, thus scrolling through the list of available items to pick. Number boxes and sliders work also with dragging. Nowadays, I'm starting to believe that dragging with mouse key pressed is not an ergonomic action and I'm going to avoid it whenever possible. Both, [jp.menu] and [dropDownMenu], do the selection with two clicks. I think that is the better approach. I think there's [mousestate] or maybe something in one of the iem libraries (?), and if I remember correctly, structs can declare if a mouse is over them. But yes, there are very few options, and a solution using the gui's own possibilities would surely be better. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
Em qui., 11 de fev. de 2021 às 21:04, Alexandre Torres Porres < por...@gmail.com> escreveu: > Maybe ceammc has one as it has an unbeatable/extraordinary GUI pack > yeah, ui.menu :) > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
Em qui., 11 de fev. de 2021 às 17:47, Roman Haefeli escreveu: > On Thu, 2021-02-11 at 15:05 -0300, Alexandre Torres Porres wrote: > > If you want a vanilla dropdown, Henri made one here > > https://github.com/HenriAugusto/guilla > > Cool. That's also a nice one. Thanks for mentioning. It doesn't even > use data structures, just dynamically resized GOP. > > BTW, the patching inside is a piece of art (Also, I like how > it makes good use of UTF-8 symbols). > I haven't seen it, but I agree it's a piece of art and that it looks like magic :) As for compiled externals, the known ones from extended era are flatgui/popup and tof/menubutton, not sure if there are others out there. Maybe ceammc has one as it has an unbeatable/extraordinary GUI pack I have it on my infinite to do list providing yet another one for ELSE. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Thu, 2021-02-11 at 15:05 -0300, Alexandre Torres Porres wrote: > If you want a vanilla dropdown, Henri made one here > https://github.com/HenriAugusto/guilla Cool. That's also a nice one. Thanks for mentioning. It doesn't even use data structures, just dynamically resized GOP. BTW, the patching inside is a piece of art (Also, I like how it makes good use of UTF-8 symbols). Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Thu, 2021-02-11 at 19:01 +0100, João Pais wrote: > you mean something like [jmmmp/jp.menu]? Exactly. Thanks for the pointer. That's definitely what I was looking for. Picking something can be done really quick, which is nice. One small caveat: I personally find it confusing, when the drop-down covers the selected item. I'd place the drop-down below the selected item, so that selected item is always shown. Maybe it's just a matter of taste? I was going to open an issue about not using any [declare]s, but I couldn't find a public repo for jmmmp. Is there one? Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
On Thu, 2021-02-11 at 16:51 +, Jonathan Wilkes wrote: > It's possible to build one with data structures. There may be one > from me or others on the pd forum. But it's really a pain to build. I'm not even so worried about the pain of building, but about how you can make something that feels good and intuitive to use given the limited HID data you get from Pd. I mean there is no way to detect hovering or a mouse key release. I made menu widgets that required the user to keep the mouse key pressed while dragging, thus scrolling through the list of available items to pick. Number boxes and sliders work also with dragging. Nowadays, I'm starting to believe that dragging with mouse key pressed is not an ergonomic action and I'm going to avoid it whenever possible. Both, [jp.menu] and [dropDownMenu], do the selection with two clicks. I think that is the better approach. > In Purr Data I just made a core object "dropdown" built on the same > simple display that an atom box has. Thanks for the pointer. I certainly will try it out when exploring Purr Data the next time. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
you mean something like [jmmmp/jp.menu]? Or to split a list horizontally through a gui? It's possible to build one with data structures. There may be one from me or others on the pd forum. But it's really a pain to build. In Purr Data I just made a core object "dropdown" built on the same simple display that an atom box has. Best, Jonathan On Thursday, February 11, 2021, 7:46:02 AM EST, Roman Haefeli wrote: Hi I'm curious what types of list item pickers widgets exist in Pd realm. I imagine a widget that lets you select an item from a arbitrary length list that only displays the picked item and thus uses little screen estate when not in active use. I don't know any but the kludgy ones I made myself. I'd be specially interested in patched ones as opposed to externals, though externals would be interesting to know about, too. Maybe there is something made of data structures? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
If you want a vanilla dropdown, Henri made one here https://github.com/HenriAugusto/guilla Em qui., 11 de fev. de 2021 às 14:05, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> escreveu: > It's possible to build one with data structures. There may be one from me > or others on the pd forum. But it's really a pain to build. > > In Purr Data I just made a core object "dropdown" built on the same simple > display that an atom box has. > > Best, > Jonathan > > On Thursday, February 11, 2021, 7:46:02 AM EST, Roman Haefeli < > reduz...@gmail.com> wrote: > > > Hi > > I'm curious what types of list item pickers widgets exist in Pd realm. > I imagine a widget that lets you select an item from a arbitrary length > list that only displays the picked item and thus uses little screen > estate when not in active use. > > I don't know any but the kludgy ones I made myself. I'd be specially > interested in patched ones as opposed to externals, though externals > would be interesting to know about, too. Maybe there is something made > of data structures? > > > Roman > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] list item picker widget
It's possible to build one with data structures. There may be one from me or others on the pd forum. But it's really a pain to build. In Purr Data I just made a core object "dropdown" built on the same simple display that an atom box has. Best,Jonathan On Thursday, February 11, 2021, 7:46:02 AM EST, Roman Haefeli wrote: Hi I'm curious what types of list item pickers widgets exist in Pd realm. I imagine a widget that lets you select an item from a arbitrary length list that only displays the picked item and thus uses little screen estate when not in active use. I don't know any but the kludgy ones I made myself. I'd be specially interested in patched ones as opposed to externals, though externals would be interesting to know about, too. Maybe there is something made of data structures? Roman ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] list item picker widget
Hi I'm curious what types of list item pickers widgets exist in Pd realm. I imagine a widget that lets you select an item from a arbitrary length list that only displays the picked item and thus uses little screen estate when not in active use. I don't know any but the kludgy ones I made myself. I'd be specially interested in patched ones as opposed to externals, though externals would be interesting to know about, too. Maybe there is something made of data structures? Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
