From: joakim@verona.se
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725)
Date: Sat, 17 Jan 2015 18:40:48 +0100 [thread overview]
Message-ID: <m3a91htie7.fsf@exodia.verona.se> (raw)
In-Reply-To: <m3egqttou1.fsf@exodia.verona.se> (joakim@verona.se's message of "Sat, 17 Jan 2015 16:21:42 +0100")
joakim@verona.se writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: joakim@verona.se
>>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>> Date: Fri, 16 Jan 2015 22:16:57 +0100
>>>
>>> Here in the L2R case, I insert a button in the middle of the text. If I
>>> type more text, the buttone moves along with the text towards the right
>>> edge. This is the expected behaviour.
>>> (xwidget-demo "a-button"
>>> (xwidget-insert (+ 15 (point-min)) 'Button "button" 60 50)
>>> (define-key (current-local-map) [xwidget-event] 'xwidget-handler-demo-basic))
>>>
>>> In the next case the button is also in the middle of the text at
>>> first. However, when the direction is changed to right-to-left, the text
>>> sticks to the right edge as expected, but the button jumps to the edge
>>> rather than staying within the text. If I type some text, the text move
>>> right to left, but the button just stays there at the right edge.
>>
>> That's indeed a sign of some problem. The code that places the widget
>> on the screen on the Xlib level is something specific to your changes,
>> am I right? I believe that's where the problem is: somehow that code
>> doesn't work correctly in right-to-left display lines (a.k.a. "glyph
>> rows"). Can you show the code which computes the coordinates where to
>> place the widget?
>
> The code is supposed to work like it does for images. The display engine
> calculates coordinates.
Now I tried the same test, but with an image. It behaves the same way!
So this would seem to indicate a number of possibilities:
- My test is somewhow flawed. Perhaps (set (make-local-variable
'bidi-paragraph-direction) 'right-to-left) isnt supposed to affect
images and xwidgets etc.
- my xwidget code is so flawed that it affects the image code where it
shouldnt. (the code paths are supposed to be separate though)
- this is how its supposed to work, and everything is allright.
> Then the xwidget code further tweaks the coordinates, and place the gtk
> components on-screen.
>
> AFAICS in this particular case the (xwidget modified) display engine
> isnt calculating the coordinates properly, because text is flowing
> around the gtk button. It is not being placed above text.
>
> I think the xwidget code is basically older than the merge of bidi to
> trunk, and I never did the modifications necessary for bidi, and I think
> I'm missing some important bidi bits.
>
> Anyway, I will try your method below and see if I can figure something out.
>
>> To make sure this code is indeed the problem, I suggest to look at the
>> glyph row generated by the device-independent part of the display
>> engine, and make sure the glyph row is correct. Here's how:
>>
>> $ cd src
>> $ gdb ./emacs
>> (gdb) break Fredraw_display
>> (gdb) r -Q
>>
>> Now recreate the problem with button display in R2L line, make sure
>> the cursor is in that line, and type "M-x redraw-display RET". This
>> will cause GDB to kick in. Then do:
>>
>> (gdb) break set_cursor_from_row
>> (gdb) continue
>>
>> Usually, the first time the breakpoint in set_cursor_from_row is hit,
>> it's because Emacs redisplays the echo area, which is not where we
>> want to look. Type "bt" to see if that's the case: if it is, you
>> should see display_echo_area in the backtrace, in which case type
>> "continue" and wait for the next time the breakpoint breaks. This
>> time, "bt" should show something like this:
>>
>> 14252 struct glyph *glyph = row->glyphs[TEXT_AREA];
>> (gdb) bt 10
>> #0 set_cursor_from_row (w=0x17e4918 <dumped_data+2497336>, row=0xfc46e8,
>> matrix=0xfbd418, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:14252
>> #1 0x010663b0 in display_line (it=0x82beb0) at xdisp.c:20828
>> #2 0x0105720f in try_window (window=25053469, pos=..., flags=1)
>> at xdisp.c:16928
>> #3 0x01053f90 in redisplay_window (window=25053469, just_this_one_p=false)
>> at xdisp.c:16401
>> #4 0x0104c567 in redisplay_window_0 (window=25053469) at xdisp.c:14226
>>
>> Now issue this command:
>>
>> (gdb) pgrow
>>
>> and post the full output.
>>
>> The command "pgrow" is defined by src/.gdbinit. Latest versions of
>> GDB will refuse to read that file unless you tell GDB that it's "safe"
>> to read it. If you didn't make such an arrangement, the easiest thing
>> to do is simply read the file manually:
>>
>> (gdb) source .gdbinit
>>
>> You'll have to do that in case GDB says "pgrow" is not a known
>> command.
>>
>> Finally, it could be that "pgrow" doesn't yet know how to display the
>> xwidget glyph, in which case you will have to modify the pgx function
>> in .gdbinit to do that.
--
Joakim Verona
next prev parent reply other threads:[~2015-01-17 17:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20141226164113.11620.38682@vcs.savannah.gnu.org>
2014-12-27 15:22 ` [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725) Stefan Monnier
2014-12-27 15:48 ` joakim
2014-12-28 16:08 ` Eli Zaretskii
2014-12-29 9:48 ` joakim
2014-12-29 13:46 ` Ulrich Mueller
2014-12-29 16:10 ` Eli Zaretskii
2015-01-09 20:17 ` joakim
2014-12-29 16:03 ` Eli Zaretskii
2015-01-09 20:12 ` joakim
2015-01-09 20:35 ` Eli Zaretskii
2015-01-16 20:50 ` joakim
2015-01-16 20:59 ` Eli Zaretskii
2015-01-16 21:16 ` joakim
2015-01-17 10:19 ` Eli Zaretskii
2015-01-17 15:21 ` joakim
2015-01-17 17:40 ` joakim [this message]
2015-01-17 18:04 ` Eli Zaretskii
2015-01-17 18:13 ` joakim
2015-01-17 18:39 ` Eli Zaretskii
2015-01-17 23:08 ` joakim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3a91htie7.fsf@exodia.verona.se \
--to=joakim@verona.se \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.