Re: [ve-dev] running sweet

[Mark Proctor <mproctor@xxxxxxxxxxxx>]

David,

Trying to understand what you mean by:
"With CompositeTable it is simple to create a checkbook registry type 
layout where some pair (or n) rows repeat. Just use a GridLayout to lay 
out your prototype row object however you like. "

Can merges as shown in the attached gif be achieved? Its not something I 
need now and I admit its an obscure use case, most likely it will be for 
inserting images.

Mark
David J. Orme wrote:
> Mark Proctor wrote:
>
> > virtual table stuff sounds great.
>
> Thanks!
>
> > With regards to merge I mean if you merge two cells, one above the 
> > other, or even a block of 4x4 cells. 
>
> Okay, I know what you mean now.
>
> With CompositeTable it is simple to create a checkbook registry type 
> layout where some pair (or n) rows repeat.  Just use a GridLayout to 
> lay out your prototype row object however you like.
>
> Horizontal merges are also possible by programming your row object to 
> handle that for you.
>
> But you can't just randomly merge cells vertically.
>
> > I'm guessing that veritcal or block cell merging can be done by 
> > placing a floating composite that covers the 4x4 cells as the 
> > rectangle top left and bottom right can be calculated - or maybe we 
> > only need to set its width and height and anchor the top and left. 
> > How would this compare GC based rendering performance? Any issues?
>
> That would be a real kludgy way to get the job done.  If 
> CompositeTable exposed more of its redraw events to the outside, you 
> could do it.
>
> But I really want to understand the use-case for doing this.  (In over 
> 10 years of database application programming, I've never seen a 
> use-case for this, so I have to admit that I'm stumped here.)
>
> Here's where I'm coming from:
>
> In any grid that is fundamentally editing rows from a collection or 
> ResultSet, you're going to have repeating groups of things where each 
> visual "thing" in the group represents a row in the 
> collection/resultset.  So it seems to me that at some level, you're 
> just going to model this whole collection of things as a row that can 
> repeat n times where n is determined by the amount of visible space.  
> Within that row, you might merge vertical cells, which you can do 
> today in CompositeTable by using a GridLayout/GridData with 
> verticalSpan > 1 on appropriate objects.  But I don't understand the 
> use-case for merging vertical cells across boundaries that represent 
> rows in your collection.
>
> > jxtable is a nice open source jtable implementation, that has some 
> > extra features like frozen columns:
> > http://xframe.sourceforge.net/swing/jxtable.html
>
> Yes.  Frozen columns would be very nice.  CompositeTable currently 
> don't handle the case where you need to scroll horizontally.  Right 
> now it makes your columns fit exactly in the visible space and 
> allocates each column a programmer-specified percentage of the 
> whole--which works fine for 80% of the cases.  But there are the 20% 
> that need to scroll horizontally and this still needs work.
>
>
> Regards,
>
> Dave Orme