Quantcast

GLObservableList

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GLObservableList

Rob Eden
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

Rob Eden
Just noticed I used a StarLight Common class. You can get the jar for that here:


Rob

On Sat, Mar 16, 2013 at 5:04 PM, Rob Eden <[hidden email]> wrote:
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
In reply to this post by Rob Eden
Hey Rob,

I had a quick look at your adapter.
I think it looks great and straightforward.

I think a JavaFX extension would be the right place for this work.

Last month I had a small conversation with Jonathan Giles and Martin Sladecek from the JavaFX team
about creating an adapter between JavaFX observable list and GL EventList.
I think they are supportive of the idea, so if JavaFX specific questions arise, they might be able to help.

I think to fully bridge the two worlds we need to finish the work on providing the deleted/updated elements in GlazedLists.
Therefore I didn't start the JavaFX adapter yet, but now I'm glad you did ;-)

The next two weeks I don't have much free time,
but I'm about to finish migrating our tests to JUnit 4.

Stay tuned,
Holger


2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
In reply to this post by Rob Eden
Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
Hi Rob,

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob







JavaFX_adapter.patch (46K) Download Attachment
Clean_up_special_characters__Better_exception_message.patch (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
Thanks, Holger. I need to fix one thing in the next day or two. I just found out my usage of InvalidationListener was wrong. I'll get that to you ASAP.

As for the file cleanup, I'm not sure. I think all the problems were in comments. Maybe the comments should just be ASCII-fied? It's not preferable, but it's sure-fire and easy.

For particular characters we could link to their Unicode info page. For other stuff (like "rèsumè") we could use HTML character codes (eg, "re&eacute;sum&eacute;"). Ugly, I know, but works.

Rob

On Nov 17, 2013, at 8:13 AM, Holger Brands <[hidden email]> wrote:

Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

Rob Eden
Holger -

It looks like I do have commit ability (when I use SSH key auth... which I should have known).

I've fixed the issue with the incorrect usage of InvalidationListener. I believe the JavaFX stuff should be good to go at this point.

Here is the revision log if you would like to review:

Rob


On Sun, Nov 17, 2013 at 2:52 PM, Rob Eden <[hidden email]> wrote:
Thanks, Holger. I need to fix one thing in the next day or two. I just found out my usage of InvalidationListener was wrong. I'll get that to you ASAP.

As for the file cleanup, I'm not sure. I think all the problems were in comments. Maybe the comments should just be ASCII-fied? It's not preferable, but it's sure-fire and easy.

For particular characters we could link to their Unicode info page. For other stuff (like "rèsumè") we could use HTML character codes (eg, "re&eacute;sum&eacute;"). Ugly, I know, but works.

Rob

On Nov 17, 2013, at 8:13 AM, Holger Brands <[hidden email]> wrote:

Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob











Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
Ok, I see, makes sense.

Holger


2013/12/20 Rob Eden <[hidden email]>
Holger -

It looks like I do have commit ability (when I use SSH key auth... which I should have known).

I've fixed the issue with the incorrect usage of InvalidationListener. I believe the JavaFX stuff should be good to go at this point.

Here is the revision log if you would like to review:

Rob


On Sun, Nov 17, 2013 at 2:52 PM, Rob Eden <[hidden email]> wrote:
Thanks, Holger. I need to fix one thing in the next day or two. I just found out my usage of InvalidationListener was wrong. I'll get that to you ASAP.

As for the file cleanup, I'm not sure. I think all the problems were in comments. Maybe the comments should just be ASCII-fied? It's not preferable, but it's sure-fire and easy.

For particular characters we could link to their Unicode info page. For other stuff (like "rèsumè") we could use HTML character codes (eg, "re&eacute;sum&eacute;"). Ugly, I know, but works.

Rob

On Nov 17, 2013, at 8:13 AM, Holger Brands <[hidden email]> wrote:

Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob












Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
In reply to this post by hbrands
Hey guys,

I finally found some time to handle the file encoding issues.
All java source files should be UTF-8 now, and I changed the build accordingly.
I also set "text/plain; charset=UTF-8” as mime-type on all java source files.

Rob, could you check on your side if that fixes the encoding issues you had previously?

If yes, I'll publish a new snapshot soon...

Thanks,
Holger



2013/11/17 Holger Brands <[hidden email]>
Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob











Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

robeden
Yes, it behaved perfectly (I could build immediately without changes).

Thanks!
Rob

On Jan 12, 2014, at 2:54 PM, Holger Brands <[hidden email]> wrote:

Hey guys,

I finally found some time to handle the file encoding issues.
All java source files should be UTF-8 now, and I changed the build accordingly.
I also set "text/plain; charset=UTF-8” as mime-type on all java source files.

Rob, could you check on your side if that fixes the encoding issues you had previously?

If yes, I'll publish a new snapshot soon...

Thanks,
Holger



2013/11/17 Holger Brands <[hidden email]>
Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob












Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GLObservableList

hbrands
Administrator
Ok, thanks for checking.

I just published a new 1.10 snapshot to the maven snapshot repo.
As usual, it's also downloadable here:
https://java.net/projects/glazedlists/downloads/directory/latest_build

Holger



2014/1/13 Rob Eden <[hidden email]>
Yes, it behaved perfectly (I could build immediately without changes).

Thanks!
Rob

On Jan 12, 2014, at 2:54 PM, Holger Brands <[hidden email]> wrote:

Hey guys,

I finally found some time to handle the file encoding issues.
All java source files should be UTF-8 now, and I changed the build accordingly.
I also set "text/plain; charset=UTF-8” as mime-type on all java source files.

Rob, could you check on your side if that fixes the encoding issues you had previously?

If yes, I'll publish a new snapshot soon...

Thanks,
Holger



2013/11/17 Holger Brands <[hidden email]>
Hi Rob et al.,

I applied the JavaFX patch with a few modifications (like reformatting) and checked it in.
Looks good to me, many thanks!
Should I make the nested classes GLChangeWrapper and GLReorderChangeWrapper static (and final)?

Eclipse didn't accept the second patch, but I can convert the encoding manually.
But if I do, it doesn't compile under Windows anymore. I have to use the encoding attribute on the javac ant task to specify UTF-8.

So, should I go on and convert all java source files to UTF-8 and set "text/plain; charset=UTF-8” as mime type?

Feedback from all contributors is appreciated...

Thanks,
Holger



2013/11/5 Rob Eden <[hidden email]>
I would think the patches would apply, but let me know if they don't. I could also just put it in a BitBucket repo, if that would be easier to look at.

Rob

On Nov 5, 2013, at 1:02 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

that's great, thanks!
I'll have a look this week.
I hope I can apply the patches with Eclipse.

I'll let you know when it's integrated...

Holger





2013/11/4 Rob Eden <[hidden email]>
Hi Holger -

Ok, finally ready to hand over code for this. I’ve attached two patches. The first has the JavaFX adapter. It has full unit tests, but I haven’t modified the build file. There’s a (very small) demo class included as well.

The other cleans up some character problems I had checking out existing classes. For the AbstractTextSearchStrategy, GlazedListsImpl, and LatinDiacriticsStripper classes, the property “svn:mime-type” should be set to "text/plain; charset=UTF-8”, which should take care of those issues in the future.

I think it should be pretty straight-forward, but let me know if there’s anything that doesn’t work or you’d like me to do.

Rob




On Sep 17, 2013, at 2:27 PM, Rob Eden <[hidden email]> wrote:

Inline…

I'm fine with both options.
You can send me the files and I could create the javafx extension, check it in and integrate it into the build.
Or you could check in your work directly if you like that more.

Ok, I'll see how it goes.


So we would have a new 'javafx' extension directory under the existing 'extensions' directory.
I guess the root package for the extension would be "ca.odell.glazedlists.javafx"?

Yeah, that's what I was thinking.


I'd suggest to put a small example class into the same extension. If it is more like an internal test app I would put it under "test".
If we create a full-fledged demo app (like an JavaFX issue browser) I would put it under the 'issuebrowser' extension.

Ok. It'll probably be small. It might be small enough that it can just go in docs.


As the next version of Glazed Lists targets Java 1.6: can we agree to build and link against JavaFx 2.x ?

Yes. In fact, it will likely require it.


Currently, we download all tools and third-party libs we need for the build from
https://java.net/projects/glazedlists/downloads.
Should we do the same with the JavaFx runtime or do you see legal issues?

I think that will be fine, but I'll look at the JRE license to re-verify.



Thanks,
Holger



2013/9/17 Rob Eden <[hidden email]>
Hi Holger -

Ok, I'm back working on this.

It looks like I have commit capabilities in SVN (probably: I'm "Software Developer" role in java.net). Would you like me to check extension work in directly and then have you look at it or would you prefer if I send things to you and let you check in?

Also, I was thinking it would be nice to include a small example class. Assuming you're okay with that, would you put it under an "example" directory in the extension dir or somewhere else?

Rob

On Aug 6, 2013, at 10:40 AM, Rob Eden <[hidden email]> wrote:

Ok thanks, Holger. I've been off my JavaFX work for a while but expect to be back there working on that component in the relatively near term. When I am I'll make sure to allocate some time to make it distributable.

Rob

On Aug 6, 2013, at 9:49 AM, Holger Brands <[hidden email]> wrote:

Hey Rob,

to come back to your JavaFX adapter:

if you have time to cleanup your prototype, provide some JUnit 4 testcases and remove the dependency to StarLight Common
I would be happy to create a JavaFX extension and include it there as a starting point.

Thanks,
Holger

2013/3/16 Rob Eden <[hidden email]>
Hey guys -

I'd like to deep-bump an old thread last discussed a year ago:

The topic is dealing with ObservableList in JavaFX.

I'm now starting to move into JavaFX development myself and, frankly, I think whoever designed the models in JavaFX was a GlazedLists fan. There's clearly significant inspiration taken. Bottom line: (So far) I love it. It's exactly how I end up making my Swing code look.

However as discussed, they don't have transformations yet. So, I give you an experimental (!!!) wrapper for EventList to present an ObservableList interface:


Known limitations:
  • Not tested, documented, etc. Basically it's crap experimental code. (For future readers: really, please don't use this in production.)
  • I don't lock anything.
  • I have to use ListEvent.getOldValue(). Probably more just something to note than a limitation, per se.

When you run the main method in the class it will present a ListView<String> backed by: GLObservableList -> SortedList -> FilterList -> BasicEventList
  • SortedList: reverse sort by numerical value (Strings all contain integers)
  • FilterList: never show a number ending in "5".
  • BasicEventList: initially populated with 1-10. Every second a new number is added.
So, yeah. It works. Thoughts on approach? Would this be something we'd be interested in making an extension (once it's cleaned up, obviously).

Obviously threading is an issue just like it's always been in Swing. Events would need to be dispatching on the JavaFX Application thread, but I don't see anything different here than with how we do stuff for Swing. Other than that... seems pretty straight-forward.

Rob













Loading...