--- On Thu, 11/25/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: "IOhannes m zmölnig" zmoelnig@iem.at Cc: pd-list@iem.at Date: Thursday, November 25, 2010, 7:18 PM
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.
Before you do, you should ask Miller what exactly his comments mean in:
http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&gro...
Also see:
http://sourceforge.net/tracker/index.php?func=detail&aid=2838176&gro...
- 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.
I find the orange text _very_ difficult to read.
- 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