Re: Volunteering to help on etc/TODO item: Improved xwidgets support

[Andrew De Angelis <bobodeangelis@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5511 bytes --]

Great, thanks for the informative reply!

It would be good if you coordinated your efforts with Qiantian
> Hong (copied), who is also making changes in that area.
>

Nice to meet you both. @Qiantian Hong let me know about your progress on
this, and if there's a specific area I should focus on, so we can combine
forces and avoid duplicate work.

Thanks.  It would be nice if someone resolved the more crucial issues
> first, though
>

I wasn't aware of these, but I will prioritize them.

Unless you can complete this work before November


Yeah, that's a tight deadline. I am going to try to fix the biggest issues
by then, but we'll probably have to wait until the next release to have
this included

I think the timer stops by itself, the variable is not all that
> important.
>

This is probably another NS-specific issue, but the timer doesn't always
stop in my build. The issue starts in `xwidget-webkit-callback'; it looks
like the  "load-finished" event sometimes (most of the times) doesn't
happen or is not received. I will add this to the list of things to fix.

One other possible Lisp bug: currently, `xwidget-webkit-current-url' always
returns "URL: nil" for me. This shouldn't depend on other xwidget code: the
issue is caused by the fact that `kill-new' doesn't return the string it
just added to the kill-ring. (If it does work in your builds let me know,
as I'd have to investigate what's causing such different behavior.)
This is my fix for this:

(defun xwidget-webkit-current-url ()
  "Display the current xwidget webkit URL and place it on the `kill-ring'."
  (interactive nil xwidget-webkit-mode)
  (let ((url (or (xwidget-webkit-uri (xwidget-webkit-current-session)) "")))
    (kill-new url)
    (message "URL: %s" url)))




On Tue, Oct 18, 2022 at 9:33 PM Po Lu <luangruo@yahoo.com> wrote:

> Andrew De Angelis <bobodeangelis@gmail.com> writes:
>
> > Hello everyone and thanks for all your work!
>
> Hello, thanks for working on Emacs.
>
> > This is regarding TODO item: "Things to be done for specific packages
> > or features/NeXTstep port/Missing features/Improved xwidgets support"
> >
> > I've started working on the NS code for xwidget-webkit, with the aim
> > of bringing it up-to-date with the changes to the X11 and GTK code
> > (you can check my as-yet-still-very-minor changes at this fork).  I'm
> > sending the email to: 1) check if someone is already working on this
> > 2) make sure I'm going about it the right way 3) inquire about the
> > current X11/GTK implementation.
> >
> > Regarding 1: I haven't found many recent matches for 'xwidget' in the
> > mailing list, but if you're aware of someone already working on this
> > effort, please let me know
>
> Sure.  It would be good if you coordinated your efforts with Qiantian
> Hong (copied), who is also making changes in that area.
>
> > Regarding 2: As noted in the Contributing node of the manual, I'm
> > making you aware of my planned improvements and I'd like to know if
> > you have any suggestions/advice. My current plan is to go through the
> > xwidget.c code, take note of any functions/subroutines that are
> > defined for GTK but not NS, and add an NS implementation in xwidget.m.
>
> Thanks.  It would be nice if someone resolved the more crucial issues
> first, though:
>
>   - many procedures in nsxwidget.m crash when encountering killed
>     xwidgets (see the doc string of `kill-xwidget' for more details.)
>   - nsxwidget.m has apparently been written with Objective-C Automatic
>     Reference Counting in mind, and thus leak memory, as Emacs cannot
>     use ARC.
>
> > I will do my best to complete this so that the NS code will be fully
> > up-to-date. If there are any planned changes to xwidget.c or
> > xwidget.el for the upcoming 29.1 release, please let me know.
>
> I think it will probably be too late for Emacs 29.1, which will start
> the pre-release process soon, at which point changes that don't only fix
> regressions (and possibly the MS-DOS build) will not be allowed.  Unless
> you can complete this work before November, that is.
>
> > Regarding 3: I do not have a Linux machine available at the moment,
> > which would be valuable to get a better sense of the current GTK
> > implementation (I'm working on finding additional volunteers to help
> > on this).  Is there a standard-procedure I can follow to ask questions
> > here about the GTK implementation?
>
> Just send an email to this list, with me copied in.  BTW, the canonical
> implementation is not a "GTK implementation", but rather two
> implementations combined in a single file through ifdefs: one for the
> regular X11 build, and the other for a GTK build that does not use any X
> Windows specific interfaces.
>
> > Is there a point person I should contact specifically?
>
> Me.
>
> > I would like to keep the two different implementations as consistent
> > as possible, while also making sure that common bugs are addressed.
> > One question I have regarding this is on the
> > `xwidget-webkit--loading-p' variable: in my build, I see that this is
> > set to true when creating a new session, but it is then never updated
> > to nil (even long after the web page has fully loaded). Since this
> > variable is not present in the C code, I'm not sure if this is a
> > limitation of the Lisp code (and therefore common regardless of the
> > underlying framework, GTK or NS), or if it's handled correctly in
> > other builds.
>
> I think the timer stops by itself, the variable is not all that
> important.
>

[-- Attachment #2: Type: text/html, Size: 7287 bytes --]