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.
The problem with portability is the longer you wait the less code is actually editable. This is because more of it becomes encumbered by bugs that cannot be removed due to users' growing library of prior code they wish to use and that keeps them tied to a product that perpetuates such inconsistencies. I think this is why in great part pd development has become exponentially more complex, not because of lack of developers, per se, but because of insurmountable task of ensuring that there is no breakage of backwards compatibility, even though some of those means simply perpetuating buggy behavior. My motto is if it is a bug it needs to be fixed and the sooner this is done the better for everyone involved. How does this particular issue this matter? Due to misaligned drawing, mouse hover is mis-detected by a few pixels, so selecting and interacting with objects, or showing tooltips is out of whack. More so, autopatching is broken without a workaround pd-l2ork used to have which was an ugly hack that further obfuscated the code base. So, this is not just a usability issue, but also a maintainability issue.
If you have copious amounts of abstractions, there is always a way to build a script that would change position of all iemgui objects according to their inconsistency and this would likely save you a lot of trouble. Personally, I found it a lot easier to simply edit abstractions--while I had a fair amount of them, I still tend not to trust quickly hacked shell scripts without extensive testing which in the end seemed to me at least more time consuming than doing this simply by hand...
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
Great! Thanks for sharing. I will look into this asap. Just to make sure, the code above does not use any third-party externals, correct?
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.
Interesting. Thanks for reporting. Like I mentioned, I recently introduced *initial* UTF support which by no means meant exhaustive support. This should not be too hard to trace, though.
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.
Indeed, that statement was meant to be provocative in hope of eliciting some response, and in that effect it was more than successful. That said, my comments were not entirely unfounded--I am basing my report on a semester of bug-free use by 15 mostly non-Linux-savvy and definitely non-pd-savvy users who were unable to break it with everything they tried to throw at it, including some fairly advanced gui operations present in K12 module (like dynamic loading of images to animate the gui). Even based on all that has transpired since, the reports we've gotten so far are:
- $@ issue which IMHO is a non-issue since I don't consider this a feature I wish to advertise as a feature just yet (for exact reasons why it was brought up)
- UTF inconsistency you reported that is a genuine bug
- iemgui positioning which I would consider (IMHO) a fix, not a bug
All in all, AFAICT this leaves us with #2.
Best wishes,
Ico
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list