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

[Jonathan Wilkes]

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