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

Tue Apr 9 05:57:36 EDT 2019

Hi Jonathan,

The information about how old K12 fetches data is really helpful, thanks
for that. I've added more content to the tooltip part. One reason I didn't
pay much attention to tooltips over abstractions is that I find them quite
annoying and they get displayed in the K12 buttons on the left anyway. But
yeah, I should've included that in the proposal. Apart from that, I think
it would be easier if we just build a JSON object at startup and fetch
information from there instead of the whole index.

Here's draft 2: https://tinyurl.com/shaoqian-gsoc-2 . Changes are in the
tooltips part and the relevant weeks in the proposed timeline. It will
probably be the final draft, given the date.

Thanks again for the review!

Cheers
Shaoqian

On Mon, Apr 8, 2019 at 12:11 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Sun, Apr 7, 2019 at 4:01 PM Coniine Dieu <coniinedieu at gmail.com> wrote:
> >
> > 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!
>
> Hi Shaoqian,
>
> Excellent draft!
>
> I only have two observations:
>
> 1. Small thing-- grammar: "but I do have dabbled in"
>
> 2. Tooltips-- in Pd-l2ork 1.0 we had an arcane system for displaying
> tooltips that did a GUI->Pd->GUI roundtrip each time a tip was to be
> displayed.
> Pd would fetch the help patch path and send it to the GUI. Then the
> GUI would open that file and parse the relevant tooltip text.
>
> One benefit is that this leveraged pre-existing data inside Pd help
> patches to display the tip. This was nice because it meant that users
> could revise
> the tip string without having to recompile. They could also make tips
> for abstraction simplys by writing a complete help file.
>
> This obviously meant reading a file from the filesystem for each tip.
> But this was only done opportunistically. The user would hover the
> mouse over
> an object long enough, and only then would the help patch be opened
> and parsed to obtain the relevant tip text.
>
> If you want to create a DOM element for each tooltip when each object
> gets drawn then we'll need a different way to fetch the tooltip
> text than the opportunistic way used in Pd-l2ork 1.0. One possibility
> would be to fetch it from the search index, and in fact there's
> already a setting to
> build that index at startup. At least that's the easiest thing I can think
> of.
>
> Also-- I *think* the tooltips in Pd-l2ork 1.0 would display a string
> for the description of the object itself when hovering the mouse over
> the box text.
>
> Hope that helps a bit. Let us know if you have any more questions
> about the project idea.
>
> Best,
> Jonathan
>
> >
> > 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
> >
> > _______________________________________________
> > 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/20190409/fbb06c7c/attachment-0001.html>