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

[Jonathan Wilkes]

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