Hi,
I'm not going to the GTK+ hackfest, but there is one subject listed on
the wiki page that I want to talk about: textview/sourceview
replacements.
Christian talked a bit about it here:
https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00037.html
Which is inspired by this paper:
htt
On Sun, Jun 5, 2016 at 1:35 PM, Sébastien Wilmet wrote:
> Hi,
>
> I'm not going to the GTK+ hackfest, but there is one subject listed on
> the wiki page that I want to talk about: textview/sourceview
> replacements.
>
> Christian talked a bit about it here:
> https://mail.gnome.org/archives/gtk-d
On 06/05/2016 10:35 AM, Sébastien Wilmet wrote:
> It would indeed be really nice to have such an implementation, to
> support very large files and very long lines (GtkTextView currently
> doesn't support well very long lines, there is a performance issue). But
> writing a new text widget is a major
On 05.06.2016 22:33, Christian Hergert wrote:
> On 06/05/2016 10:35 AM, Sébastien Wilmet wrote:
>> For source code, GtkTextView is really not that bad IMHO. Normally
>> source code doesn't trigger the very long line problem (and even, this
>> problem in GtkTextView is fixable by internal refactorin
On 06/05/2016 01:25 PM, LRN wrote:
>> If we could sacrifice 100% correct scrollbar correctness (really,
>> its
>>> not that big of a deal) we could avoid this problem. Just
>>> estimate by byte offset the Y position, and make calculated
>>> offsets in the Y position b-tree/treap/index relative to i
