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

[Andrew De Angelis]

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.