<div dir="ltr"><div dir="ltr"><div>Hi Jonathan,</div><div><br></div><div>The information about how old K12 fetches data is really helpful, thanks for that. I've added more content to the tooltip part. One reason I didn't pay much attention to tooltips over abstractions is that I find them quite annoying and they get displayed in the K12 buttons on the left anyway. But yeah, I should've included that in the proposal. Apart from that, I think it would be easier if we just build a JSON object at startup and fetch information from there instead of the whole index.<br></div><div><br></div><div>Here's draft 2: <a href="https://tinyurl.com/shaoqian-gsoc-2">https://tinyurl.com/shaoqian-gsoc-2</a> . Changes are in the tooltips part and the relevant weeks in the proposed timeline. It will probably be the final draft, given the date.<br></div><div><br></div><div>Thanks again for the review!</div><div><br></div><div>Cheers</div><div>Shaoqian<br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2019 at 12:11 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Apr 7, 2019 at 4:01 PM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
><br>
> Hi Jonathan,<br>
><br>
> Sorry for not getting back to you earlier--school is quite demanding. Anyways, here's my first draft of the proposal: <a href="http://tinyurl.com/shaoqian-gsoc-d1" rel="noreferrer" target="_blank">http://tinyurl.com/shaoqian-gsoc-d1</a> . Please be blunt and tell me whatever problems you find there, I would really appreciate that.<br>
><br>
> 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.<br>
><br>
> It's a long read, I know, and thanks for your time!<br>
<br>
Hi Shaoqian,<br>
<br>
Excellent draft!<br>
<br>
I only have two observations:<br>
<br>
1. Small thing-- grammar: "but I do have dabbled in"<br>
<br>
2. Tooltips-- in Pd-l2ork 1.0 we had an arcane system for displaying<br>
tooltips that did a GUI->Pd->GUI roundtrip each time a tip was to be<br>
displayed.<br>
Pd would fetch the help patch path and send it to the GUI. Then the<br>
GUI would open that file and parse the relevant tooltip text.<br>
<br>
One benefit is that this leveraged pre-existing data inside Pd help<br>
patches to display the tip. This was nice because it meant that users<br>
could revise<br>
the tip string without having to recompile. They could also make tips<br>
for abstraction simplys by writing a complete help file.<br>
<br>
This obviously meant reading a file from the filesystem for each tip.<br>
But this was only done opportunistically. The user would hover the<br>
mouse over<br>
an object long enough, and only then would the help patch be opened<br>
and parsed to obtain the relevant tip text.<br>
<br>
If you want to create a DOM element for each tooltip when each object<br>
gets drawn then we'll need a different way to fetch the tooltip<br>
text than the opportunistic way used in Pd-l2ork 1.0. One possibility<br>
would be to fetch it from the search index, and in fact there's<br>
already a setting to<br>
build that index at startup. At least that's the easiest thing I can think of.<br>
<br>
Also-- I *think* the tooltips in Pd-l2ork 1.0 would display a string<br>
for the description of the object itself when hovering the mouse over<br>
the box text.<br>
<br>
Hope that helps a bit. Let us know if you have any more questions<br>
about the project idea.<br>
<br>
Best,<br>
Jonathan<br>
<br>
><br>
> Cheers<br>
> Shaoqian<br>
><br>
> On Sat, Mar 30, 2019 at 11:48 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> On Sat, Mar 30, 2019 at 4:19 AM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
>> ><br>
>> > Just made a traumatizingly primitive prototype for K12 mode. To try it out:<br>
>> > 1. copy the whole l2ork_addons/K12 folder to purr-data-installation-folder/extra.<br>
>> > 2. back up these files from your purr-data-installation-folder/bin, and replace them with the files in <a href="https://tinyurl.com/k12-proto-1" rel="noreferrer" target="_blank">https://tinyurl.com/k12-proto-1</a> :<br>
>> >   - pd_canvas.html<br>
>> >   - pd_canvas.js<br>
>> >   - pdgui.js<br>
>> ><br>
>> > All the changes can be found at <a href="https://git.purrdata.net/nerrons/purr-data/merge_requests/1/diffs" rel="noreferrer" target="_blank">https://git.purrdata.net/nerrons/purr-data/merge_requests/1/diffs</a> . 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.<br>
>><br>
>> Excellent! I'll have a look later this evening.<br>
>><br>
>> -Jonathan<br>
>><br>
>> ><br>
>> > Thanks<br>
>> > Shaoqian<br>
>> ><br>
>> > On Fri, Mar 29, 2019 at 9:45 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Fri, Mar 29, 2019 at 6:17 AM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Tried converting PNG to SVG and the result is surprisingly nice.<br>
>> >> ><br>
>> >> > Recipe:<br>
>> >> > 1. Go to <a href="http://waifu2x.udp.jp" rel="noreferrer" target="_blank">http://waifu2x.udp.jp</a>, upscale.<br>
>> >> > 2. Open the upscaled PNG. Trace Bitmap in Inkscape with "Color" mode and "Smooth" turned off. Try with different numbers of scans.<br>
>> >> > 3. Save as "Optimized SVG".<br>
>> >> ><br>
>> >> > 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: <a href="https://tinyurl.com/png-svg-demo" rel="noreferrer" target="_blank">https://tinyurl.com/png-svg-demo</a><br>
>> >><br>
>> >> Ok, looks like that is definitely an option then.<br>
>> >><br>
>> >> ><br>
>> >> > 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.<br>
>> >><br>
>> >> Hm, not sure. There may be a bug with that object. I'll investigate later.<br>
>> >><br>
>> >> -Jonathan<br>
>> >><br>
>> >> ><br>
>> >> > On Thu, Mar 28, 2019 at 9:59 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> On Wed, Mar 27, 2019 at 9:33 PM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
>> >> >> ><br>
>> >> >> > Hi Jonathan,<br>
>> >> >> ><br>
>> >> >> > 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?<br>
>> >> >><br>
>> >> >> [draw image] and [ggee/image] both use the same interface for loading<br>
>> >> >> images in the GUI.<br>
>> >> >> And [draw image] supports SVG so it shouldn't be difficult to change<br>
>> >> >> [ggee/image] to support<br>
>> >> >> them, too.<br>
>> >> >><br>
>> >> >> But this is something that can be done incrementally. For example,<br>
>> >> >> getting the PNGs to work<br>
>> >> >> first, then testing by changing one to an SVG.<br>
>> >> >><br>
>> >> >> -Jonathan<br>
>> >> >><br>
>> >> >> ><br>
>> >> >> > Thanks,<br>
>> >> >> > Shaoqian<br>
>> >> >> ><br>
>> >> >> > On Tue, Mar 26, 2019 at 5:55 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> >> >> >><br>
>> >> >> >> On Mon, Mar 25, 2019 at 1:54 PM Coniine Dieu <<a href="mailto:coniinedieu@gmail.com" target="_blank">coniinedieu@gmail.com</a>> wrote:<br>
>> >> >> >> ><br>
>> >> >> >> > Hi Jonathan,<br>
>> >> >> >> ><br>
>> >> >> >> > Thanks for the quick response.<br>
>> >> >> >> ><br>
>> >> >> >> > -- We don't need anything fancy for the tooltips so simple CSS should suffice.<br>
>> >> >> >><br>
>> >> >> >> At least for SVG elements, the <title> tag is even easier-- the<br>
>> >> >> >> browser automatically<br>
>> >> >> >> hoists the inner text into a tooltip as well as handling the tooltip's<br>
>> >> >> >> appearance<br>
>> >> >> >> and placement.<br>
>> >> >> >><br>
>> >> >> >> On the other hand a CSS tooltip gives us automatic text resizing when zooming,<br>
>> >> >> >> which is probably preferable. Just make sure to do some tests with the<br>
>> >> >> >> corners of<br>
>> >> >> >> the window to ensure the tip shows up properly.<br>
>> >> >> >><br>
>> >> >> >> ><br>
>> >> >> >> > -- Yes, I just tested: ggee/image supports relative path and @pd_extra works<br>
>> >> >> >> > indeed if I put the abstractions into the installation folder. I wanted to<br>
>> >> >> >> > create an independent patch so I didn't really check. My bad.<br>
>> >> >> >><br>
>> >> >> >> No problem.<br>
>> >> >> >><br>
>> >> >> >> ><br>
>> >> >> >> > -- I think we should keep the menus for trivial but necessary entries (like<br>
>> >> >> >> > recently opened files) so we don't clutter the k12 frame. But of course, some of<br>
>> >> >> >> > them can migrate, for the sake of touchscreen too. That leads to--<br>
>> >> >> >> ><br>
>> >> >> >> > -- Yes, touchscreen compatibility can be a good objective for the third month. I<br>
>> >> >> >> > wonder if pd has any existing code in charge of touchscreen I can study or refer<br>
>> >> >> >> > to.<br>
>> >> >> >><br>
>> >> >> >> I think what I'm going to do is add touchstart, touchcancel, touchend,<br>
>> >> >> >> and touchmove<br>
>> >> >> >> listeners for the document and then just generate the relevant mouse-related<br>
>> >> >> >> events from that. That should at least bring touch up to date with<br>
>> >> >> >> mouse interaction.<br>
>> >> >> >> That means it will leverage the same codebase so there's no need for separate<br>
>> >> >> >> code paths aside from the one I mentioned above.<br>
>> >> >> >><br>
>> >> >> >> (Ideally I'd like to use the pointer events API for both touch and<br>
>> >> >> >> mouse but that<br>
>> >> >> >> would require an upgrade of nw.js.)<br>
>> >> >> >><br>
>> >> >> >> ><br>
>> >> >> >> > -- I'll try to convert them into svg and see what happens. If anything is too<br>
>> >> >> >> > complex we can always simplify a bit.<br>
>> >> >> >><br>
>> >> >> >> Sounds good. If you want you could do a single image as a test to make sure<br>
>> >> >> >> the underlying framework supports it.<br>
>> >> >> >><br>
>> >> >> >> ><br>
>> >> >> >> > I'm excited to know that my plans are feasible. I'll try to finish the first<br>
>> >> >> >> > draft within a few days. Are there any additional information you'd like to see<br>
>> >> >> >> > in the proposal?<br>
>> >> >> >><br>
>> >> >> >> It looks good to me so far. And of course, feel free to keep posting<br>
>> >> >> >> to the list<br>
>> >> >> >> here if you have any more questions or run into any issues.<br>
>> >> >> >><br>
>> >> >> >> Best,<br>
>> >> >> >> Jonathan<br>
>> >> >> >><br>
>> >> >> >> ><br>
>> >> >> >> > Best,<br>
>> >> >> >> > Shaoqian<br>
>> >> >> >> > _______________________________________________<br>
>> >> >> >> > L2Ork-dev mailing list<br>
>> >> >> >> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> >> >> >> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> >> >> >> _______________________________________________<br>
>> >> >> >> L2Ork-dev mailing list<br>
>> >> >> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> >> >> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> >> >> ><br>
>> >> >> > _______________________________________________<br>
>> >> >> > L2Ork-dev mailing list<br>
>> >> >> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> >> >> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> >> >> _______________________________________________<br>
>> >> >> L2Ork-dev mailing list<br>
>> >> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> >> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > L2Ork-dev mailing list<br>
>> >> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> >> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> >> _______________________________________________<br>
>> >> L2Ork-dev mailing list<br>
>> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > L2Ork-dev mailing list<br>
>> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
>> _______________________________________________<br>
>> L2Ork-dev mailing list<br>
>> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>