[L2Ork-dev] Hello, and a rough plan on how to port K12 mode for GSoC

Mon Apr 8 00:05:58 EDT 2019

On Sun, Apr 7, 2019 at 4:01 PM Coniine Dieu <coniinedieu at gmail.com> wrote:
>
> Hi Jonathan,
>
> Sorry for not getting back to you earlier--school is quite demanding. Anyways, here's my first draft of the proposal: http://tinyurl.com/shaoqian-gsoc-d1 . Please be blunt and tell me whatever problems you find there, I would really appreciate that.
>
> One thing is that I didn't elaborate much on the touchscreen part, because I don't have much insight on the best way to do it, but since it's in later this summer, I hope it won't be a big issue for now.
>
> It's a long read, I know, and thanks for your time!

Hi Shaoqian,

Excellent draft!

I only have two observations:

1. Small thing-- grammar: "but I do have dabbled in"

2. Tooltips-- in Pd-l2ork 1.0 we had an arcane system for displaying
tooltips that did a GUI->Pd->GUI roundtrip each time a tip was to be
displayed.
Pd would fetch the help patch path and send it to the GUI. Then the
GUI would open that file and parse the relevant tooltip text.

One benefit is that this leveraged pre-existing data inside Pd help
patches to display the tip. This was nice because it meant that users
could revise
the tip string without having to recompile. They could also make tips
for abstraction simplys by writing a complete help file.

This obviously meant reading a file from the filesystem for each tip.
But this was only done opportunistically. The user would hover the
mouse over
an object long enough, and only then would the help patch be opened
and parsed to obtain the relevant tip text.

If you want to create a DOM element for each tooltip when each object
gets drawn then we'll need a different way to fetch the tooltip
text than the opportunistic way used in Pd-l2ork 1.0. One possibility
would be to fetch it from the search index, and in fact there's
already a setting to
build that index at startup. At least that's the easiest thing I can think of.

Also-- I *think* the tooltips in Pd-l2ork 1.0 would display a string
for the description of the object itself when hovering the mouse over
the box text.

Hope that helps a bit. Let us know if you have any more questions
about the project idea.

Best,
Jonathan

>
> Cheers
> Shaoqian
>
> On Sat, Mar 30, 2019 at 11:48 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>
>> On Sat, Mar 30, 2019 at 4:19 AM Coniine Dieu <coniinedieu at gmail.com> wrote:
>> >
>> > Just made a traumatizingly primitive prototype for K12 mode. To try it out:
>> > 1. copy the whole l2ork_addons/K12 folder to purr-data-installation-folder/extra.
>> > 2. back up these files from your purr-data-installation-folder/bin, and replace them with the files in https://tinyurl.com/k12-proto-1 :
>> >   - pd_canvas.html
>> >   - pd_canvas.js
>> >   - pdgui.js
>> >
>> > All the changes can be found at https://git.purrdata.net/nerrons/purr-data/merge_requests/1/diffs . Basically I added a "position: fixed; height: 100%" div in pd_canvas.html and added horizontal offsets in functions that needs the current cursor position, to counter the bias introduced by the 70px width of the k12 frame. Some bugs: when clicking the button on the k12 frame, the whole canvas gets pushed to the right; if press ESC when placing the k12 abstraction, the border does not change; etc. But anyways, I hope this prototype will add value to the proposal and meanwhile I'm going to continue working on that.
>>
>> Excellent! I'll have a look later this evening.
>>
>> -Jonathan
>>
>> >
>> > Thanks
>> > Shaoqian
>> >
>> > On Fri, Mar 29, 2019 at 9:45 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>
>> >> On Fri, Mar 29, 2019 at 6:17 AM Coniine Dieu <coniinedieu at gmail.com> wrote:
>> >> >
>> >> > Tried converting PNG to SVG and the result is surprisingly nice.
>> >> >
>> >> > Recipe:
>> >> > 1. Go to http://waifu2x.udp.jp, upscale.
>> >> > 2. Open the upscaled PNG. Trace Bitmap in Inkscape with "Color" mode and "Smooth" turned off. Try with different numbers of scans.
>> >> > 3. Save as "Optimized SVG".
>> >> >
>> >> > When using less numbers of scans, the file is small (down to 15 KB), and the result has a cute cartoon/crayon feel in it. Thus using SVG is definitely a viable option. Here's a Google Drive link to the files I've tested: https://tinyurl.com/png-svg-demo
>> >>
>> >> Ok, looks like that is definitely an option then.
>> >>
>> >> >
>> >> > However I'm not sure how [draw image] works. I tried having [struct svg-test float x float y], and then [draw image path-to-my.svg]. When I create [svg-test], it becomes a tiny transparent object that apparently doesn't display the SVG. I wonder what am I doing wrong here.
>> >>
>> >> Hm, not sure. There may be a bug with that object. I'll investigate later.
>> >>
>> >> -Jonathan
>> >>
>> >> >
>> >> > On Thu, Mar 28, 2019 at 9:59 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >> >>
>> >> >> On Wed, Mar 27, 2019 at 9:33 PM Coniine Dieu <coniinedieu at gmail.com> wrote:
>> >> >> >
>> >> >> > Hi Jonathan,
>> >> >> >
>> >> >> > Currently as we are using PNG files for k12 abstractions, we use [image] to load it. However I'm not sure how to do the same for SVG files since it seems that both [image] and [ggee/image] do not support it. I am wondering, if we are using SVG files for k12 abstractions, does that mean we have to write new objects that loads SVG files? Or are there other ways to do this?
>> >> >>
>> >> >> [draw image] and [ggee/image] both use the same interface for loading
>> >> >> images in the GUI.
>> >> >> And [draw image] supports SVG so it shouldn't be difficult to change
>> >> >> [ggee/image] to support
>> >> >> them, too.
>> >> >>
>> >> >> But this is something that can be done incrementally. For example,
>> >> >> getting the PNGs to work
>> >> >> first, then testing by changing one to an SVG.
>> >> >>
>> >> >> -Jonathan
>> >> >>
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Shaoqian
>> >> >> >
>> >> >> > On Tue, Mar 26, 2019 at 5:55 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >> >> >>
>> >> >> >> On Mon, Mar 25, 2019 at 1:54 PM Coniine Dieu <coniinedieu at gmail.com> wrote:
>> >> >> >> >
>> >> >> >> > Hi Jonathan,
>> >> >> >> >
>> >> >> >> > Thanks for the quick response.
>> >> >> >> >
>> >> >> >> > -- We don't need anything fancy for the tooltips so simple CSS should suffice.
>> >> >> >>
>> >> >> >> At least for SVG elements, the <title> tag is even easier-- the
>> >> >> >> browser automatically
>> >> >> >> hoists the inner text into a tooltip as well as handling the tooltip's
>> >> >> >> appearance
>> >> >> >> and placement.
>> >> >> >>
>> >> >> >> On the other hand a CSS tooltip gives us automatic text resizing when zooming,
>> >> >> >> which is probably preferable. Just make sure to do some tests with the
>> >> >> >> corners of
>> >> >> >> the window to ensure the tip shows up properly.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > -- Yes, I just tested: ggee/image supports relative path and @pd_extra works
>> >> >> >> > indeed if I put the abstractions into the installation folder. I wanted to
>> >> >> >> > create an independent patch so I didn't really check. My bad.
>> >> >> >>
>> >> >> >> No problem.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > -- I think we should keep the menus for trivial but necessary entries (like
>> >> >> >> > recently opened files) so we don't clutter the k12 frame. But of course, some of
>> >> >> >> > them can migrate, for the sake of touchscreen too. That leads to--
>> >> >> >> >
>> >> >> >> > -- Yes, touchscreen compatibility can be a good objective for the third month. I
>> >> >> >> > wonder if pd has any existing code in charge of touchscreen I can study or refer
>> >> >> >> > to.
>> >> >> >>
>> >> >> >> I think what I'm going to do is add touchstart, touchcancel, touchend,
>> >> >> >> and touchmove
>> >> >> >> listeners for the document and then just generate the relevant mouse-related
>> >> >> >> events from that. That should at least bring touch up to date with
>> >> >> >> mouse interaction.
>> >> >> >> That means it will leverage the same codebase so there's no need for separate
>> >> >> >> code paths aside from the one I mentioned above.
>> >> >> >>
>> >> >> >> (Ideally I'd like to use the pointer events API for both touch and
>> >> >> >> mouse but that
>> >> >> >> would require an upgrade of nw.js.)
>> >> >> >>
>> >> >> >> >
>> >> >> >> > -- I'll try to convert them into svg and see what happens. If anything is too
>> >> >> >> > complex we can always simplify a bit.
>> >> >> >>
>> >> >> >> Sounds good. If you want you could do a single image as a test to make sure
>> >> >> >> the underlying framework supports it.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > I'm excited to know that my plans are feasible. I'll try to finish the first
>> >> >> >> > draft within a few days. Are there any additional information you'd like to see
>> >> >> >> > in the proposal?
>> >> >> >>
>> >> >> >> It looks good to me so far. And of course, feel free to keep posting
>> >> >> >> to the list
>> >> >> >> here if you have any more questions or run into any issues.
>> >> >> >>
>> >> >> >> Best,
>> >> >> >> Jonathan
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Best,
>> >> >> >> > Shaoqian
>> >> >> >> > _______________________________________________
>> >> >> >> > L2Ork-dev mailing list
>> >> >> >> > L2Ork-dev at disis.music.vt.edu
>> >> >> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >> >> >> _______________________________________________
>> >> >> >> L2Ork-dev mailing list
>> >> >> >> L2Ork-dev at disis.music.vt.edu
>> >> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > L2Ork-dev mailing list
>> >> >> > L2Ork-dev at disis.music.vt.edu
>> >> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >> >> _______________________________________________
>> >> >> L2Ork-dev mailing list
>> >> >> L2Ork-dev at disis.music.vt.edu
>> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >> >
>> >> > _______________________________________________
>> >> > L2Ork-dev mailing list
>> >> > L2Ork-dev at disis.music.vt.edu
>> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >> _______________________________________________
>> >> L2Ork-dev mailing list
>> >> L2Ork-dev at disis.music.vt.edu
>> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >
>> > _______________________________________________
>> > L2Ork-dev mailing list
>> > L2Ork-dev at disis.music.vt.edu
>> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev