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

[Coniine Dieu]

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?

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