[PD] Pd-l2ork GUI port Alpha 0

[Jonathan Wilkes]

    > On Tuesday, April 12, 2016 11:59 AM, Roman Haefeli <reduzent at gmail.com> wrote:
 

 > On Fri, 2016-04-08 at 14:38 +0000, Jonathan Wilkes via Pd-list wrote:


>> Hi list,
>> Here are some binaries to test out the alpha 0 release for the GUI
>> port of Pd-l2ork.

> Wow.. impressive work you've done and I think I'm not even remotely able
> to grasp what it meant to achieve this. I very much like its native look
> (I checked on Ubuntu 14.04). Also the GUI tab in the preferences dialog,
> very neat. And the canvas zoom is probably going to be _the_ killer
> feature with all the hi-res displays coming up.

If you have a chance, do check out doc/4.data.structures/pd-l2ork/ds-tutorialsas well.  It's still under heavy development, but I think you'll find the API allows 
you to do 2d visualizations with a lot less work than the vanilla API.  Part of 
that has to do with affine transformations, which includes zooming (well, scaling)-- 
that's why I mention it here.

> Some observations (from Ubuntu 14.04 i386):

>  * For a true vanilla experience, it'd be nice if the GUI preset
  'vanilla' would use bold fonts.

Added to tracker.  I have the feeling I didn't do this because the bold style probably 
changes the line width, which makes it a harder problem than just adding a line 
of css.  But I'll look into it.

> * I sometimes have to click on Menus twice for the selected item to show
  up. I couldn't figure out a reliable pattern. Affected entries:
  'Media->Test Audio and Midi' or 'Edit -> Preferences'
This is a bug in nw.js.  It's been reported and investigated, and will hopefully 
get fixed soon.

> * I can't load many of my patches in this nw-version of Pd-l2ork. When I
  do so, the patch canvas never appears and I get repeating messages
  'watchdog: signaling pd..' on stderr. The process 'nw' uses 100% of a
  core and I have to kill pd-l2ork. Some simple patches work fine and I
  haven't figured out a pattern of what kind of patches are affected 
  which are not. However, the behaviour of a certain patch is consistent
  (either it loads always ok or it never does so).
  UPDATE: Not true. It just takes that much time to load the patch. The 
  one I just loaded took more than 2 minutes to load.
You can see it even with the loadmeter on slower machines-- each additional 
Pd object triggers a layout recalculation, and that can result in jank.
But I think I've got a fix for it. Email me a worst-case patch and I'll test.

> What version of Pd-vanilla is this based on? Or is not related to
vanilla anymore? I stopped caring about Pd-l2ork when I figured it
contains some fixes that shifts position of iemguis around. This
renders a lot of my patches unusable because they are not displayed in
the GOP area anymore. I'd love if patches would work in both flavors,
but right now it seems as a patch author you need to decide one.
Try starting up with the "-legacy" flag and tell me if they display properly.
This is a transitional flag-- what I want to do is add a flag to t_canvas 
so that this "just works" for you and "just works" for Pd-l2ork gops going 
forward.  (And just have some simple mass import for Pd-l2ork gops 
created in the interim.)

In the meantime, let me know any of your gop abstractions that don't 
display correctly with -legacy and I'll file a bug and investigate.

> Is it correct that externals for Pd-l2ork are binary-incompatible with
externals built for Pd-vanilla? I'm just interested to know, maybe this
isn't such a huge issue, since Pd-l2ork has so many externals
pre-compiled.
Two related issues:1. I am porting gui externals manually to nw.js.  In these cases 
binary compatibility is irrelevant.2. AFAICT nobody has had sufficient interest to test whether or not 
Pd-l2ork and Vanilla are binary compatible.
So I think I'll just blithely claim they are 100% 
binary compatible.  If anybody finds otherwise, I'll file a bug.
-Jonathan


> Roman
_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160412/7ba78132/attachment.html>