> thanks for sharing. > a couple of very minor remarks: > - - your webpage froze firefox/iceweasel on my eeepc the first time i > accessed it; i assume this is due to the animated tagcloud. is there any > conceptual reason for maaking a navigation aid eat 100% on 2 cores?
I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else. > > once i managed to download it, i only played a few minutes with it, so.. > > - - when releasing tarballs you should get rid of the .svn folders; these > hold a copy of all files, so you could reduce the size of the unpacked > bundle to about 50% Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder. > > - - the "magnifying glass" (i think you all refer to the "Patch cord > viewer" (or "cord inspector" how i would call it) by this term), is a > very nice feature. > what i find weird is, that i can only switch to "cord viewing" when in > edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect > to switch my patch into run mode if needed Well, this is the way original Sarlo's code works, so I haven't given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly saps some of the CPU and as such one would probably not want to run it in "runtime/performance" mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well. All that said, I like your term better. > > - - the "inlet highlighting" (this looks more like a "magnifying glass" to > me) is a nice idea but it doesn't really help yet. e.g. with objects > that have more inlets then available width (e.g. [pix_info]) you still > have the same problem as before (though a bit bigger); i also think that > the magnification amount is a bit too small, but this might be due to my > very small screen size (at first i wouldn't even notice a real > difference then to the original connection cursor). it would probably be > a good idea to let the user change the amount of magnification) > Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a tooltip that reflects which inlet/outlet is selected and what it does. This was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented. I think I'll take a stab at this one soon. > - - why is the default selection color "orange/red"? is this a pd-extended > thing? for me this is very close to the error-indicating color "red" > (e.g. when an object fails to create) Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and which occurs a lot more often than the red invalid objects. That said, I will up the width on the red objects which should solve this problem. > > - - something i think is only inherited from pd-extended, but whiich makes > me shout out loud, is that when i start pd-l2ork it creates a > "pd-externals" folder in my home directory. even if i don't do anything > apart from opening! > i think this is _very_ rude. This is indeed inherited from pd-extended and I think we need to hear from Hans on this one as I certainly wish to maintain as much pd-extended compatibility as reasonably possible. Hans? Many thanks for your feedback! Best wishes, Ico _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
