Gtkconv webview entry regression

[Jorge Villaseñor]

On Wed, Jun 17, 2015 at 10:38 PM, Eion Robb <eion at robbmob.com> wrote:

> Are the magic values  WEBVIEW_DOM_FONT_PADDING and
> WEBVIEW_DOM_TEXT_PADDING not dependant on font-size, font-family or
> font-weight?
>

That may be possible. I tried to find the values on the DOM to extract them
as well, but found nothing.

Disclosure: I am not familiar at all with all this web/js/DOM stuff, so if
you know better, we can implement it.


> On 18 June 2015 at 14:53, Jorge Villaseñor <salinasv at gmail.com> wrote:
>
>> Third attempt! Yeeii!
>>
>> ---------- Forwarded message ----------
>> From: Jorge Villaseñor <salinasv at gmail.com>
>> Date: Wed, Jun 17, 2015 at 7:42 PM
>> Subject: Fwd: Gtkconv webview entry regression
>> To: Pidgin Devel Mailing List <devel at pidgin.im>
>>
>>
>> Second attempt to get this through
>>
>>
>> ---------- Forwarded message ----------
>> From: Jorge Villaseñor <salinasv at gmail.com>
>> Date: Tue, Jun 16, 2015 at 12:02 AM
>> Subject: Gtkconv webview entry regression
>> To: Pidgin Devel Mailing List <devel at pidgin.im>
>>
>>
>> As some of you have noticed, on pidgin 3.0 the gtkconv->entry sometimes
>> have a 0-1 pixel height.
>>
>> Finally, after poking too may ways to figure this out, I found a way to
>> set the size of the gtkconv entry at startup based on the prefs, autosize
>> up to half the conversation window and back.
>>
>> The approach is to take the font-size form the DOM * min_lines from the
>> prefs + some padding for initial setup and then respect the DOM size
>> (+padding) to increment the size of the widget.
>>
>> There is only one pice of it that I was not able to solve, but this is
>> FAR better than what we have right now. When we delete a line more than
>> min_lines, the DOM does not return to the needed size immediately, it
>> requires more events to incrementally get to the actual needed size. I
>> expect some of you with more knowledge of GtkWebkit and HTML magic can
>> figure out something to force this DOM height calculation.
>>
>> Please review this code and give some inputs about what can be done
>> better. It needs a little of clean up, maybe move some lines to
>> gtkwebview.[ch] and delete my debug prints (I left them there to help
>> whoever wants to tweak the patch).
>>
>> If nobody answer, I will just commit this by the end of the week. If you
>> want to review but don't have time this week, please let me know.
>>
>> --
>> Masca
>>
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing on usenet and in e-mail?
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at pidgin.im
>> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>>
>
>


-- 
Masca

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20150618/a616ea37/attachment.html>