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 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.
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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
