Mergeability of xwidget patch?

Mergeability of xwidget patch?

[Daniel Hackney]

I'm the developer of Ezbl [1], a package which embeds the Uzbl web
browser within Emacs. Ezbl depends on the xwidget patch by Joakim
Verona, which is in the Emacs repo under the "xwidget" branch. I'd like
to have Ezbl be available to people without them having to install a
separate branch of Emacs (especially since it hasn't kept up with the
trunk).

I would like to know how close the xwidget patches are to being fit for
the 24.1 trunk and what still needs to be done. I'm not much of a C
programmer, and don't know the C-level internals of Emacs well, but I'm
willing to learn for the sake of getting this patch completed and merged
in. I think it would be a great feature to have in 24.1, but I heard the
feature freeze was coming soon-ish, so I understand if it has to be
pushed back.

I'd love to have Ezbl available to those using the trunk and especially
folks who use stable releases. I think it could be a powerful addition
to the Emacs ecosystem by adding HTML5 support (through WebKit) into the
mix. It's also possible to communicate with the embedded Uzbl instance
through JavaScript, so there's a lot of potential there.

Thanks,

Daniel Hackney

P.S. I'm not on the mailing list, so if you could CC me on replies,
it'll be easier for me to communicate. Sorry for the inconvenience.

[1] https://github.com/haxney/ezbl

--
Daniel M. Hackney

Re: Mergeability of xwidget patch?

[Stefan Monnier]

> I'm the developer of Ezbl [1], a package which embeds the Uzbl web
> browser within Emacs. Ezbl depends on the xwidget patch by Joakim
> Verona, which is in the Emacs repo under the "xwidget" branch. I'd like
> to have Ezbl be available to people without them having to install a
> separate branch of Emacs (especially since it hasn't kept up with the
> trunk).

I think both xwidget and ezbl are indeed a very interesting projects.
I do not know enough about the xwidget branch to tell you how close/far
it is to merging.  But unless it's "right about ready" (which doesn't
sounds likely) it seems too late for 24.1 which will enter feature
freeze real-soon-now.
Depending on details of the xwidget code (if it is sufficiently
modular), it might make it into 24.2, but otherwise it'd have to wait
for 25.1.
If the code isnot modular enough, maybe we could install some
refactoring right now, so that the remaining patch is sufficiently
modular for 24.2.


        Stefan

Re: Mergeability of xwidget patch?

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm the developer of Ezbl [1], a package which embeds the Uzbl web
>> browser within Emacs. Ezbl depends on the xwidget patch by Joakim
>> Verona, which is in the Emacs repo under the "xwidget" branch. I'd like
>> to have Ezbl be available to people without them having to install a
>> separate branch of Emacs (especially since it hasn't kept up with the
>> trunk).
>
> I think both xwidget and ezbl are indeed a very interesting projects.
> I do not know enough about the xwidget branch to tell you how close/far
> it is to merging.  But unless it's "right about ready" (which doesn't
> sounds likely) it seems too late for 24.1 which will enter feature
> freeze real-soon-now.
> Depending on details of the xwidget code (if it is sufficiently
> modular), it might make it into 24.2, but otherwise it'd have to wait
> for 25.1.
> If the code isnot modular enough, maybe we could install some
> refactoring right now, so that the remaining patch is sufficiently
> modular for 24.2.

xwidgets walk all over the display code. OTOH its pretty modular in the
sense that if you dont insert xwidgets the new painting code isn't
touched. So, 24.2 doesn't seem unreasonable, but I think the project
needs more hands if its going to move forward.

I can offer to keep the branch more alive but I probably need someone
with a large stick to keep me going :)

>
>
>         Stefan

-- 
Joakim Verona

Re: Mergeability of xwidget patch?

[Daniel Hackney]

<joakim@verona.se> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Depending on details of the xwidget code (if it is sufficiently
>> modular), it might make it into 24.2, but otherwise it'd have to wait
>> for 25.1.
>> If the code isnot modular enough, maybe we could install some
>> refactoring right now, so that the remaining patch is sufficiently
>> modular for 24.2.
>
> xwidgets walk all over the display code. OTOH its pretty modular in
> the sense that if you dont insert xwidgets the new painting code isn't
> touched. So, 24.2 doesn't seem unreasonable, but I think the project
> needs more hands if its going to move forward.
>
> I can offer to keep the branch more alive but I probably need someone
> with a large stick to keep me going :)

I'm certainly willing to wield the large stick and be the taskmaster,
though I'd also like to help out some too.

This may be better discussed off-list, but where do you think I should
start? Any particular resources you'd suggest for getting up to speed on
the relevant parts of the Emacs display code or Xlib (or XCB)?

Also, I had an idea for keyboard propagation. It's ugly, but much better
than the way I'd been testing in Ezbl (forking an Xdotool [1] instance
on each keypress): using libxdo [2] to forward keypresses to the
embedded process.

Anyway, I'm happy to help, even if it's just whipping you into shape ;).
Ultimately, I'd like to be able to take one more application off of my
current commonly-used list (which right now is Emacs, gnome-terminal,
and Firefox).

[1] http://www.semicomplete.com/projects/xdotool/

[2] http://www.semicomplete.com/files/xdotool/docs/html/

--
Daniel M. Hackney

Re: Mergeability of xwidget patch?

[joakim]

Daniel Hackney <dan@haxney.org> writes:

> <joakim@verona.se> wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Depending on details of the xwidget code (if it is sufficiently
>>> modular), it might make it into 24.2, but otherwise it'd have to wait
>>> for 25.1.
>>> If the code isnot modular enough, maybe we could install some
>>> refactoring right now, so that the remaining patch is sufficiently
>>> modular for 24.2.
>>
>> xwidgets walk all over the display code. OTOH its pretty modular in
>> the sense that if you dont insert xwidgets the new painting code isn't
>> touched. So, 24.2 doesn't seem unreasonable, but I think the project
>> needs more hands if its going to move forward.
>>
>> I can offer to keep the branch more alive but I probably need someone
>> with a large stick to keep me going :)
>
> I'm certainly willing to wield the large stick and be the taskmaster,
> though I'd also like to help out some too.
>
> This may be better discussed off-list, but where do you think I should
> start? Any particular resources you'd suggest for getting up to speed on
> the relevant parts of the Emacs display code or Xlib (or XCB)?

I've started rewriting the code for a MVC aproach. Its going better than
expected (except I'll be sleepy during meetings tomorrow).

I think the mvc aproach will be saner and easier to understand and thus
contribute to than the insane phantoming scheme I used before.

Another thing that would help is if you can find out if webkit and uzbl
supports multiple document views. I plan to use such a function to
achieve split emacs windows showing the same xembedded application.

If thats not possible only one view will be active for the xemmbed case
for the foreseeable future, because the composition code that is
otherwise needed was to infuriating to write. (it would help if someone
could look at that too. the aproach I tried was blitting using
cairo. the attempt is in xwidget-attic.c)

> Also, I had an idea for keyboard propagation. It's ugly, but much better
> than the way I'd been testing in Ezbl (forking an Xdotool [1] instance
> on each keypress): using libxdo [2] to forward keypresses to the
> embedded process.

I had xwidget-send-keyboard-event but I dont remember if it actually
worked. If we cant get that to work libxdo could be an option.
>
> Anyway, I'm happy to help, even if it's just whipping you into shape
> ;).

You did already because I got a guilty conscience and started hacking!

> Ultimately, I'd like to be able to take one more application off of my
> current commonly-used list (which right now is Emacs, gnome-terminal,
> and Firefox).

Hey, you should be able to remove gnome-terminal as-is!
(ok, it's a pretty large subject)

> [1] http://www.semicomplete.com/projects/xdotool/
>
> [2] http://www.semicomplete.com/files/xdotool/docs/html/
>
> --
> Daniel M. Hackney

-- 
Joakim Verona

Re: Mergeability of xwidget patch?

[joakim]

Daniel Hackney <dan@haxney.org> writes:

> I'm the developer of Ezbl [1], a package which embeds the Uzbl web
> browser within Emacs. Ezbl depends on the xwidget patch by Joakim
> Verona, which is in the Emacs repo under the "xwidget" branch. I'd like
> to have Ezbl be available to people without them having to install a
> separate branch of Emacs (especially since it hasn't kept up with the
> trunk).
>
> I would like to know how close the xwidget patches are to being fit for
> the 24.1 trunk and what still needs to be done. I'm not much of a C
> programmer, and don't know the C-level internals of Emacs well, but I'm
> willing to learn for the sake of getting this patch completed and merged
> in. I think it would be a great feature to have in 24.1, but I heard the
> feature freeze was coming soon-ish, so I understand if it has to be
> pushed back.
>
> I'd love to have Ezbl available to those using the trunk and especially
> folks who use stable releases. I think it could be a powerful addition
> to the Emacs ecosystem by adding HTML5 support (through WebKit) into the
> mix. It's also possible to communicate with the embedded Uzbl instance
> through JavaScript, so there's a lot of potential there.

Sadly the patch is in a bad state. I was convinced composition was the
right way to go but in retrospect that is too complex to get working
robustly. I'm working on an MVC approach instead. I didn't choose that
path to start with because its more difficult with xembed clients, which
is the primary use-case people seems interested in.

For some xembed clients(like a patched version of Inkscape I have) thats
solveable because it allows several windows. I tried to have a look if
Webkit supports that as well but so far I haven't found a
solution. Mplayer doesn't either. those kind of clients will only have a
single working view, but that might not be too bad in practice.

Anyway I'm sorry for not giving the patch the love it deserves. Its
clearly still on my agenda, because I've spent a lot of time working on
a similar project to your Ezbl project, called Inkmacs. which fuses
Emacs and Inkscape. My goal is to embedded Inkscape in Emacs but so far
I've focused on controlling Inkscape through Dbus from Emacs. This has
required a lot of work on the Inkscape side in expanding and bugfixing
the Inkscape Dbus API.

I was in fact updating the xembed branch locally the other day and
starting to look at which commits to revert in order to backtrack to a
state where an MVC approach could be done.

I would be extatic to have more people help out with this. People do
show up but later vanish. I'm not sure why that is. If I need to explain
things better in the documentation I can try.

>
> Thanks,
>
> Daniel Hackney
>
> P.S. I'm not on the mailing list, so if you could CC me on replies,
> it'll be easier for me to communicate. Sorry for the inconvenience.
>
> [1] https://github.com/haxney/ezbl
>
> --
> Daniel M. Hackney

-- 
Joakim Verona