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

Sun Apr 7 18:56:33 EDT 2019

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!

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20190408/5950d96a/attachment-0001.html>