[PD] deken install user experience

IOhannes m zmoelnig zmoelnig at iem.at
Wed Jun 8 14:00:20 CEST 2016


On 2016-06-08 12:09, Hans-Christoph Steiner wrote:
> 
> I'd
> like to find a little time to contribute to it, to smooth out the user

cool.
welcome back.

> 
> * hide all incompatible library version by default (e.g. hide OSX and
> Windows versions on GNU/Linux)

this is what we are currently doing.
all incompatible versions are sorted after the compatible ones, and
(more importantly) they are greyed out.
they are still selectable though.

> 
> * by default, install into user's pd externals folder without any prompt
> (~/pd-externals, etc)

hmm, well: there has been a lot of discussion on this list about which
approach should be taken.

a short (probably biased) recap (but you'll find more detailed reasoning
in the archives):
- originally, deken would try to download/install into the externals
folder (as your suggestion). it would even try to create this folder, in
case it was not there yet.
this was rejected, as many people very much dislike applications
creating folders in their home directory (~/pd-externals).
- a second iteration did the same, but without trying to create any
directories. if no writable folder was found, deken would prompt the
user for a target directory)
this was rejected because people have very different opinions about the
scope of downloaded externals (per-user, per-project, per-pd).
- a third iteration added a big button to manually set the directory
before downloading stuff (and otherwise would try the standard search
paths first).
this was rejected because it was not obvious. (which only shows that i'm
a bad UI designer)
- the fourth iteration went for simplicity and prompted the user where
to install.

currently, Pd-vanilla uses the 4th iteration, wheras deken upstream
still uses the 3rd iteration.


> 
> * add "Advanced Mode" or "Expert Mode" that shows the current user
> experience
> 
> * remember which mode the user has selected across pd starts (e.g. make
> a pref)

yes, many more things should be user-settable, not just two basic modes.
e.g.
directory-selection:
 - [ ] ask every time
 - [x] ask once per Pd process
 - [ ] choose automatically from existing search-paths
 - [ ] choose automatically, possibly creating default locations

as for search results, i was thinking about switching to a tree-view,
where only the most recent version of a found library would be shown by
default; but opening the (sub)tree, you would see all the older versions.
the wrong-arch results could be grouped together into an "incompatible"
subtree that is closed by default.

in any case: deken development is somewhat independent of puredata
itself and is occasionally merged into Pd proper.
it has it's own bug/feature tracker at [1] and we are happily accepting
merge requests and contributors.


fgmasdr
IOhannes



[1] https://github.com/pure-data/deken






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160608/20439878/attachment.sig>


More information about the Pd-list mailing list