My 2 cents:
From a beginners perspective, limiting to the latest (stable) release makes sense as a long list of various versions and tests with only some number and date in a small font / embedded in the file name to differentiate them could be very confusing. Perhaps there is a good middle ground where the option can be enabled by default but the latest, say 2-3 releases are listed with "stable" and "test" better marked? Or perhaps this is the new default behavior and the checkbox is reversed as in it becomes "Show all versions of a library"?
Don't forget that just because you get used to something, doesn't mean that's the best approach or that's the way it has to stay. I recall a few people on this list making that point about certain aspects of the GUI... :)
On Nov 28, 2021, at 4:05 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Sun, 28 Nov 2021 16:05:50 +0100 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] Pd 0.52 test 2 is out Message-ID: <2ec67a1d-1b01-98d2-d1dd-247d33d93e90@christofressi.com mailto:2ec67a1d-1b01-98d2-d1dd-247d33d93e90@christofressi.com> Content-Type: text/plain; charset="utf-8"; Format="flowed"
I think this kind of unwarned change can be really confusing, see my case here :) it's a cool option, but maybe not checked by default?
I also think that the option should be off by default. For example, let's say there is a stable "vstplugin~-0.5.2" package on Deken. Now, if I upload "vstplugin~-0.6-test" Deken would only show that and would hide the stable release...
Or should we rather stop uploading test releases to Deken?
Christof
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I'm all up for discussing how we can change things to achieve a goal.
First we had them all showing and then we chose to hid foreign architectures, right?
Back then, the idea was to highlight the native ones, this still happens when we decide to show them, foreign architecctures are greyed out.
What I also think it's confusing now is that if you decide to show foreign architectures and have that other checbox o by default, you get native options that are greyed out. It's hard to differentiate the native ones from the foreign. It's confusing.
My idea: we create a new standard for highlighting the first option. This can be shown in bold, and perhaps a different color (blue is nice, it's what links usually are colored like).
We change the behaviour of that box, and tell it to hide others that are not the latest (unchecked by default). This is not "treated" as foreign. Which means, if we have it marked and choose to show foreign, only the latest version of the foreign releases are shown.
I guess this makes sense from a design point of view.
cheers
But treating in the same was as foreign architecture (hiding it) doesn't seem clever
If the idea is to highlight the
Em dom., 28 de nov. de 2021 às 12:17, Dan Wilcox danomatika@gmail.com escreveu:
My 2 cents:
From a beginners perspective, limiting to the latest (stable) release makes sense as a long list of various versions and tests with only some number and date in a small font / embedded in the file name to differentiate them could be very confusing. Perhaps there is a good middle ground where the option can be enabled by default but the latest, say 2-3 releases are listed with "stable" and "test" better marked? Or perhaps this is the new default behavior and the checkbox is reversed as in it becomes "Show all versions of a library"?
Don't forget that just because you get used to something, doesn't mean that's the best approach or that's the way it has to stay. I recall a few people on this list making that point about certain aspects of the GUI... :)
On Nov 28, 2021, at 4:05 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Sun, 28 Nov 2021 16:05:50 +0100 From: Christof Ressi info@christofressi.com To: Pd-List pd-list@lists.iem.at Subject: Re: [PD] Pd 0.52 test 2 is out Message-ID: 2ec67a1d-1b01-98d2-d1dd-247d33d93e90@christofressi.com Content-Type: text/plain; charset="utf-8"; Format="flowed"
I think this kind of unwarned change can be really confusing, see my case here :) it's a cool option, but maybe not checked by default?
I also think that the option should be off by default. For example, let's say there is a stable "vstplugin~-0.5.2" package on Deken. Now, if I upload "vstplugin~-0.6-test" Deken would only show that and would hide the stable release...
Or should we rather stop uploading test releases to Deken?
Christof
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
On 11/28/21 16:37, Alexandre Torres Porres wrote:
I guess this makes sense from a design point of view.
thanks for all your inputs and mockups.
you can (as always) file *directed* tickets at https://github.com/pure-data/deken/issues
(but please let's not start any *discussions* there, as they quickly get out of bounds).
in any case: i think all of your suggestions (with he noteable exception of changing some default values for the available settings) are out of reach for Pd-0.52. the code changes required are simply too much for the next weeks (i hope that Pd-0.52 will be released this year or very early next year).
otoh, deken-0.7 (which has all the behaviour your noticed) has been announced more than 8 months ago. i have received feedback for the 0.7 release from various people, but i don't remember anyone raising the issues you are raising now (i'm not saying that these new issues are not valid; only that there would have been plenty of time to notice them beforehand)
cheers and happy patching.
gdsarm IOhannes
i think all of your suggestions (with he noteable exception of changing some default values for the available settings) are out of reach for Pd-0.52.
Sure enough!
I think for now the safest "solution" would be to disable _Only show the newest version of a library_ by default, so there won't be any complaints. For the next (minor) release we can think about the best "real" solution. What do you think? __
I will open a ticket about my two column search results suggestion and maybe even try a PR.
(i'm not saying that these new issues are not valid; only that there would have been plenty of time to notice them beforehand)
Yes, it's certainly the worst possible time to come up with these complaints. Actually, I did test the most recent Deken release but I didn't notice the new default values because those are stored in the Windows registry.
After reading "pd_guiprefs.tcl" I learned the following trick: exporting PD_CONFIG_DIR will force Pd to read the GUI preferences from a file and ignore the settings in the registry. Since the file doesn't exist (yet), it will start without any GUI preferences. I will do that in the future whenever I test a new Pd or Deken version.
Christof
On 28.11.2021 21:15, IOhannes m zmölnig wrote:
On 11/28/21 16:37, Alexandre Torres Porres wrote:
I guess this makes sense from a design point of view.
thanks for all your inputs and mockups.
you can (as always) file *directed* tickets at https://github.com/pure-data/deken/issues
(but please let's not start any *discussions* there, as they quickly get out of bounds).
in any case: i think all of your suggestions (with he noteable exception of changing some default values for the available settings) are out of reach for Pd-0.52. the code changes required are simply too much for the next weeks (i hope that Pd-0.52 will be released this year or very early next year).
otoh, deken-0.7 (which has all the behaviour your noticed) has been announced more than 8 months ago. i have received feedback for the 0.7 release from various people, but i don't remember anyone raising the issues you are raising now (i'm not saying that these new issues are not valid; only that there would have been plenty of time to notice them beforehand)
cheers and happy patching.
gdsarm IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On 11/28/2021 5:52 PM, Christof Ressi wrote:
exporting PD_CONFIG_DIR will force Pd to read the GUI preferences from a file and ignore the settings in the registry
How I do this?
--
Mensaje telepatico asistido por maquinas.
In the msys2 shell:
$ export PD_CONFIG_DIR=<some_path>
$ pd
Christof
On 28.11.2021 23:00, Lucas Cordiviola wrote:
On 11/28/2021 5:52 PM, Christof Ressi wrote:
exporting PD_CONFIG_DIR will force Pd to read the GUI preferences from a file and ignore the settings in the registry
How I do this?
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
"-noprefs" only works for the Pd core preferences, but *not* for the Pd GUI preferences.
On 28.11.2021 23:20, Lucas Cordiviola wrote:
Cool. Even better:
./pd -noprefs
Mensaje telepatico asistido por maquinas. On 11/28/2021 7:08 PM, Christof Ressi wrote:
$ export PD_CONFIG_DIR=<some_path> $ pd
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On 11/28/2021 7:23 PM, Christof Ressi wrote:
"-noprefs" only works for the Pd core preferences, but *not* for the Pd GUI preferences.
Yes sure. This way is for starting with no prefs at all.
$ export PD_CONFIG_DIR=<some_path> $ ./pd -noprefs
--
Mensaje telepatico asistido por maquinas.
as a long list of various versions and tests with only some number and date in a small font / embedded in the file name to differentiate them could be very confusing.
I can totally see that. Particularly, when you search for an object and the query matches several libraries, you might get a massive list of results that can indeed be overwhelming.
I think the actual problem is that all the data has to be displayed in a single list.
A much better approach would be to only show the library names in a first column, with the actual versions (and possibly more information) in a second colum, a bit like in a file browser.
Here's a very beautiful mock-up:
Christof
On 28.11.2021 16:17, Dan Wilcox wrote:
My 2 cents:
From a beginners perspective, limiting to the latest (stable) release makes sense as a long list of various versions and tests with only some number and date in a small font / embedded in the file name to differentiate them could be very confusing. Perhaps there is a good middle ground where the option can be enabled by default but the latest, say 2-3 releases are listed with "stable" and "test" better marked? Or perhaps this is the new default behavior and the checkbox is reversed as in it becomes "Show all versions of a library"?
Don't forget that just because you get used to something, doesn't mean that's the best approach or that's the way it has to stay. I recall a few people on this list making that point about certain aspects of the GUI... :)
On Nov 28, 2021, at 4:05 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Sun, 28 Nov 2021 16:05:50 +0100 From: Christof Ressi info@christofressi.com To: Pd-List pd-list@lists.iem.at Subject: Re: [PD] Pd 0.52 test 2 is out Message-ID: 2ec67a1d-1b01-98d2-d1dd-247d33d93e90@christofressi.com Content-Type: text/plain; charset="utf-8"; Format="flowed"
I think this kind of unwarned change can be really confusing, see my case here :) it's a cool option, but maybe not checked by default?
I also think that the option should be off by default. For example, let's say there is a stable "vstplugin~-0.5.2" package on Deken. Now, if I upload "vstplugin~-0.6-test" Deken would only show that and would hide the stable release...
Or should we rather stop uploading test releases to Deken?
Christof
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com