[PD] enhance pd-extended with pd-l2ork featues ?

[Roman Haefeli]

On Son, 2013-01-20 at 11:42 -0500, Ivica Ico Bukvic wrote:
> > Most of my GOP-abstractions are broken in pd-l2ork, because I often fit
> > the GUI objects exactly into the GOP area. However, in pd-l2ork those
> > iemguis don't show up, because of two reasons:
> > * Compared the pd/pd-extended, the position of the iemguis is shifted by
> > 2px to the right. This means they overlap the GOP area in pd-l2ork.
> > * In pd-l2ork, iemguis aren't shown in the parent canvas when they
> > perfectly fit into the GOP area. Only when there is a padding area of
> > 3px width on the right side, they appear in the parent. Fitting iemguis
> > perfectly into GOPs is not supported in pd-l2ork.
> 
> They fit perfectly fine. It is that the original iemgui are
> inconsistent in positioning iemgui objects. Try auto-patching in
> regular pd various iemgui objects one below the other and you'll see
> how off they are. In other words, the regular pd lies about its x and
> sometimes y coordinates. It is just that this has been the case
> forever in pd that you accepted it as a norm. Granted, I completely
> understand why you would not want to mess with this but if you did (I
> went through this a couple months ago retrofitting everything I ever
> made for pd-l2ork and it was no fun), you'd end up with something that
> will be a lot more transportable over the long run than something that
> essentially compensates for a bug.

Ok, I see what you mean. When I align a hslider to a GOP area positioned
at the coordinates 20 20, the hslider has the coordinates 23 20. It is
wrong in Pd and Pd-extended. However, I don't quite see the advantage of
fixing this, as it breaks portability of patches.  


> > I tried other stuff of mine and stumbled on some issues, though I didn't
> > invest much into finding out what the causes are. One patch does not the
> > connect to the server. It turned out, that the protocol test fails in
> > pd-l2ork for some reason. When it loaded a certain abstraction, pd-l2ork
> > startet to fully use the CPU and filling up the RAM until I killed the
> > process (this is reproducible).
> 
> It would be great to see what this is so that I can trace it down.

If you want to have a look on your own, open chat.pd from netpd and
click the 'unpatch' button. Here, on Ubuntu 12.04.1 with pd-l2ork from
yesterday it immediately starts eating memory.
You can download it from here:
https://github.com/reduzent/netpd2/archive/master.zip

> > 
> > Symbolboxes' support for german umlaute is broken. When typing 'blä'
> > into:
> > 
> > [symbol\
> > |
> > [print]
> > 
> > an empty line is printed to the console window (not even the 'print:'
> > prefix shows up). messageboxes and other object classes seem not
> > affected by this. [symbol blä(-[print] works fine.
> 
> Can you send a patch so that this can be tested out?

Actually no, since it doesn't trigger the problem when I save the symbol
containing non-ASCII characters in the patch. You really have to type
them in order to trigger the issue. 

To illustrate the problem, I typed 'äöü' to a symbol box and save the
result with [textfile]. I did the same with a message box. The results
are indeed different. Here the content of the files (in hex):

* from symbol box:
  E4 F6 FC 3B  0A

* from message box:
  C3 A4 C3 B6  C3 BC 3B 0A

Obviously, symbol box writes in latin1 encoding, while message box (and
probably the rest of Pd-l2ork) writes in proper utf-8. BTW, my locale is
set to LANG=en_US.UTF-8.


> > pd-l2ork certainly is in good shape, but calling it bug-free seems a bit
> > sensationalistic.
> 
> Indeed, claiming that every single 3rd-party external works is
> ridiculous and that is not what I've been referring to. I've been
> referring to the core (and I don't consider internationalization core
> yet since it is still a moving target both on l2ork and other
> iterations).

I didn't mention any issues with internationalization. If you think that
my problem with German umlaute has something to do with
internationalization, we disagree. I would consider proper UTF-8 support
a core feature. 

IMHO, even claiming only the core to be bug-free is a bit bold. That
said, doubting the bug-freeness of your work doesn't mean to make you or
Pd-l2ork appear in a bad light at all.

Roman