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

Sat Mar 30 01:54:12 EDT 2019

We don't consider updating nw.js, right? The version we are using does not
support CSS Grid. Just wanted to check; if that's the case I will either
use another layout tool or include updating nw.js in the proposal. For the
latter, what are the challenges for updating, or is it just for safety?
Thanks.

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