First, I am totally new to Fan. I just read Stephen C's intro to it a while back and my conclusion was that the creator(s) of Fan and I have a very similar way of thinking. So I really hope Fan will take off!
I'm wondering if you will, or maybe have already, chosen how to do GUIs with Fan? I'm the creator of MigLayout, a very flexible and easy to use (IMO), LayoutManager for Java (Swing and SWT). I think it would be a perfect fit for something like Fan since it is very pragmatic, short in syntax and basically all you need. I won't reiterate its features here though. www.miglayout.com has all the details.
Maybe you are aiming to just leverage Swing as it is, I don't know, but maybe there's a way that you can make GUIs easier/faster to create if you somehow work with MigLayout.
Let me know what's cooking in the GUI department and I'll see what can be done.
Cheers, Mikael Grev
brianMon 22 Dec 2008
Hi Mikael,
I'm definitely familiar with MIG - very nice to hear from you.
Bit of background on what is there today. The fwt is a Fan API that starts with a clean slate for defining a nice, elegant API for the widget toolkit. Behind the scenes we ported the fwt to SWT to get started. I don't think I will directly do a port to Swing (too many Swing battle scars in my past), although I would be very supportive of working with other contributors to get a fwt port to Swing merged upstream. On the .NET side we will probably use one of the .NET UI technologies to get support for Silverlight. Because we want to keep the fwt portable, the layout strategy is separate from the widget port. Layout managers are written in Fan and work against the Fan widget APIs. Unlike Swing, a "layout manager" is just a normal subclass of fwt::Pane.
We've currently only do a few panes right now - simple ones like InsetPane, GridPane, and EdgePane (like border pane). Andy and I have had some discussions about a more general purpose pane for layout - but it hasn't been a high priority. But if we had something like Mig for Fan that is definitely something to consider. My criteria for getting it standardized in the fwt pod itself would have to be a API with a small surface area (preferably one public class) - something like MIG might be well suited to that using strings and not exposing all the other stuff. And we'd want something nicely serializable using Fan's text serial format.
So what do you think of a MIG port to Fan for the fwt?
mikaelgrevMon 22 Dec 2008
Hello Brian,
MigLayout is made from start to be portable. 95% of the code is plain Java with no dependencies to any GUI toolkit. The GUI specific dependencies are managed through implmentations of three Interfaces: MigLayout (the LayoutManager2 implementation in Swing. Layout in SWT), ComponentWrapper and ContainerWrapper.
So, the effort of converting it to native Fan code should be minimal, maybe even trivial. A MigPane would be the layout manager impl and the interface calls to the component/container proxys could just be replaced with real calls to your GUI classes.
There's a little cruft that can be removed from MIG. For instance there are an API version of those string constraints that wouldn't fit Fan I think. I just created it to shut up the "we hate strings for whatever reason"-crowd. ;)
I don't know what would be needed to support serialization in Fan but since it works today with XMLEncoder/Decoder I think there shouldn't be any problems. It would probably even be less of a problem since the constraint classes could probably be serialized directly.
I think the effort would be a lot less for someone knowing Fan to port it than for me to learn Fan and then port it. After instructions from me it could probably be done in an afternoon, at least if it is as I think, which is that Fan kind of accepts Java syntax to some degree. I have intended to write a "Porting Guide" anyway and I can probably get my thumbs out faster if I know someone is actualy waiting for it.. :)
Since I have put a lot of effort into making MigLayout be both good and portable I think that it would be a waste of effort to recreate a new layout engine in Fan instead of just converting MigLayout.
Cheers, Mikael
brianTue 23 Dec 2008
OK - thanks Mikael. I think the string only constraints would be fine myself. Serialization pretty much comes for free in Fan, so I doubt that would be a problem. Andy and I are pretty busy getting SkyFoundry started which is why the fwt isn't a top priority right now, but we'll need to dig into MigLayout when we get back into the fwt.
mikaelgrevTue 23 Dec 2008
Excellent Brian,
Let me know when you get back to fwt. I'll help out if you are interested in MigLayout.
If you are interested I'll even look over the APIs of fwt (unless they are set in stone). I have quite long experience with Swing and know its pros and cons, both performance and API wise. At a first glance the API looks good though. :)
Cheers, Mikael
brianTue 23 Dec 2008
If you are interested I'll even look over the APIs of fwt (unless they are set in stone)
Please share any feedback you have on the APIs - nothing is set in stone.
mikaelgrev Mon 22 Dec 2008
Hello developers of this excellent language!
First, I am totally new to Fan. I just read Stephen C's intro to it a while back and my conclusion was that the creator(s) of Fan and I have a very similar way of thinking. So I really hope Fan will take off!
I'm wondering if you will, or maybe have already, chosen how to do GUIs with Fan? I'm the creator of MigLayout, a very flexible and easy to use (IMO), LayoutManager for Java (Swing and SWT). I think it would be a perfect fit for something like Fan since it is very pragmatic, short in syntax and basically all you need. I won't reiterate its features here though. www.miglayout.com has all the details.
Maybe you are aiming to just leverage Swing as it is, I don't know, but maybe there's a way that you can make GUIs easier/faster to create if you somehow work with MigLayout.
Let me know what's cooking in the GUI department and I'll see what can be done.
Cheers, Mikael Grev
brian Mon 22 Dec 2008
Hi Mikael,
I'm definitely familiar with MIG - very nice to hear from you.
Bit of background on what is there today. The fwt is a Fan API that starts with a clean slate for defining a nice, elegant API for the widget toolkit. Behind the scenes we ported the fwt to SWT to get started. I don't think I will directly do a port to Swing (too many Swing battle scars in my past), although I would be very supportive of working with other contributors to get a fwt port to Swing merged upstream. On the .NET side we will probably use one of the .NET UI technologies to get support for Silverlight. Because we want to keep the fwt portable, the layout strategy is separate from the widget port. Layout managers are written in Fan and work against the Fan widget APIs. Unlike Swing, a "layout manager" is just a normal subclass of
fwt::Pane
.We've currently only do a few panes right now - simple ones like InsetPane, GridPane, and EdgePane (like border pane). Andy and I have had some discussions about a more general purpose pane for layout - but it hasn't been a high priority. But if we had something like Mig for Fan that is definitely something to consider. My criteria for getting it standardized in the fwt pod itself would have to be a API with a small surface area (preferably one public class) - something like MIG might be well suited to that using strings and not exposing all the other stuff. And we'd want something nicely serializable using Fan's text serial format.
So what do you think of a MIG port to Fan for the fwt?
mikaelgrev Mon 22 Dec 2008
Hello Brian,
MigLayout is made from start to be portable. 95% of the code is plain Java with no dependencies to any GUI toolkit. The GUI specific dependencies are managed through implmentations of three Interfaces: MigLayout (the LayoutManager2 implementation in Swing. Layout in SWT), ComponentWrapper and ContainerWrapper.
So, the effort of converting it to native Fan code should be minimal, maybe even trivial. A MigPane would be the layout manager impl and the interface calls to the component/container proxys could just be replaced with real calls to your GUI classes.
There's a little cruft that can be removed from MIG. For instance there are an API version of those string constraints that wouldn't fit Fan I think. I just created it to shut up the "we hate strings for whatever reason"-crowd. ;)
I don't know what would be needed to support serialization in Fan but since it works today with XMLEncoder/Decoder I think there shouldn't be any problems. It would probably even be less of a problem since the constraint classes could probably be serialized directly.
I think the effort would be a lot less for someone knowing Fan to port it than for me to learn Fan and then port it. After instructions from me it could probably be done in an afternoon, at least if it is as I think, which is that Fan kind of accepts Java syntax to some degree. I have intended to write a "Porting Guide" anyway and I can probably get my thumbs out faster if I know someone is actualy waiting for it.. :)
Since I have put a lot of effort into making MigLayout be both good and portable I think that it would be a waste of effort to recreate a new layout engine in Fan instead of just converting MigLayout.
Cheers, Mikael
brian Tue 23 Dec 2008
OK - thanks Mikael. I think the string only constraints would be fine myself. Serialization pretty much comes for free in Fan, so I doubt that would be a problem. Andy and I are pretty busy getting SkyFoundry started which is why the fwt isn't a top priority right now, but we'll need to dig into MigLayout when we get back into the fwt.
mikaelgrev Tue 23 Dec 2008
Excellent Brian,
Let me know when you get back to fwt. I'll help out if you are interested in MigLayout.
If you are interested I'll even look over the APIs of fwt (unless they are set in stone). I have quite long experience with Swing and know its pros and cons, both performance and API wise. At a first glance the API looks good though. :)
Cheers, Mikael
brian Tue 23 Dec 2008
Please share any feedback you have on the APIs - nothing is set in stone.