sweet-swt-develop Mailing List for Sweet
Status: Beta
Brought to you by:
dvorme
Menu
▾
▴
sweet-swt-develop — Sweet developer mailing list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(8) |
Apr
(12) |
May
(2) |
Jun
(11) |
Jul
(8) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Dave O. <Da...@AS...> - 2004-11-15 16:16:02
|
Sweet-interested developers: I wanted to drop you guys a brief note to say that the XSWT part of Sweet is alive, very well, and has a small but active developer community over at xswt.sourceforge.net. If you're interested, you might want to come join the xswt-developer mailing list so you can keep up on what's going on. Best regards, Dave Orme XSWT project lead/maintainer |
|
From: Gerald B. <lux...@ya...> - 2004-04-03 09:22:20
|
Hello, Meetup.com - a site that helps in organizing local interest groups - has opened up a XUL chapter. Now you can join and link up with fellow XUL coders and designers at local cafes (and other places) in 612 cities across 51 countries. Every 1st Tuesday of every month is now officially International XUL Meetup Day! Meetup with other local XML UI Language (XUL) coders and designers to discuss the future of the rich internet for everyone. Full story @ http://xul.meetup.com - Gerald PS: I will try to organize a first XUL coder and designer meeting in Vienna, Austria in May. See you there. ------------------- Gerald Bauer Open XUL Alliance - A Rich Internet For Everyone | http://xul.sourceforge.net XUL News Wire | http://news.gmane.org/gmane.comp.lang.xul.announce ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
|
From: Dave O. <Da...@AS...> - 2003-08-22 18:44:16
|
Try my home email: dj...@co... <mailto:dj...@co...> -----Original Message----- From: Mark S. Millard [mailto:mmi...@vi...] Sent: Wednesday, August 20, 2003 3:02 PM To: swe...@li... Subject: RE: [Sweet-swt-develop] Direct Contact for Dave Orme? Sorry, Dave, but my email to Da...@AS... <mailto:Da...@AS...> never gets delivered. Is there an alternative email address? -----Original Message----- From: swe...@li... [mailto:swe...@li...] On Behalf Of Dave Orme Sent: Wednesday, August 13, 2003 1:21 PM To: 'swe...@li...' Subject: RE: [Sweet-swt-develop] Direct Contact for Dave Orme? I have a .zip file full of examples on how to write simple Sweet programs. They are for the purpose of learning Sweet. Excellent! I am still struggling with a few issues and was hoping that you could take a look and them. After the examples are solid enough, I will then submit them for general distribution. Please email them to me directly along with your questions and I'll have a look. Best regards, Dave Orme |
|
From: Mark S. M. <mmi...@vi...> - 2003-08-22 02:35:25
|
Sorry, Dave, but my email to Da...@AS... never gets delivered. Is there an alternative email address? -----Original Message----- From: swe...@li... [mailto:swe...@li...] On Behalf Of Dave Orme Sent: Wednesday, August 13, 2003 1:21 PM To: 'swe...@li...' Subject: RE: [Sweet-swt-develop] Direct Contact for Dave Orme? I have a .zip file full of examples on how to write simple Sweet programs. They are for the purpose of learning Sweet. Excellent! I am still struggling with a few issues and was hoping that you could take a look and them. After the examples are solid enough, I will then submit them for general distribution. Please email them to me directly along with your questions and I'll have a look. Best regards, Dave Orme |
|
From: Dave O. <Da...@AS...> - 2003-08-13 19:30:58
|
I have a .zip file full of examples on how to write simple Sweet programs. They are for the purpose of learning Sweet. Excellent! I am still struggling with a few issues and was hoping that you could take a look and them. After the examples are solid enough, I will then submit them for general distribution. Please email them to me directly along with your questions and I'll have a look. Best regards, Dave Orme |
|
From: Mark S. M. <mmi...@vi...> - 2003-08-12 21:17:03
|
Sorry about sending this out to everyone. Please ignore if you are not Dave Orme. Dave, I have a .zip file full of examples on how to write simple Sweet programs. They are for the purpose of learning Sweet. I am still struggling with a few issues and was hoping that you could take a look and them. After the examples are solid enough, I will then submit them for general distribution. Thanks for any help you can provide. ---------------------------------------------- Mark Millard, Software Architect Vidiom Systems E-mail: mmi...@vi... Phone: (303) 604-0800 x119 |
|
From: Mark M. <mmi...@vi...> - 2003-07-31 23:40:25
|
Thanks for your prompt reply. I'll put together some reasonably small examples that can be used for learning Sweet. I don't know if I'll have time to write the accompanying documentation/tutorial but I'll see what I can put together. The first example I'm working on is a simple String Property Editor. For example, something that could be used to change a password. -----Original Message----- From: swe...@li... [mailto:swe...@li...] On Behalf Of Dave Orme Sent: Thursday, July 31, 2003 1:29 PM To: 'swe...@li...' Subject: RE: [Sweet-swt-develop] (no subject) I am evaluating Sweet for a GUI Builder that is applicable to the interactive TV industry. Specifically it is for the OpenCable Application Platform (OCAP). See http://www.opencable.com/ocap.html for more information concerning this technology. If we choose to use Sweet, we plan to put a significant amount of editor components back into the Sweet community. Excellent! Are there any examples on how to write Sweet-compliant components? I'll be committing a starter palette to CVS today. Basically, you create a BeanInfo that extends OverrideComponentInfo, then edit the BeanInfo data structure inside your constructor. The BeanInfo class I have right now are really minimal and still need a bunch of work to function optimally. Look for a "Palette" project to appear in CVS later today or early tomorrow. I am struggling, trying to use the PropertyTable mechanism. PropertyTable is a property editor SWT control that is designed to be used either inside of or outside of Eclipse. It is just a helper class that makes it easier to write a property editor for Sweet-based SWT controls. It depends on a couple of Eclipse classes (mainly StructuredSelection and its dependants), so you'll need to grab those if you want your code to work outside Eclipse. Off the top of my head, here's what your GUI builder needs to do: (I'm assuming here that you're already familiar with the JFace viewer framework. If not, then I have an example of using a JFace table at: http://www.swtworkbench.com/community/bin/index.cgi?action=viewnews <http://www.swtworkbench.com/community/bin/index.cgi?action=viewnews&id= 8> &id=8) 1) Implement IPropertyEditorFactory and register it with your instance of PropertyTable. This class takes an IStructuredSelection of objects and returns an array of IEditableProperty objects (your own implementation--see below). It's analogous to the JFace IContentProvider in that it takes your GUI builder's data structure for a SWT component and returns the list of properties that are editable on that component. 2) Create your own implementation of IEditableProperty. This will be the class returned by your IPropertyEditorFactory. There are two issues here: (a) GUI-builder specific mechanisms for getting/setting property values and (b) undo/redo management. (a) is pretty self-explanatory. The reasoning behind (b) is as follows: Since each GUI builder will handle undo/redo differently, the property object must be reimplemented by each GUI builder in order to register property value changes with the GUI builder's individual undo/redo stack. 3) Use Eclipse's StructuredSelection objects to manage your GUI builder's current selection. When the selection changes, your property table view (or whatever your equivalent thing is that is listening to selection change events) will call PropertyTable.setInput() (again, just like JFace). 4) Property editors are managed by the PropertyEditorFactory class. This is a static class that manages the property editor registry and retrieves property editor classes on request using an algorithm similar to the one in the original JavaBeans specification/implementation. By convention, property editors for built-in classes are registered in a static initializer block at the bottom of this class. From this block, you can see what property editors are currently implemented for what types and how they work. I think that's about it. The property editor table is the part of Sweet under the most heavy development and as a result is badly under-documented, so I'm not surprised that it's been tough to use. If after pursuing the above you have a more specific question, I'll be glad to try to help. But I hope this gets you started. I know this all needs to be documented somewhere. ;-} I guess Sweet is no different from most other open-source projects in that it tends to value innovation over documentation. ;-) I look forward to working together! Once you've gotten your mind wrapped around this, let's talk some more about what you'd like to do. Best regards, Dave Orme |
|
From: Dave O. <Da...@AS...> - 2003-07-31 19:29:04
|
I am evaluating Sweet for a GUI Builder that is applicable to the interactive TV industry. Specifically it is for the OpenCable Application Platform (OCAP). See http://www.opencable.com/ocap.html <http://www.opencable.com/ocap.html> for more information concerning this technology. If we choose to use Sweet, we plan to put a significant amount of editor components back into the Sweet community. Excellent! Are there any examples on how to write Sweet-compliant components? I'll be committing a starter palette to CVS today. Basically, you create a BeanInfo that extends OverrideComponentInfo, then edit the BeanInfo data structure inside your constructor. The BeanInfo class I have right now are really minimal and still need a bunch of work to function optimally. Look for a "Palette" project to appear in CVS later today or early tomorrow. I am struggling, trying to use the PropertyTable mechanism. PropertyTable is a property editor SWT control that is designed to be used either inside of or outside of Eclipse. It is just a helper class that makes it easier to write a property editor for Sweet-based SWT controls. It depends on a couple of Eclipse classes (mainly StructuredSelection and its dependants), so you'll need to grab those if you want your code to work outside Eclipse. Off the top of my head, here's what your GUI builder needs to do: (I'm assuming here that you're already familiar with the JFace viewer framework. If not, then I have an example of using a JFace table at: http://www.swtworkbench.com/community/bin/index.cgi?action=viewnews <http://www.swtworkbench.com/community/bin/index.cgi?action=viewnews&id=8> &id=8) 1) Implement IPropertyEditorFactory and register it with your instance of PropertyTable. This class takes an IStructuredSelection of objects and returns an array of IEditableProperty objects (your own implementation--see below). It's analogous to the JFace IContentProvider in that it takes your GUI builder's data structure for a SWT component and returns the list of properties that are editable on that component. 2) Create your own implementation of IEditableProperty. This will be the class returned by your IPropertyEditorFactory. There are two issues here: (a) GUI-builder specific mechanisms for getting/setting property values and (b) undo/redo management. (a) is pretty self-explanatory. The reasoning behind (b) is as follows: Since each GUI builder will handle undo/redo differently, the property object must be reimplemented by each GUI builder in order to register property value changes with the GUI builder's individual undo/redo stack. 3) Use Eclipse's StructuredSelection objects to manage your GUI builder's current selection. When the selection changes, your property table view (or whatever your equivalent thing is that is listening to selection change events) will call PropertyTable.setInput() (again, just like JFace). 4) Property editors are managed by the PropertyEditorFactory class. This is a static class that manages the property editor registry and retrieves property editor classes on request using an algorithm similar to the one in the original JavaBeans specification/implementation. By convention, property editors for built-in classes are registered in a static initializer block at the bottom of this class. From this block, you can see what property editors are currently implemented for what types and how they work. I think that's about it. The property editor table is the part of Sweet under the most heavy development and as a result is badly under-documented, so I'm not surprised that it's been tough to use. If after pursuing the above you have a more specific question, I'll be glad to try to help. But I hope this gets you started. I know this all needs to be documented somewhere. ;-} I guess Sweet is no different from most other open-source projects in that it tends to value innovation over documentation. ;-) I look forward to working together! Once you've gotten your mind wrapped around this, let's talk some more about what you'd like to do. Best regards, Dave Orme |
|
From: Mark M. <mmi...@vi...> - 2003-07-31 18:32:53
|
I am evaluating Sweet for a GUI Builder that is applicable to the interactive TV industry. Specifically it is for the OpenCable Application Platform (OCAP). See http://www.opencable.com/ocap.html for more information concerning this technology. If we choose to use Sweet, we plan to put a significant amount of editor components back into the Sweet community. Are there any examples on how to write Sweet-compliant components? I am struggling, trying to use the PropertyTable mechanism. Thanks for any help that can be provided. -------------------------------------- Mark S. Millard Vidiom Systems Phone: 303 604-0800 x119 Email: mmi...@vi... |
|
From: Dave O. <Da...@AS...> - 2003-07-09 13:13:43
|
No problem. I'm glad you got it working. I'll be away from email until Monday while I move. So if you try to email me before then and don't hear back, that's why. Best, Dave > -----Original Message----- > From: Konstantin Scheglov [mailto:sch...@nl...] > Sent: Tuesday, July 08, 2003 10:33 PM > To: Dave Orme > Subject: Re[4]: [Sweet-swt-develop] Properties as Resources > > > Hello Dave, > > Tuesday, July 8, 2003, 6:43:11 PM, you wrote: > > Ok, sorry, I found problem. > I've tried both ssh and pserver, but with my real SF > account, not with anonymous. > > DO> I should have added: You should be using pserver, but note that > DO> SourceForge has been unreliable lately with their pserver > services. > DO> If you're using pserver and still can't connect, please > let me know. > > > DO> Dave > > DO> -----Original Message----- > DO> From: Dave Orme [mailto:Da...@AS...] > DO> Sent: Tuesday, July 08, 2003 9:38 AM > DO> To: 'swe...@li...' > DO> Subject: RE: Re[2]: [Sweet-swt-develop] Properties as Resources > > > > DO> Are you using pserver or extssh? > > > > DO> Dave > > >> -----Original Message----- > >> From: Konstantin Scheglov [mailto:sch...@nl... > DO> <mailto:sch...@nl...> ] > >> Sent: Tuesday, July 08, 2003 2:16 AM > >> To: 'swe...@li...' > >> Subject: Re[2]: [Sweet-swt-develop] Properties as Resources > >> > >> > >> Hello Dave, > >> > >> Can anybody checkout files from CVS ? > >> I always have such exception. :-( > >> > >> Errors occured during this operation The server reported an > >> error while performing the "cvs checkout" command. > >> : cvs server: failed to create lock directory for > >> `/cvsroot/sweet-swt/net.sf.sweet_swt' > >> (/cvsroot/sweet-swt/net.sf.sweet_swt/#cvs.lock): > Permission denied > >> : cvs server: failed to obtain dir lock in repository > >> `/cvsroot/sweet-swt/net.sf.sweet_swt' > >> : cvs [server aborted]: read lock failed - giving up > >> > >> -- > >> Best regards, > >> Konstantin mailto:sch...@nl... > DO> <mailto:sch...@nl...> > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email sponsored by: Free pre-built ASP.NET sites > >> including Data Reports, E-commerce, Portals, and Forums are > >> available now. Download today and enter to win an XBOX or > >> Visual Studio .NET. > >> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06 > DO> <http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06> > DO> 1203_01/01 > DO> _______________________________________________ > DO> Sweet-swt-develop mailing list > Swe...@li... > DO> https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop > DO> <https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop> > > > > > -- > Best regards, > Konstantin mailto:sch...@nl... > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps > _______________________________________________ > Sweet-swt-develop mailing list > Swe...@li... > https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop > |
|
From: Konstantin S. <sch...@nl...> - 2003-07-09 03:33:17
|
Hello Dave, Tuesday, July 8, 2003, 6:43:11 PM, you wrote: Ok, sorry, I found problem. I've tried both ssh and pserver, but with my real SF account, not with anonymous. DO> I should have added: You should be using pserver, but note that SourceForge DO> has been unreliable lately with their pserver services. If you're using DO> pserver and still can't connect, please let me know. DO> Dave DO> -----Original Message----- DO> From: Dave Orme [mailto:Da...@AS...] DO> Sent: Tuesday, July 08, 2003 9:38 AM DO> To: 'swe...@li...' DO> Subject: RE: Re[2]: [Sweet-swt-develop] Properties as Resources DO> Are you using pserver or extssh? DO> Dave >> -----Original Message----- >> From: Konstantin Scheglov [mailto:sch...@nl... DO> <mailto:sch...@nl...> ] >> Sent: Tuesday, July 08, 2003 2:16 AM >> To: 'swe...@li...' >> Subject: Re[2]: [Sweet-swt-develop] Properties as Resources >> >> >> Hello Dave, >> >> Can anybody checkout files from CVS ? >> I always have such exception. :-( >> >> Errors occured during this operation The server reported an >> error while performing the "cvs checkout" command. >> : cvs server: failed to create lock directory for >> `/cvsroot/sweet-swt/net.sf.sweet_swt' >> (/cvsroot/sweet-swt/net.sf.sweet_swt/#cvs.lock): Permission denied >> : cvs server: failed to obtain dir lock in repository >> `/cvsroot/sweet-swt/net.sf.sweet_swt' >> : cvs [server aborted]: read lock failed - giving up >> >> -- >> Best regards, >> Konstantin mailto:sch...@nl... DO> <mailto:sch...@nl...> >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites >> including Data Reports, E-commerce, Portals, and Forums are >> available now. Download today and enter to win an XBOX or >> Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06 DO> <http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06> DO> 1203_01/01 DO> _______________________________________________ DO> Sweet-swt-develop mailing list Swe...@li... DO> https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop DO> <https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop> -- Best regards, Konstantin mailto:sch...@nl... |
|
From: Dave O. <Da...@AS...> - 2003-07-08 14:43:18
|
I should have added: You should be using pserver, but note that SourceForge has been unreliable lately with their pserver services. If you're using pserver and still can't connect, please let me know. Dave -----Original Message----- From: Dave Orme [mailto:Da...@AS...] Sent: Tuesday, July 08, 2003 9:38 AM To: 'swe...@li...' Subject: RE: Re[2]: [Sweet-swt-develop] Properties as Resources Are you using pserver or extssh? Dave > -----Original Message----- > From: Konstantin Scheglov [mailto:sch...@nl... <mailto:sch...@nl...> ] > Sent: Tuesday, July 08, 2003 2:16 AM > To: 'swe...@li...' > Subject: Re[2]: [Sweet-swt-develop] Properties as Resources > > > Hello Dave, > > Can anybody checkout files from CVS ? > I always have such exception. :-( > > Errors occured during this operation The server reported an > error while performing the "cvs checkout" command. > : cvs server: failed to create lock directory for > `/cvsroot/sweet-swt/net.sf.sweet_swt' > (/cvsroot/sweet-swt/net.sf.sweet_swt/#cvs.lock): Permission denied > : cvs server: failed to obtain dir lock in repository > `/cvsroot/sweet-swt/net.sf.sweet_swt' > : cvs [server aborted]: read lock failed - giving up > > -- > Best regards, > Konstantin mailto:sch...@nl... <mailto:sch...@nl...> > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites > including Data Reports, E-commerce, Portals, and Forums are > available now. Download today and enter to win an XBOX or > Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06 <http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06> 1203_01/01 _______________________________________________ Sweet-swt-develop mailing list Swe...@li... https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop <https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop> |
|
From: Dave O. <Da...@AS...> - 2003-07-08 14:38:24
|
Are you using pserver or extssh? Dave > -----Original Message----- > From: Konstantin Scheglov [mailto:sch...@nl...] > Sent: Tuesday, July 08, 2003 2:16 AM > To: 'swe...@li...' > Subject: Re[2]: [Sweet-swt-develop] Properties as Resources > > > Hello Dave, > > Can anybody checkout files from CVS ? > I always have such exception. :-( > > Errors occured during this operation The server reported an > error while performing the "cvs checkout" command. > : cvs server: failed to create lock directory for > `/cvsroot/sweet-swt/net.sf.sweet_swt' > (/cvsroot/sweet-swt/net.sf.sweet_swt/#cvs.lock): Permission denied > : cvs server: failed to obtain dir lock in repository > `/cvsroot/sweet-swt/net.sf.sweet_swt' > : cvs [server aborted]: read lock failed - giving up > > -- > Best regards, > Konstantin mailto:sch...@nl... > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites > including Data Reports, E-commerce, Portals, and Forums are > available now. Download today and enter to win an XBOX or > Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06 1203_01/01 _______________________________________________ Sweet-swt-develop mailing list Swe...@li... https://lists.sourceforge.net/lists/listinfo/sweet-swt-develop |
|
From: Konstantin S. <sch...@nl...> - 2003-07-08 07:15:45
|
Hello Dave, Can anybody checkout files from CVS ? I always have such exception. :-( Errors occured during this operation The server reported an error while performing the "cvs checkout" command. : cvs server: failed to create lock directory for `/cvsroot/sweet-swt/net.sf.sweet_swt' (/cvsroot/sweet-swt/net.sf.sweet_swt/#cvs.lock): Permission denied : cvs server: failed to obtain dir lock in repository `/cvsroot/sweet-swt/net.sf.sweet_swt' : cvs [server aborted]: read lock failed - giving up -- Best regards, Konstantin mailto:sch...@nl... |
|
From: Dave O. <Da...@AS...> - 2003-06-18 17:49:01
|
Whatever the solution, I think that rather than just solving Font with FontManager, it should be generic and basically address the fact that property values can come from other objects .... The problem here is that you may be then getting into the issue of persistence, so right now I'm in two minds. Do you just reference things by value and allow static class references, or do you allow anything more complex. This hits the nail on the head. And I'll add another 2c: With SWT, aliasing objects like this makes it hard to know if/when to generate dispose() calls... I don't have a good solution for this yet. Maybe a SWTResourceManager object that does reference counting for SWT objects and calls dispose() at the right time... But there are problems with this too. Dave |
|
From: Dave O. <Da...@AS...> - 2003-06-18 17:45:48
|
Nice work, Joe. As you said, please do keep us informed. Dave -----Original Message----- From: Joe Winchester [mailto:WIN...@uk...] Sent: Tuesday, June 17, 2003 6:46 AM To: swe...@li... Subject: Re: [Sweet-swt-develop] Has anyone here seen this? Hi Dave, I spoke to Mark Davidson at Sun ( the developer looking after JavaBeans/BeanInfo spec ) and we talked about having a whole ramp on the BeanInfo spec. Things we discussed were a) Making it all go to XML because BeanInfo classes are really declarative and not behavioral and for some folks ( those who are using JavaBeans as objects they wrapper as web services and want to created WSDL ) it makes more sense. b) Looking at metadata ( the URL you gave for this ). The good thing about metadata is that it is part of the source of the JavaBean ( so you don't need a separate BeanInfo class or XML document to manage and deploy ), and unlike comments that you can't parse and don't go into the .class file, metadata does. The disadvantage is that because it's part of the class itself you don't get the advantage that BeanInfo does right now ( whether in the existing .class or an XML format ) that you can augment it with your own. For example, Sun provide their own BeanInfo classes however we at IBM have our own ones for VisualAge for Java and WebSphere Studio. This is because some of the information in the BeanInfo is put their by the author and is really just declarative, however some isn't. Things like property editors are the "value add" that IDEs provide. It did make me think ! about this whole issue and how people currently extend BeanInfo by having full replacement classes and slamming it into the Introspector's search path. We need a better way to just delta your metadata on top of the compoent author's existing definition. There is a JSR that is just about to begin to ramp the whole BeanInfo spec. Marc ( from Sun ) and I are pushing it through right now to get JCP approval and given that IBM and Sun are backing it I doubt it'll get voted down. Once this gets going then our thoughts are something along the lines of metadata for the class author, XML for deltas, and allowing extension to other component models not supported by BeanInfo including modelling relationships ( container to component for example ) and also non-default construction and other patterns. We'll need an expert group once this gets going so hopefully there is synergy between Sweet and the BeanInfo ramp. I'm going to chase the IBM lawyers today to see where it's at in the JCP and I'll post here once I know more. Best regards, Joe Please respond to swe...@li... Sent by: swe...@li... To: "'swe...@li...'" <swe...@li...> cc: Subject: [Sweet-swt-develop] Has anyone here seen this? <http://www.jcp.org/en/jsr/detail?id=175> http://www.jcp.org/en/jsr/detail?id=175 Thoughts/opinions? Dave |
|
From: Joe W. <WIN...@uk...> - 2003-06-17 12:17:35
|
Hi Dave, >Sounds like there's a need for a FontManager class that the GUI builder is aware of and can use optionally in lieu of manually creating fonts. In Sweet's parlance, this would be a custom font PropertyEditor that can interact >with a FontManager to generate the appropriate initialization strings for the individual GUI builder's code generator. To me the problem sounds more like you just need to be able to point to a property value by name or by reference. Usually a property editor comes up with a new color, font, etc... That's what the BeanInfo spec basically enforces( it actually says explicitly that the property editor instance must be newed up each time ). However some properties don't, for example an AWT Checkbox/checkboxGroup ( the whole point is to share one ), or Swing's JComponent/nextFocusableComponent ( that points to the next GUI element to tab onto ). Others do come from other places such as strings from resource bundles, borders from factories, even in SWT color rather than new org.eclipse.swt.graphics.Color(display,255,255,255) you might want display.getSystemColor(SWT.COLOR_WHITE); Whatever the solution, I think that rather than just solving Font with FontManager, it should be generic and basically address the fact that property values can come from other objects. The FontManager is that objects, and the method used to access the font is the accessor. In the case of FontManager being a class then you don't need to reference the instance by anything other than name ( two property values will get the same instance because the VM will ensure that ), however if it's something else that's part of the set of other objects ( i.e.an instance of a resource bundle ) then you need to be able to identify that specific instance not necessarily via a static. The problem here is that you may be then getting into the issue of persistence, so right now I'm in two minds. Do you just reference things by value and allow static class references, or do you allow anything more complex. Best regards, Joe |
|
From: Joe W. <WIN...@uk...> - 2003-06-17 12:15:22
|
Hi Dave, I spoke to Mark Davidson at Sun ( the developer looking after JavaBeans/BeanInfo spec ) and we talked about having a whole ramp on the BeanInfo spec. Things we discussed were a) Making it all go to XML because BeanInfo classes are really declarative and not behavioral and for some folks ( those who are using JavaBeans as objects they wrapper as web services and want to created WSDL ) it makes more sense. b) Looking at metadata ( the URL you gave for this ). The good thing about metadata is that it is part of the source of the JavaBean ( so you don't need a separate BeanInfo class or XML document to manage and deploy ), and unlike comments that you can't parse and don't go into the .class file, metadata does. The disadvantage is that because it's part of the class itself you don't get the advantage that BeanInfo does right now ( whether in the existing .class or an XML format ) that you can augment it with your own. For example, Sun provide their own BeanInfo classes however we at IBM have our own ones for VisualAge for Java and WebSphere Studio. This is because some of the information in the BeanInfo is put their by the author and is really just declarative, however some isn't. Things like property editors are the "value add" that IDEs provide. It did make me think about this whole issue and how people currently extend BeanInfo by having full replacement classes and slamming it into the Introspector's search path. We need a better way to just delta your metadata on top of the compoent author's existing definition. There is a JSR that is just about to begin to ramp the whole BeanInfo spec. Marc ( from Sun ) and I are pushing it through right now to get JCP approval and given that IBM and Sun are backing it I doubt it'll get voted down. Once this gets going then our thoughts are something along the lines of metadata for the class author, XML for deltas, and allowing extension to other component models not supported by BeanInfo including modelling relationships ( container to component for example ) and also non-default construction and other patterns. We'll need an expert group once this gets going so hopefully there is synergy between Sweet and the BeanInfo ramp. I'm going to chase the IBM lawyers today to see where it's at in the JCP and I'll post here once I know more. Best regards, Joe Please respond to swe...@li... Sent by: swe...@li... To: "'swe...@li...'" <swe...@li...> cc: Subject: [Sweet-swt-develop] Has anyone here seen this? http://www.jcp.org/en/jsr/detail?id=175 Thoughts/opinions? Dave |
|
From: Dave O. <Da...@AS...> - 2003-06-16 21:04:34
|
Hi Paul, You're right that there's been some bit-rot since the directions on the download page were written. I'll have to address that; thanks for bringing it to my attention. Sweet is currently just a toolkit for GUI builder writers--it helps solve the SWT metadata problem and provides an open source SWT property editor control. Is this what you were expecting? Please let me know more about how you were wanting to help. Best regards, Dave Orme -----Original Message----- From: Paul Sinnema [mailto:pau...@wa...] Sent: Sunday, June 15, 2003 10:55 AM To: Sweet Subject: [Sweet-swt-develop] New to sweet Hi, I've just registered myself as a developer. I would like to participate but need some help to get up and running. Paul. |
|
From: Paul S. <pau...@wa...> - 2003-06-15 15:54:53
|
Hi, I've just registered myself as a developer. I would like to participate but need some help to get up and running. Paul. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003 |
|
From: Dave O. <Da...@AS...> - 2003-06-12 17:05:19
|
http://www.jcp.org/en/jsr/detail?id=175 Thoughts/opinions? Dave |
|
From: Scott S. <sc...@ja...> - 2003-06-12 15:14:07
|
MessageCan't reply right now - in release mode at work...
I'll look at it as soon as I get a chance...
-- Scott
====================
Scott Stanchfield
FGM, Inc.
sc...@fg...
====================
-----Original Message-----
From: swe...@li...
[mailto:swe...@li...]On Behalf Of Dave Orme
Sent: Thursday, June 12, 2003 11:00 AM
To: 'John Bridges'
Cc: 'swe...@li...'
Subject: RE: [Sweet-swt-develop] Properties as Resources
Common resources make life easier when you want to propagate changes
through an application - classic case is a company wants to use "Font Y"
instead of "Font X" as a company standard - can you now go and change all
instances.
Obviously this can be done with a dumb search and replace - but the use
of a 'named' resource allows you to be more specific - so "Font X" remains
in use for all Labels but is changed in all combo-boxes to "Font Y".
Definitely not a contrived example - I've had to do this by hand before
and it sucks!
Sounds like there's a need for a FontManager class that the GUI builder is
aware of and can use optionally in lieu of manually creating fonts. In
Sweet's parlance, this would be a custom font PropertyEditor that can
interact with a FontManager to generate the appropriate initialization
strings for the individual GUI builder's code generator.
I've started a new section in the Sweet design doc for Sweet 2.0 ideas and
added this idea to it (giving you attribution, of course).
Can you think of any other examples?
Do you have thoughts about this, Scott?
Thanks for the feedback!
Best regards,
Dave
|
|
From: Dave O. <Da...@AS...> - 2003-06-12 14:59:56
|
Common resources make life easier when you want to propagate changes through an application - classic case is a company wants to use "Font Y" instead of "Font X" as a company standard - can you now go and change all instances. Obviously this can be done with a dumb search and replace - but the use of a 'named' resource allows you to be more specific - so "Font X" remains in use for all Labels but is changed in all combo-boxes to "Font Y". Definitely not a contrived example - I've had to do this by hand before and it sucks! Sounds like there's a need for a FontManager class that the GUI builder is aware of and can use optionally in lieu of manually creating fonts. In Sweet's parlance, this would be a custom font PropertyEditor that can interact with a FontManager to generate the appropriate initialization strings for the individual GUI builder's code generator. I've started a new section in the Sweet design doc for Sweet 2.0 ideas and added this idea to it (giving you attribution, of course). Can you think of any other examples? Do you have thoughts about this, Scott? Thanks for the feedback! Best regards, Dave |
|
From: Dave O. <Da...@AS...> - 2003-06-12 14:17:24
|
Dave, the addition of categories is right on the mark (re: comments in Wiki). Thanks! Would it be appropriate for property values to be taggable as common resources ? e.g. Color, Font, Image, Strings etc are often duplicated within UI builders - because its easier to create objects on the fly than search around for similar instances. I don't know. Do you have a use-case where this would be beneficial to you? Scott, can you think of any use-cases? This is kind of a fuzzy one as it borders on being more of a persistence issue than a design time issue, although I feel it crosses the border somewhere. Thoughts ? Given SWT's rule that disposing the parent also disposes children, this sounds dangerous to me--like you would be setting yourself up for disposing things multiple times. Am I right here? Dave |
|
From: Gerald B. <lux...@ya...> - 2003-06-04 15:49:36
|
Hi, It looks like the Eclipse Bugzilla Bug #38109 "consider a UI markup language for SWT" online @ https://bugs.eclipse.org/bugs/show_bug.cgi?id=38109 and also covered in the XUL News Wire @ http://article.gmane.org/gmane.comp.lang.xul.announce/18 has spawned a debate over the XML format for describing SWT UIs. Before reinventing the wheel, the toothbrush or the alphabeth may I point out the XUL Alliance site @ http://xul.sourceforge.net XUL in case you wondered stands for XML UI Language. The XUL Alliance site lists dozens of XUL motors that turn XML into live UIs using Swing, SWT or other UI toolkits. Some XUL motors using SWT include: * Luxor - http://luxor-xul.sourceforge.net * JellySWT - http://jakarta.apache.org/commons/jelly/jellyswt.html * Haystack - http://haystack.lcs.mit.edu * and others. - Gerald ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
