[prev in list] [next in list] [prev in thread] [next in thread] 

List:       berlin-design
Subject:    Re: [Berlin-design] TreeView widget design
From:       Ben Bucksch <benb () berlin-consortium ! org>
Date:       2002-03-01 5:03:44
[Download RAW message or body]

How about that:

In the Kit, we offer to create (in the server) a special dummy node, 
which just fills out one row or column (no matter how many cells).
With the appropriate number of dummy nodes, this would allow the server 
to display the scrollbar correctly (give the illusion that the list is 
filled with all entries).

50k remote CORBA calls are probably still too much, so we could also 
offer to create a block of dummy nodes at once, which the application 
can then insert into the list/table/tree. That way, the app can create a 
list with 50k entries with just 2 or so CORBA calls. The server, knowing 
that it's just a block of dummy nodes, can also optimize internally.

The application can then replace the dummy nodes with real ones whenever 
it pleases. The app can also leave holes - e.g. even the user quickly 
scrolls down to the end, the app could just fill out the last few 
entries in addition to the first ones, leaving a big block of dummy 
nodes in the middle (which the user didn't really look at yet). Because 
we offer single dummy nodes, too, the app can do the same on a smaller 
scale with only a few dummy nodes (e.g. when implementing an image browser).

Then, we only have to give hints to the app, when it has to replace the 
dummy nodes with real ones. Maybe simply an observer for the current 
visible area.

This means that we won't have Berlin's advantage of responsiveness, 
because the app has to calculate and transfer the entries during/after 
the user scrolles/d. But that's inherent to the problem, I think.

This approach should also work for spreadsheets, which try to be 
practically endless. That would be cool, because the spreadsheet might 
then be able to use our standard table widget and doesn't have to create 
its own. (Which would give the usual advantages of consistency and 
customizability.)


Florin Boariu wrote in Sep. 2001:

> There's something more I've been missing on treeview-implementations so
> far.
>
> I'm currently working on a library management tool. Basically, it's a
> MySQL backend with a Qt frontend (the frontend being a generic DB browser,
> so you can actually manage _anything_ including but not limited to books
> [;)]
>
> However, one of the biggest problem I'm facing is that realtime search is
> very hard to archieve. ("Realtime search": show the user all database
> entries and let him refine his search on every key strike -- you
> basically have an edit field and a result list. the result list gets
> smaller with every letter you type in the edit field).
>
> The problem arrives with very big search results (like "SELECT * FROM
> whatever"): Qt simply has problems inserting 10k entries (list items) in
> real time, which is understandable. The other problem is that somewhere
> around 50k db entries start to eat up all system memory.
>
> The sollution to this problem would be a partially-loaded list, that is a
> list, which virtually contains 10k elements but only has about 20 or 30
> visible, and -- let's say -- about 100 actually ready-to-show (=> loaded
> into memory) the rest of them (about 9900) should still be on disk.
>
> It's not possible to do this with Qt's TreeView, unless you use some
> magic.
>
> I'm not quite sure how one could fix this problem, probably by providing
> some index values for every item (0..x) and then calling some function
> loadItems(from,to) or prepareItems(from,to)...
>
> I realize this problem is probably not of much concern to anyone but me,
> but I thought I'd just throw my $0.02 in [;)]
>


Stefan Seefeld's reply:

> Florin Boariu wrote:
>
>> The sollution to this problem would be a partially-loaded list, that 
>> is a
>> list, which virtually contains 10k elements but only has about 20 or 30
>> visible, and -- let's say -- about 100 actually ready-to-show (=> loaded
>> into memory) the rest of them (about 9900) should still be on disk.
>>
>> It's not possible to do this with Qt's TreeView, unless you use some
>> magic.
>
> Well, I think this kind of think won't be possible with "any" kind of 
> TreeView,
> not if you restrict the discussion to the GUI part. To do the 'magic' 
> as you are
> calling it, the application has to do its part. This is precisely the 
> point
> we are currently discussing, i.e. how to hook up domain specific 
> application
> logic to the GUI to be able to create the illusion of a single big list.
>
>> I'm not quite sure how one could fix this problem, probably by providing
>> some index values for every item (0..x) and then calling some function
>> loadItems(from,to) or prepareItems(from,to)...
>
> A way to appraoch this problem may be a way to define 'distance' to the
>
> unloaded items, and then load them as the distance gets smaller. I'm 
> thinking
> of some intelligence such as the kernel's memory management, i.e. 
> where pages
> are mapped in and out depending on some heuristics about their usage.
>
> But that's just a very rough idea...
> [...]
> PS: editors and viewers of large documents will face the same problem 
> when
>     it comes to caching often visited (viewed) parts.



_______________________________________________
Berlin-design mailing list
Berlin-design@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/berlin-design

[prev in list] [next in list] [prev in thread] [next in thread]