Qt-interest Archive, May 2008
displaying huge amounts of text
Message 1 in thread
I'm new to Qt (using 4.4.0), and I've reached a bit of a stumbling
block. I'm writing a log file viewer, and I want to display a
potentially enormous amount of text (10+ GB). It looks like a
QPlainTextEdit is what I'm looking for, except that it seems to want me
to load up the entire contents with setPlainText/appendPlainText.
Although the file itself is huge, a user is only going to be looking at
a tiny fraction of it, so it makes more sense for me to leave the data
where it is (in a database), and generate just the lines of text the
user needs based on the visible region.
Unfortunately, I don't see any way to make QPlainTextEdit scroll over a
region much larger than the amount of text it's currently holding and
call some sort of update function each time the scrollbar moves. It
looks like I could write my own subclass of QAbstractScrollArea, but
don't particularly want to re-implement the rest of QPlainTextEdit's
functionality, either. QTextDocument looked promising, but I'm not
really sure how to use it.
Any suggestions?
Thanks,
Jeff
--
[ signature omitted ]
Message 2 in thread
Hi Jeff,
"Jeff Gibson" <jsg72@xxxxxxx> wrote in message
news:482375D4.7030204@xxxxxxxxxx
> I'm new to Qt (using 4.4.0), and I've reached a bit of a stumbling block.
> I'm writing a log file viewer, and I want to display a potentially
> enormous amount of text (10+ GB). It looks like a QPlainTextEdit is what
> I'm looking for, except that it seems to want me to load up the entire
> contents with setPlainText/appendPlainText. Although the file itself is
> huge, a user is only going to be looking at a tiny fraction of it, so it
> makes more sense for me to leave the data where it is (in a database), and
> generate just the lines of text the user needs based on the visible
> region.
That seems sensible, yes. Loading up such a huge amount of text is not a
good solution.
> Unfortunately, I don't see any way to make QPlainTextEdit scroll over a
> region much larger than the amount of text it's currently holding and call
> some sort of update function each time the scrollbar moves. It looks like
> I could write my own subclass of QAbstractScrollArea, but don't
> particularly want to re-implement the rest of QPlainTextEdit's
> functionality, either. QTextDocument looked promising, but I'm not really
> sure how to use it.
I think it depends on what it is that you *exactly* want. To me, it sounds
like the model/view architecture might be what you are looking for. However,
it depends on what you want to show, I guess. If the text you are talking
about is really something like logs, instead of running text, it may be a
good idea to try to build a model to wrap your data backend, and attach it
to one of the standard views. It would allow you to just retreive what you
need, and not more than that.
However, if you need bigger pieces of text, it may be that you would end up
also building a specialized view, which could be a lot of work.
I don't know enough about QTextDocument to give you advise on that. I would
guess that it may not be geared towards displaying such a huge amount of
data.
You also should, IMHO, considder how your users are going to navigate
through that huge amount of data. Let me tell you: a scrollbar is not going
to cut it. If a page is about four thousand characters, you may have up to a
quarter of a million pages full of text. That means that each pixel in a
scollbar of a window a thousand pixels high is going to scroll about 250
pages.
HTH,
André
--
[ signature omitted ]
Message 3 in thread
Thanks for your help. The model/view thing sounds promising. I'm not
familiar with how it works in Qt, but I can read up on that. If none
of the views are specific to text, I'd probably be stuck re-
implementing text features like selection and copy/paste, though.
I agree with you about the scrollbar not being a good navigation tool
for something that big. I have other data views in the interface that
will handle most of the navigation.
Thanks,
Jeff
On May 9, 2008, at 12:02 AM, André Somers wrote:
> Hi Jeff,
>
> "Jeff Gibson" <jsg72@xxxxxxx> wrote in message news:482375D4.7030204@xxxxxxx
> ...
>> I'm new to Qt (using 4.4.0), and I've reached a bit of a stumbling
>> block. I'm writing a log file viewer, and I want to display a
>> potentially enormous amount of text (10+ GB). It looks like a
>> QPlainTextEdit is what I'm looking for, except that it seems to
>> want me to load up the entire contents with setPlainText/
>> appendPlainText. Although the file itself is huge, a user is only
>> going to be looking at a tiny fraction of it, so it makes more
>> sense for me to leave the data where it is (in a database), and
>> generate just the lines of text the user needs based on the visible
>> region.
>
> That seems sensible, yes. Loading up such a huge amount of text is
> not a good solution.
>
>> Unfortunately, I don't see any way to make QPlainTextEdit scroll
>> over a region much larger than the amount of text it's currently
>> holding and call some sort of update function each time the
>> scrollbar moves. It looks like I could write my own subclass of
>> QAbstractScrollArea, but don't particularly want to re-implement
>> the rest of QPlainTextEdit's functionality, either. QTextDocument
>> looked promising, but I'm not really sure how to use it.
>
> I think it depends on what it is that you *exactly* want. To me, it
> sounds like the model/view architecture might be what you are
> looking for. However, it depends on what you want to show, I guess.
> If the text you are talking about is really something like logs,
> instead of running text, it may be a good idea to try to build a
> model to wrap your data backend, and attach it to one of the
> standard views. It would allow you to just retreive what you need,
> and not more than that.
>
> However, if you need bigger pieces of text, it may be that you would
> end up also building a specialized view, which could be a lot of work.
>
> I don't know enough about QTextDocument to give you advise on that.
> I would guess that it may not be geared towards displaying such a
> huge amount of data.
>
> You also should, IMHO, considder how your users are going to
> navigate through that huge amount of data. Let me tell you: a
> scrollbar is not going to cut it. If a page is about four thousand
> characters, you may have up to a quarter of a million pages full of
> text. That means that each pixel in a scollbar of a window a
> thousand pixels high is going to scroll about 250 pages.
>
> HTH,
>
> André
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx
> with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
--
[ signature omitted ]
