This has been delayed for a while (maybe Q2 of next year?). We want to
refactor the PagingScrollTable and incorporate a ListModel/TreeModel that
would apply to multiple widgets and incorporate data binding. It will take
some time before anyone has enough time to start working on it.
Thanks,
John
Reviving this old thread ..
Has there been a decision on this yet? Just want to know if
PagingScrollTable is likely to make it to trunk in a future release.
--Sri
2009/10/9 Sri sripathikrish...@gmail.com
-- Forwarded message --
From: Bruce Johnson br...@google.com
Date:
We probably won't decide what to move into trunk until we get closer to the
next release. I'm working on improving our unit test coverage to make GWT
more stable, and most of the other UI developers are busy on their own
tasks. Sorry I don't have a better answer, but I'll escalate the fact that
Issue #188 has 40 stars, making it number seven in the issue list
(when sorted appropriately). Let's shoot for number one before John
gets back to working on it. ;-)
So if you're anxious for PST to leave the incubator, star this issue:
I was under the impression (based on conversations with GWT team
members) at Google I/O in May), that moving this into trunk for 2.0
was a sure thing. Has something changed?
I'll live if this has changed, I'd just like to know. Please...keep us
informed...
thanks,
jay
On Jul 16, 8:07 am,
Bump again? Any status?
thanks...
jay
On Jul 7, 8:40 am, jay jay.gin...@gmail.com wrote:
bump. Anything?
On Jun 24, 10:31 am, jay jay.gin...@gmail.com wrote:
Just curious if the effort has been resumed? Regardless, is there
anyway for you to commit what you do have somewhere we could
bump. Anything?
On Jun 24, 10:31 am, jay jay.gin...@gmail.com wrote:
Just curious if the effort has been resumed? Regardless, is there
anyway for you to commit what you do have somewhere we could look and
provide feedback?
thanks,
jay
On Jun 10, 8:28 am, John LaBanca jlaba...@google.com
Just curious if the effort has been resumed? Regardless, is there
anyway for you to commit what you do have somewhere we could look and
provide feedback?
thanks,
jay
On Jun 10, 8:28 am, John LaBanca jlaba...@google.com wrote:
@jay - I got side tracked with other tasks, but I'll pick up the
I'd definitely like to see the paging ability as an extension (read
that as you will: interface implementation, derived class, plug-in
behavior, whatever) to the scrolling behavior. I don't really like how
the incubator has two totally separate, unrelated classes.
I wonder if some performance
Hi,
I'd like to support this effort and would be glad if some of my
changes would make it into trunk:
- filters
- column types for most frequently used column types
(numbers,dates,text) including proper filtering, editing and sorting
capabilities
- simplified table generation ( see
I'll be the bad guy and try to lower expectations: whatever we end up doing,
it has to be fast. We've seen some *horrible* usability problems with fancy
tables -- even at a small number of rows -- and so don't be surprised if we
have to pare back features and reduce API flexibility to ensure that
@jay - I got side tracked with other tasks, but I'll pick up the
PagingScrollTable effort within a couple of weeks. The main goal when we
transfer the PagingScrollTable to GWT trunk is to separate the concept of
scrolling (with three distinct tables) from the rest of the code. That way,
we can
Re: Bruce's point about expectations and features vs. performance.
Has there been (or should we start) discussion for the public record
of different facets/features of tables, their impact on performance,
and their possible class structure? What I'm thinking of specifically
is bulk rendering vs.
Jay,
We are experiencing the same ideas here. We store column ordering and
widths on the server but we have no way of getting events in the UI to
know when changes have been complete.
wouldn't it be nice that the dnd was included as well, I could really
use the DND of columns! Was it hard to
We'll definitely keep these things in mind when moving stuff over to GWT
trunk. We've also found a lot of general usability problems, such as the
fact the the table doesn't layout naturally, which means apps require active
layout. During the transfer, we'll refactor quite a few things to make
Hi,
Another thing that would be usefull is that the table is not generated
in one big string and then inserted in the DOM in one call.
If the number of rows is big than this can take a long time.
In our project we do the rendering in larger chunks. We bulk generate
pages of rows and append a
I saw the initial commit of these classes into your branch, but I
haven't seen any additional commits. I'd love to take a look at the
current direction, and see what other input I can provide.
jay
On Jun 9, 7:12 am, John LaBanca jlaba...@google.com wrote:
We'll definitely keep these things in
17 matches
Mail list logo
