[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ve-dev] running sweet
|
CompositeTable only creates the number of Composites necessary to
display the visible rows. Then it shuffles them around in order to
implement scrolling, insert/delete, etc.
Advantages: You can use any SWT control in any cell. You can use any
SWT layout in a row to get just about any appearance you can imagine.
If you use a null layout the CompositeTable will make your controls into
a tabular layout for you (ie: it supplies the layout manager if you
don't explicitly set one). It's fast and feels native because it uses
native controls in each cell even though the table itself isn't native.
There really is no functional disadvantage because you can always create
custom controls that draw whatever you want on a GC and include them in
your prototype row Composite. So you can get KTable-like behaviors too.
On Windows, KTable would probably perform slightly better than
CompositeTable because lightweight drawing works best in GDI. On
X-Windows, CompositeTable flies though because scrolling is normally
just moving native O/S controls around, and a lot of that can happen
directly on the X server where the X server can optimize the refresh for
you.
Regards,
Dave Orme
Mark Proctor wrote:
Looking at the table implementations CompositeTable uses composites
for each row where as KTable seems to use GC to draw everything. How
do these two implementations compare, ie advantages of one over the
other. The GC technique means it only draws what it has to based on a
"visibility" method to determine visible data, ie virtual tables. How
would composite achieve this. I'm trying to determine if
CompositeTable is a better approach than using GC to render each
individual visible cell.
Mark
David J. Orme wrote:
The sweet1 stuff is a data binding implementation. It has more
abstraction than JGoodies and also has more defaults set, so you can
learn about the abstractions incrementally as you go along.
Sweet 2/3 are prototypes of "bridge" APIs (to use Gili's terminology)
to surface the sweet1 stuff as Eclipse Platform API. We started
working with the JFace team today on this.
At this point, the only thing that is settled is that we are all
going to make a concerted effort to have some sort of simple data
binding API in Eclipse for 3.2.
Best regards,
Dave Orme
Mark Proctor wrote:
starting to understand the sweet implementation, haven't looked at
sweet2/3 yet. Just read the jgoodies binding framework presentation
- http://www.jgoodies.com/articles/binding.pdf - has anyone looked
at that presentation/framework? how does this stuff compare?
Mark
David J. Orme wrote:
Mark Proctor wrote:
Two frameworks? In the source how do I know which framework is
which? I've seen there is sweet1, sweet2 and sweet3. Also are
there any quick ramblings on how these work, to help when delving
into the code?
sweet is my stuff; sweet2/3 is Gili's team's work.
Look for packages ending in .test for (basic) examples.
Regards,
Dave
Mark
David J. Orme wrote:
Mark Proctor wrote:
Ah thats what you get for skim reading :)
I'm spending some time now trying to work out how this data
binding stuff works. The Binding Proof of Concept doesn't use
the CompositeTable right and is the only current working
example? Once I've figured out how this works I'm going to see
if its possible to shoe horn ktable into this. Well atleast
thats the theory, if I can get enough time :)
FYI: There are actually two frameworks here.
Mine is complete for all the use-cases it currently implements,
works, and is deployed at two clients of mine--parts for over six
months now and over a hundred sites. CompositeTable is a part of
my framework. Gili's is a spike solution sketching out some of
the API for how you could do a binding framework on top of JFace.
Stay tuned for how each framework will eventually be
used/deployed. We're right now in the process of working that out.
Regards,
Dave Orme
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
--
Objects are here to stay. http://www.db4o.com
PGP Public Key (for confidential communications):
http://www.coconut-palm-software.com/~djo/public_key.txt