[PD] Pd-l2ork GUI port Alpha 0

Jonathan Wilkes jancsika at yahoo.com
Fri Apr 29 22:33:13 CEST 2016




    > On Tuesday, April 12, 2016 12:03 PM, Roman Haefeli <reduzent at gmail.com> wrote:
 
> 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.

I just looked at this.  The bold font weight is _slightly_ wider.  But I had to create 
an object that spans the width of my laptop screen before the right edge of the 
text finally ate up the right margin and touched the box border.
Bigger issue is that "DejaVu Sans Mono Bold" is actually a separate font in a 
separate file.  I'm utilizing the CSS @fontface feature in order not to have to 
install the font to the OS, which is great.  But it means I'd have to package and 
ship the bold font file, just to accommodate this strange aesthetic of 
everything-is-bold-therefore-nothing-is-important.
 
However, I hate reading the arrogant "won't fix" resolution on bug reports, 
so I'll commit to addressing this issue if someone buys me a burrito.

> * 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 was just fixed in the latest update to nw.js, so it will be fixed in the 
next alpha.

> * 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.

Just an FYI-- this was due to Pd-l2ork not (yet) having the [text] object, which 
had the side-effect of causing Roman's patch to trigger an endless [until] loop.
However, I believe I'm still thrashing the layout when mapping a patch in the 
GUI, so it's definitely slower than it could be atm.
-Jonathan
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160429/b8240ecf/attachment.html>


More information about the Pd-list mailing list