Re: ScrolledWindow, DrawingArea, and setting step-increment
On Wed, Nov 13, 2013 at 7:56 PM, Gabriele Greco gabriele.gr...@darts.it wrote: in Gypsum has barely started and I already have 50K lines; my RosMud session currently has 300K lines of scrollback; and I've noted as an unsolvable RosMud bug that it's unacceptably slow adding the 16,777,216th line to the buffer (because it does a naive I think that so many lines may be a problem for GtkTextBuffer, I mean, they are also a problem for an editor like vim :) Okay, I got around to fiddling the current code to use TextBuffer/TextView. If I put the TextView directly in the window, it simply expanded to hold as much as it wants; putting it in the ScrolledWindow means it still scrolls by partial lines, based on the window size. There must be something I'm missing here - some way to configure something. I'm sure it's staring me in the face and I'm just not seeing it, somewhere, because this must be a solved problem! I mean, maybe I'm doing the wrong thing in using a DrawingArea for text, but text is exactly what the TextView is supposed to, well, view, so it's logical to want to scroll by lines. I put the change onto a dedicated branch. Here's the commit; if you can spot some glaring error in it, I'd love to hear! https://github.com/Rosuav/Gypsum/commit/4aafb0805c2c575029371d7c16395829463caf43 Thanks for your help Gabriele. If nothing else, I've learned a few things about TextView along the way :) ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ScrolledWindow, DrawingArea, and setting step-increment
Hmm. I used to have something using that, in one of the early tests, but there was either a critical performance problem, or something I couldn't do with it. Can that handle mark-and-copy, clickable URLs, and so on? Or possibly it's that you say thousands there; to me, thousands of lines is just barely getting started. My current session Mark copy and clickable urls are supported in the code example I sent you. About the thousands... I've not done specific benchmarks but I used to keep a scrollback of 5 lines in my old powerbook 800mhz without slowdowns. in Gypsum has barely started and I already have 50K lines; my RosMud session currently has 300K lines of scrollback; and I've noted as an unsolvable RosMud bug that it's unacceptably slow adding the 16,777,216th line to the buffer (because it does a naive I think that so many lines may be a problem for GtkTextBuffer, I mean, they are also a problem for an editor like vim :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ScrolledWindow, DrawingArea, and setting step-increment
I'm developing a MUD client in Pike, using GTK2 for the UI, and there's an aspect of scrolling that's bugging me. The display uses discrete lines of text of a fixed height (or, to be more technically accurate, a fixed distance from the start of one line to the start of the next), and I'd really like the scrolling to be done in lines I suggest you to use GtkTextView for your text output, thank to GtkTextTag it's flexible enough to do everything a mud client needs, also blinking text, it scrolls at line boundaries and let you keep thousands of lines of textbuffer without slowdowns. For an example of ANSI16 parser/output with GtkTextView using GTK2 you can look at my own mud client ( source http://sourceforge.net/p/ggmud/code/HEAD/tree/trunk/ggmud/ ). I think most of the code you may be interested in is in ansi.c window. c. -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ScrolledWindow, DrawingArea, and setting step-increment
On Wed, Nov 13, 2013 at 4:44 AM, Gabriele Greco gabriele.gr...@darts.it wrote: I suggest you to use GtkTextView for your text output, thank to GtkTextTag it's flexible enough to do everything a mud client needs, also blinking text, it scrolls at line boundaries and let you keep thousands of lines of textbuffer without slowdowns. Hmm. I used to have something using that, in one of the early tests, but there was either a critical performance problem, or something I couldn't do with it. Can that handle mark-and-copy, clickable URLs, and so on? Or possibly it's that you say thousands there; to me, thousands of lines is just barely getting started. My current session in Gypsum has barely started and I already have 50K lines; my RosMud session currently has 300K lines of scrollback; and I've noted as an unsolvable RosMud bug that it's unacceptably slow adding the 16,777,216th line to the buffer (because it does a naive double-and-move-pointers operation). Unfortunately I don't have (or can't find) my notes on exactly what was wrong there, but there were some issues on Windows that I had to warp my code around. (Gypsum is slated as a replacement for RosMud, a Windows client, so it has to be at least plausibly equivalent in performance and functionality. Being awesome on Linux and abysmal on Windows isn't good enough.) I'm currently looking at whether it's worth bypassing the ScrolledWindow and simply putting an Hbox with the DrawingArea and a Scrollbar, and managing the scroll position myself. That might be easier, I don't know; is there a way to blit a DrawingArea's contents? I can't find anything. (It'd make scrolling a lot quicker and smoother if I could say move this bit here.) ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ScrolledWindow, DrawingArea, and setting step-increment
Hi! I hope this is the right place to ask this question.
I'm developing a MUD client in Pike, using GTK2 for the UI, and
there's an aspect of scrolling that's bugging me. The display uses
discrete lines of text of a fixed height (or, to be more technically
accurate, a fixed distance from the start of one line to the start of
the next), and I'd really like the scrolling to be done in lines
rather than pixels. Scrolling by two and a bit lines is ugly; I'd
rather scroll by exactly one line, or exactly three lines, or
something of the sort.
The full application can be found at https://github.com/Rosuav/Gypsum/
but here's a cut-down demo of what I'm talking about:
-- cut --
array colors=({ }),lines=({ });
GTK2.Adjustment scr;
GTK2.DrawingArea display;
int lineheight;
void scrchange()
{
scr-set_value(scr-get_property(upper)-scr-get_property(page size));
werror(step-increment: %O\n,scr-get_property(step-increment));
}
int paint(object self,object ev)
{
int start=ev-y-lineheight,end=ev-y+ev-height+lineheight;
GTK2.GdkGC gc=GTK2.GdkGC(display);
int y=(int)scr-get_property(page size);
foreach (lines,array line)
{
if (y=start y=end)
{
gc-set_foreground(line[0]);
display-draw_text(gc,3,y,line[1]);
}
y+=lineheight;
}
}
int main()
{
GTK2.setup_gtk();
foreach (00 FF 00FF00 00 FF FF00FF 00
FF/ ,string col)
colors+=({GTK2.GdkColor(@array_sscanf(col,%2x%2x%2x))});
GTK2.Window
mainwindow=GTK2.Window(GTK2.WindowToplevel)-set_title(Gypsum
Mini)-set_default_size(800,500);
mainwindow-add(GTK2.ScrolledWindow(([hadjustment:GTK2.Adjustment(),vadjustment:scr=GTK2.Adjustment()]))
-add(display=GTK2.DrawingArea())
)-show_all();
display-modify_font(GTK2.PangoFontDescription(Monospace 12));
lineheight=display-create_pango_layout(asdf)-index_to_pos(3)-height/1024;
mainwindow-signal_connect(delete_event,lambda() {exit(0);});
scr-signal_connect(changed,scrchange);
display-signal_connect(expose_event,paint);
for (int i=0;i1000;++i) lines+=({({random(colors[1..]),Hello,
world! +i})});
display-set_size_request(-1,(int)scr-get_property(page
size)+lineheight*(sizeof(lines)+1));
display-set_background(colors[0]);
display-queue_draw();
return -1;
}
-- cut --
Unfortunately, you probably don't have a Pike interpreter installed,
so this might well not work for you :( It works with the current
stable Windows build from
http://pike.lysator.liu.se/download/pub/pike/latest-stable/ and I've
been developing it using the current build of Pike on Linux. But
hopefully you'll be able to see what's going on despite the language
issues. If it's a problem, I could try porting the above code to
Python - would that help?
What I'd like to do is set the step-increment to be the calculated
lineheight. Unfortunately this doesn't work; the Adjustment
automatically resets its increments based on the height of the display
- as can be seen (if you can run the script) by resizing the window.
Is there a way to force it to use a particular value?
This code is, I believe, using gtk_scrolled_window_add_with_viewport
under the covers. Using an explicit Viewport doesn't seem to change
anything, and I can't see any events going through that would suggest
a point at which I could change the adjustment's increments.
Does anyone have any example code (in any language - I'm at least
passably fluent in Perl, C, C++, and Python, among others, and will be
happy to figure out code in a language I'm not familiar with) that
forces the increments? I've been searching on Google and have come up
with a few bits and bobs, but most work with DrawingArea seems to be
pixel-based, not line-based, so there's no problem with scrolling by
pixels.
Thanks in advance!
Chris Angelico
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
