On Nov 25, 2010, at 1:18 PM, Ivica Ico Bukvic wrote:
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 neededWell, 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.
I think it makes a lot of sense to only have the Cord Inspector
available during Edit Mode, like Ico said, play/run mode should not
have other things drawing on the CPU.
- 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.
There is a tooltip patch in the patch tracker from Günter Geiger. Its
a good idea, but needs to be implemented differently, without changing
the core data structures. I don't remember the details, but I think
it shouldn't be hard to do.
- 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.
Blue is the standard in all OSs I've used. But it wouldn't be hard to
make it a preference.
- 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?
Pd-extended aims to be newbie friendly. Creating this folder is one
example of that. I see no harm in Pd-extended creating this folder,
but those who don't like it rarely use Pd-extended anyway.
.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