xswt-developer Mailing List for XSWT - XML/SWT page description language (Page 28)
Brought to you by:
dvorme
Menu
▾
▴
xswt-developer — Talk about developing/developing with XSWT
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(104) |
Nov
(68) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(18) |
Feb
(5) |
Mar
(4) |
Apr
(7) |
May
(28) |
Jun
(19) |
Jul
(2) |
Aug
|
Sep
(10) |
Oct
(19) |
Nov
(17) |
Dec
(3) |
| 2006 |
Jan
|
Feb
(1) |
Mar
(19) |
Apr
(61) |
May
(26) |
Jun
(31) |
Jul
(11) |
Aug
(15) |
Sep
(4) |
Oct
(18) |
Nov
|
Dec
(8) |
| 2007 |
Jan
(3) |
Feb
|
Mar
(13) |
Apr
(27) |
May
|
Jun
(4) |
Jul
(7) |
Aug
(25) |
Sep
(5) |
Oct
(6) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(6) |
Feb
(23) |
Mar
(32) |
Apr
(24) |
May
(18) |
Jun
(7) |
Jul
(12) |
Aug
(4) |
Sep
(3) |
Oct
(7) |
Nov
(29) |
Dec
(9) |
| 2009 |
Jan
(25) |
Feb
(8) |
Mar
(32) |
Apr
(32) |
May
(73) |
Jun
(68) |
Jul
(31) |
Aug
(22) |
Sep
(21) |
Oct
(26) |
Nov
(4) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(1) |
Mar
(25) |
Apr
(66) |
May
(64) |
Jun
(65) |
Jul
(33) |
Aug
(48) |
Sep
(27) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(2) |
Aug
(6) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <Yu...@no...> - 2004-10-11 11:34:28
|
Hi Jan, It's very nice to meet you. Sorry for my delayed reply. I was away for = couples of days last week. About your question to SWT on embedded devices, especially in mobile = phones, please look at eRCP project in Eclipse: http://www.eclipse.org/proposals/eclipse-ercp/ I believe you can see my name in the Creation Review presentation. = However, hold on :-) the whole eRCP has no direct link to XSWT; and my = personal contribution to XSWT does not represent Nokia's either :-) Actually I plan to write a test case/tutorial for all SWT widgets. It = has two benefits: - work as a test suit for new implementations; - work as a tutorial for XSWT users. Regards, yu > -----Original Message----- > From: xsw...@li...=20 > [mailto:xsw...@li...]On Behalf=20 > Of ext Jan Petersen > Sent: Thursday, October 07, 2004 3:04 PM > To: xsw...@li... > Subject: [Xswt-developer] To Yu >=20 >=20 > Yu You, >=20 > Dave suggested that I introduced myself to you on the > mailing list. >=20 > Well, I have been using XSWT for quite some time now on a > pretty large project. I have made some contributions which > I'm sure that you have seen already: >=20 > CustomNSHandler support > Setting a key/value widget data > Viewer support (I saw you commented this out in the current > CVS version). >=20 > Personal: About 12 years C++ experience and about 5 Java. > I'm based in Switzerland on the shores of Lake Geneva. >=20 > Currently I'm very interested in fixing 2 issues in XSWT: >=20 > The shell/global layout "thing", for which I'm sure that > you have already seen Dave's excellent proposal. >=20 > Getting ScrolledComposite to work using some kind of > forward declaration. >=20 > Also, I'm interested in htis thing you're doing for J2ME... > which J2ME devices can support SWT? Now does this work (is > there a native lib like on desktop os's), and look? >=20 > Thanks >=20 >=20 > Jan Petersen >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on=20 > ITManagersJournal > Use IT products in your business? Tell us what you think of=20 > them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to=20 > find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Xswt-developer mailing list > Xsw...@li... > https://lists.sourceforge.net/lists/listinfo/xswt-developer >=20 |
|
From: Dave O. <Da...@AS...> - 2004-10-08 13:53:48
|
It looks like the SourceForge mailing list server hiccupped on this one...
-----Original Message-----
From: Jan Petersen [mailto:ja...@in...]
Sent: Friday, October 08, 2004 3:39 AM
To: xsw...@li...; David Orme
Subject: ScrolledComposite ideas
I have a better understanding of the forward declaration problem with
ScrolledComposite.
I have done some hacking - which I will not commit - just for
experimentation and have now something that actually works. Here's what
I did (it's ugly):
I changed the WidgetDataParser like this:
public Object parse(String source) throws XSWTException {
Object result = null;
result = map.get(source);
if (result == null) {
throw new NullPointerException("Undefined ID:" + source);
// throw new XSWTException("Undefined ID:" + source);
}
return result;
}
I used NullPointerException so that I didn't have to change the
signature of these methods and will propogate all the way up.
In XSWT.processChild I changed the last part like this:
boolean gotNullpointerException = false;
try {
processChildAttributes(result, element);
} catch (NullPointerException e) {
gotNullpointerException = true;
}
processSubNodes(result, element);
if (gotNullpointerException) {
System.out.println("Now we can handle the forward declared widgets
in "
+ widgetName);
processChildAttributes(result, element);
}
return result;
This actually works, but of course calling processChildAttributes twice
is not smart.
-----------------------------------------------------------------
Proposal:
It looks like we have to change WidgetDataParser so that it doesn't
throw a XSWTException. Maybe we can introduce a
ReferenceNotFoundException, or something, which must be caught in
XSWT.processChild. If this exception is caught we know that we have to
do some extra processing to find forward declared refereces. Finally it
looks like we have to introduce a new method which contains a subset of
the functionality in processChildAttributes with the relevant funtionality.
Comments?
Cheers
Jan
|
|
From: Jan P. <ja...@in...> - 2004-10-08 08:39:56
|
I have a better understanding of the forward declaration problem with
ScrolledComposite.
I have done some hacking - which I will not commit - just for
experimentation and have now something that actually works. Here's what
I did (it's ugly):
I changed the WidgetDataParser like this:
public Object parse(String source) throws XSWTException {
Object result = null;
result = map.get(source);
if (result == null) {
throw new NullPointerException("Undefined ID:" + source);
// throw new XSWTException("Undefined ID:" + source);
}
return result;
}
I used NullPointerException so that I didn't have to change the
signature of these methods and will propogate all the way up.
In XSWT.processChild I changed the last part like this:
boolean gotNullpointerException = false;
try {
processChildAttributes(result, element);
} catch (NullPointerException e) {
gotNullpointerException = true;
}
processSubNodes(result, element);
if (gotNullpointerException) {
System.out.println("Now we can handle the forward declared widgets in "
+ widgetName);
processChildAttributes(result, element);
}
return result;
This actually works, but of course calling processChildAttributes twice
is not smart.
-----------------------------------------------------------------
Proposal:
It looks like we have to change WidgetDataParser so that it doesn't
throw a XSWTException. Maybe we can introduce a
ReferenceNotFoundException, or something, which must be caught in
XSWT.processChild. If this exception is caught we know that we have to
do some extra processing to find forward declared refereces. Finally it
looks like we have to introduce a new method which contains a subset of
the functionality in processChildAttributes with the relevant funtionality.
Comments?
Cheers
Jan
|
|
From: Dave O. <Da...@AS...> - 2004-10-08 01:49:25
|
I think this was accidentally sent to the 'admin' address... -----Original Message----- From: Jan Petersen [mailto:jpe...@in...] Sent: Thursday, October 07, 2004 10:42 AM To: xsw...@li... Subject: Forward declaration I have looked like an hour os so on this ScrolledCommposite "forward" declaration problem... Obviously the problem is that WidgetDataParser fails to parse as it can't find the source in its map and thus throws an XSWTException. The trick will (somehow) be to postpone this specific task of calling the WidgetDataParser to after all the children of the widget in question has been parsed. The question is how this is best done...? Any thoughts? Jan |
|
From: Jan P. <jpe...@in...> - 2004-10-07 12:04:27
|
Yu You, Dave suggested that I introduced myself to you on the mailing list. Well, I have been using XSWT for quite some time now on a pretty large project. I have made some contributions which I'm sure that you have seen already: CustomNSHandler support Setting a key/value widget data Viewer support (I saw you commented this out in the current CVS version). Personal: About 12 years C++ experience and about 5 Java. I'm based in Switzerland on the shores of Lake Geneva. Currently I'm very interested in fixing 2 issues in XSWT: The shell/global layout "thing", for which I'm sure that you have already seen Dave's excellent proposal. Getting ScrolledComposite to work using some kind of forward declaration. Also, I'm interested in htis thing you're doing for J2ME... which J2ME devices can support SWT? Now does this work (is there a native lib like on desktop os's), and look? Thanks Jan Petersen |
|
From: <Yu...@no...> - 2004-09-29 21:20:46
|
Hi, Please check those changes till today. I plan to commit all changes to the CVS tomorrow if accepted by most of = you so please be prepared to test it with your old XSWT files before = XSWT package ver. 1.2 is released. Major changes: - XML parser is now using kXML parser (http://www.kxml.org) - Full cutomizable automiatical resource management * by default, Color, Font, and Image resources are done by XSWT. Sep. 29, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Resource Management - now support Color, Font and Image - supported syntax: <!-- Two construction types work in Color attiribute: CSS constants = and SWT.COLOR_XXX=20 <label text=3D"Hello World:" foreground=3D"SWT.COLOR_BLUE"> --> <label text=3D"Hello World:" foreground=3D"DarkGreen" = font=3D"Dialog, 12, SWT.BOLD|SWT.ITALIC"> <background x:p0=3D"null" x:p1=3D"200" x:p2=3D"200" x:p3=3D"0xff" = /> </label> XSWT Syntax suggestions: - requires FQNS in all nodes like <x.import> <x.children> ... =09 IntDataParser.java - use Integer.decode to replace Integer.parseInt to support all = decimal, hexadecimal, and octal numbers. e.g. <background x:p0=3D"null" x:p1=3D"200" x:p2=3D"100" x:p3=3D"0xff" = /> Ori. code: int intermediate =3D Integer.parseInt(source); result =3D new Integer(intermediate); New code: result =3D Integer.decode(source); =09 LayoutBuilder.java - rolled back the change made before in Sep. 24, 2004. The change requires is too strict to be error-prone It requires all possible data parsers must be registered. TODO: at least let us log or show some errors to the user.=09 //}catch (XSWTException e1) { // throw e1; } catch (Exception e) { logger. // If we didn't succeed, try the next constructor... result.constructor =3D null; result.args =3D null; continue; } Sep. 28, 2004, by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Changed XSWT.java - processChildren // TODO: process IMPORT children too, so IMPORT elements are proceeded // twice!! That's a problem. explicitly ignore the <import> node. =09 - added the support at the top nodes for parent composite. Now nodes between <import> and <children> will be parsed as nodeproperties = for top-level composite. orig. if (nodeChild.getName().endsWith("children")) { processChildControls(composite, (Element) nodeChild); } New: if (nodeChild.getName().endsWith("children")) { processChildControls(composite, (Element) nodeChild); } // Added by Yu You // Process other nodes as child nodes of parent composite else processNodeProperty(composite, nodeChild); =09 ClassBuilder.java - getClass throw new XSWTException("Unable to resolve class: " + = className); added more hint information changed to throw new XSWTException("Unable to resolve class: " + className + = "\nCheck the import node for the necessary package name"); =09 XSWT.java - removed IColorManager in XSWT constructor XSWT() * Rational: - add global ResourceManager - for beginners, they need only use XSWT.create() to create UI; - for advanced developers, they could implement custom = IResourceManager and relevant Color/Font managers. - removed IColorManager from XSWT create methods - removed setColorManager() * changed to setResourceManager Rational: - lots of NULL arguments in many create methods seems weird; - use a resourcemanager to manager Color and Font, or any future skin = resources. Sep 27, 2004 by Yu Yu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Need to fix XSWTPreview.java - compositeFrame.setBackground(new Color(compositeFrame.getDisplay(), = 250, 140, 140));=20 new Color must be disposed manually.=20 Changed to Display.getSystemColor(SWT.Red); Fixed - duplicated ID nows reports error Design - a API to get a SWT control position in a XML: Element getElement(Control control); Sep. 26, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= New Added ResourceManager.java the default IResourceManager implementation. ImageResourceManager.java The Image resource manager Sep. 25, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Changed: IColorManager.java - moved license explanation to where it should be. Re-write the javadoc. - changed "Display" to "Device". * Both Printer and Display are Devices. - add IResourceManager as its father class Following is the detailed change list (I must have missed some changes I = have ever done) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sep. 29, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Resource Management - now support Color, Font and Image - supported syntax: <!-- Two construction types work in Color attiribute: CSS constants = and SWT.COLOR_XXX=20 <label text=3D"Hello World:" foreground=3D"SWT.COLOR_BLUE"> --> <label text=3D"Hello World:" foreground=3D"DarkGreen" = font=3D"Dialog, 12, SWT.BOLD|SWT.ITALIC"> <background x:p0=3D"null" x:p1=3D"200" x:p2=3D"200" x:p3=3D"0xff" = /> </label> XSWT Syntax suggestions: - requires FQNS in all nodes like <x.import> <x.children> ... =09 IntDataParser.java - use Integer.decode to replace Integer.parseInt to support all = decimal, hexadecimal, and octal numbers. e.g. <background x:p0=3D"null" x:p1=3D"200" x:p2=3D"100" x:p3=3D"0xff" = /> Ori. code: int intermediate =3D Integer.parseInt(source); result =3D new Integer(intermediate); New code: result =3D Integer.decode(source); =09 LayoutBuilder.java - rolled back the change made before in Sep. 24, 2004. The change requires is too strict to be error-prone It requires all possible data parsers must be registered. TODO: at least let us log or show some errors to the user.=09 //}catch (XSWTException e1) { // throw e1; } catch (Exception e) { logger. // If we didn't succeed, try the next constructor... result.constructor =3D null; result.args =3D null; continue; } Sep. 28, 2004, by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Changed XSWT.java - processChildren // TODO: process IMPORT children too, so IMPORT elements are proceeded // twice!! That's a problem. explicitly ignore the <import> node. =09 - added the support at the top nodes for parent composite. Now nodes between <import> and <children> will be parsed as nodeproperties = for top-level composite. orig. if (nodeChild.getName().endsWith("children")) { processChildControls(composite, (Element) nodeChild); } New: if (nodeChild.getName().endsWith("children")) { processChildControls(composite, (Element) nodeChild); } // Added by Yu You // Process other nodes as child nodes of parent composite else processNodeProperty(composite, nodeChild); =09 ClassBuilder.java - getClass throw new XSWTException("Unable to resolve class: " + = className); added more hint information changed to throw new XSWTException("Unable to resolve class: " + className + = "\nCheck the import node for the necessary package name"); =09 XSWT.java - removed IColorManager in XSWT constructor XSWT() * Rational: - add global ResourceManager - for beginners, they need only use XSWT.create() to create UI; - for advanced developers, they could implement custom = IResourceManager and relevant Color/Font managers. - removed IColorManager from XSWT create methods - removed setColorManager() * changed to setResourceManager Rational: - lots of NULL arguments in many create methods seems weird; - use a resourcemanager to manager Color and Font, or any future skin = resources. Sep 27, 2004 by Yu Yu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Need to fix XSWTPreview.java - compositeFrame.setBackground(new Color(compositeFrame.getDisplay(), = 250, 140, 140));=20 new Color must be disposed manually.=20 Changed to Display.getSystemColor(SWT.Red); Fixed - duplicated ID nows reports error Design - a API to get a SWT control position in a XML: Element getElement(Control control); Sep. 26, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= New Added ResourceManager.java the default IResourceManager implementation. ImageResourceManager.java The Image resource manager Sep. 25, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Changed: IColorManager.java - moved license explanation to where it should be. Re-write the javadoc. - changed "Display" to "Device". * Both Printer and Display are Devices. - add IResourceManager as its father class New added: IFontManager.java - like IColorManager.java IResourceManager.java - top interface to manage all resources Sep. 24, 2004 by Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Correct some javadoc typos * ImageDataParser * =09 Add DeviceParser for Color and Font types of classes that require Device = as argument - Added relevant parsers in XSWT.java static{} section=09 * DataParser.registerDataParser(Font.class, new FontDataParser()); * DataParser.registerDataParser(Device.class, new DeviceDataParser()); FontDataParser.java (without considering FontManager yet) - now support syntax: exmaple: <font x:p0=3D"null" x:p1=3D"Dialog" x:p2=3D"10" = x:p3=3D"SWT.ITALIC"/> TODO: get rid of x:p0=3D"null" for Display and use FontManager API =09 - changed teh parse() old code: return name !=3D null && height >=3D 0 ? new Font(display, name, = height, style) : null; new code: if (display =3D=3D null) display =3D Display.getCurrent(); Font f =3D null; try { f =3D new Font(display, name, height, style); } catch (Exception e) { f =3D display.getSystemFont(); } return f; =09 ClassBuilder.java - added exception error constants layoutBuilder.java - getConstructorInfo() * add throw XSWTException because XSWTException happens when no proper = Paser is registered. ori. code: } catch (Exception e) { =20 =20 new code: }catch (XSWTException e1) { throw e1; } catch (Exception e) { =20 =20 =20 SWTLayoutBuilder.java - in method construct () if constructorInfo.args is NULL, constructorInfo.args.length will = cause a runtime exception. ori. code: if (constructorInfo.constructor =3D=3D null || = constructorInfo.args =3D=3D null) throw new XSWTException("Unable to locate a constructor for = type" + valueType.getName() +" with " + = constructorInfo.args.length + " parameters."); changed "constructorInfo.args.length" to "argList.size()" Sep. 20, 2004 By Yu You =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= XSWT.java - tide up the code little bit * e.g. use "upperCaseFirstLetter" method in all place, i.e. in method = "processChild" * in method "processBuiltInAttr", not error catch for = nodeName.subString(2,3) // Constructor parameters have already been processed if ("p".equals(nodeName.substring(2, 3))) =09 =20 - constructor changes * delete ErrorHandler and EntityResolver =20 * String xswt_tag =3D element.getNamespace(); if (xswt_tag !=3D null) //-> changed to && xswt_tag.length()!=3D0 xswt_tag +=3D ":XSWT"; else =20 - Removed methods * getDocumentBuilder() * isElement * isChildElement * processAttributeProperty * processAttributeField - Modified methods * processImportList(NodeList imports) -> processImportList(Node = imports) =20 * processChildAttributes (no JFace View support) * processBuiltInAttr(Objetc, Node) -> processBuiltInAttr (Object, = string, string, String) =20 - kXML parser syntax changes * element.getPrefix -> element.getNamespace * element.getTagName -> element.getName * element.getChildNodes -> element.getChildCount() * in method "processBuiltInAttr" Question: it assumes nodeName format is like "x:p0" but kXML returns = "p0" without namespace prefix if ("p".equals(nodeName.substring(2, 3))) return true; Solution: an ugly hack to get rid of namespace prefix int index =3D nodeName.indexOf(':'); nodeName =3D (index=3D=3D-1)?nodeName:nodeName.substring(index+1); =09 - Removed unsupported XML syntax * DOMException =20 XSWTException.java - Modified constructors=20 * Chained exceptions (Throwable as arguments) is not supported by = J2ME CLDC 1.1/MIDP 2.0 and CDC1.0/FP1.0. CDC 1.1 afterwards will support it. |
|
From: <Yu...@no...> - 2004-09-29 19:07:45
|
Hi XSWT developers, from previous discussion regarding having the sub-nodes between <import> = and <x.children>, I come up with one requirement or suggestion for your = comments - all nodes requires full namespace prefixes. The is because XSWT = supports custom namespaces. Example: <?xml version=3D"1.0" encoding=3D"UTF-8"?> <xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt"=20 xmlns:xforms=3D"http://www.w3.org/2002/01/forms"=20 xmlns:svg=3D"http://www.w3.org/2000/svg"=20 > <x:import xmlns=3D"http://sweet_swt.sf.net/xswt"> <package name=3D"org.eclipse.swt.widgets"/> <package name=3D"org.eclipse.swt.graphics"/> <package name=3D"org.eclipse.swt.layout"/> <!-- XForms <package name=3D"" /> --> <!-- SVG <package name=3D"" /> --> </x:import> <!-- <x:include name=3D"file:///test.xswt"/> --> =09 <x:layout x:class=3D"fillLayout" /> <x:children> <!-- processing multiple namespaces is not done yet=20 for release 1.2. --> <!-- <xforms:button style=3D" color: blue; border-color: red; border-width: 1px; background-color: pink;"> <xforms:caption>This is a test</xforms:caption> </xforms:button> --> Yu |
|
From: David J. O. <dj...@co...> - 2004-09-24 02:37:35
|
On Wednesday 22 September 2004 02:33 am, you wrote: > > Okay, this is a new use-case I didn't understand before > > and *would* probably > > justify special syntax to support it. I'm assuming that > > you will manually > > dispose anything (menus, old Composite), etc., that need > > dispose()ing, right? > > Yes, you're right - I'm doing the dispose myself and I > don't think this should be within XSWT. That's fine. > I _really_ don't know if I think that the idea of having an > new overloaded XSWT.create() method, which takes a Display > as parameter, is a good or not so good. I know that it > doesn't cover my requirement for a lot of different > reasons, but that doesn't mean that it isn't a good idea of > course. 1) I'm starting to think that we need this. It's not always a good idea to have to create the Shell in code and everything else in XSWT. 2) There's another problem with the current design. Jan pointed it out earlier: The XSWT parent's layout manager has to be set in Java code. You'd like to set that in XSWT code, since the XSWT code has to setLayoutData() to go with that layout manager. The solution I'm considering is the following: We currently ignore all undefined nodes outside the top-level <x:children> tag. There's a TODO item to flag these undefined nodes as errors, but I think a better idea is the following: Nodes outside the top-level <x:children> node act as setters on the XSWT parent container. This lets you write: <?xml version="1.0" encoding="UTF-8"?> <xswt xmlns:x="http://sweet_swt.sf.net/xswt"> <import xmlns="http://sweet_swt.sf.net/xswt"> <package name="java.lang"/> <package name="org.eclipse.swt.widgets"/> <package name="org.eclipse.swt.layout"/> </import> <!-- Set the parent's layout manager --> <layout x:class="gridLayout" numColumns="2"/> <x:children> <list selection="0" x:style="BORDER|SINGLE"> <layoutData x:class="gridData" heightHint="100" widthHint="220"/> <add x:p0="Line number foreground"/> <add x:p0="Matching brackets highlight"/> <add x:p0="Current line highlight"/> </list> <!-- More stuff here... --> </x:children> </xswt> Which lets you keep the layout data for the top-level widgets with the code that sets the layout manager that they affect. This just changes the XSWT syntax so that any top-level nodes that are not recognized as XSWT reserved words are interpreted as ordinary XSWT nodes applying to the parent. This also applies to the following: > What I've done so far is to put a <shell> element in the > custom namespace handler and are only handling location and > size so far and I could easily add layout handling I guess > (only using absolute positions for now). But I would prefer > to have this in XSWT. To those entering this discussion late on the list, Jan pointed out that sometimes you need to change things on the Shell from within an XSWT file. His proposal is to add an optional top-level <shell> node inside which one could add children of the Shell. Here's a counter-proposal: *Any* XSWT node (including the <xswt> node) can call 0-arg methods to return an object and then call methods on it or add children to it. So you would be able to add menus to a Shell from XSWT as follows: <?xml version="1.0" encoding="UTF-8"?> <xswt xmlns:x="http://sweet_swt.sf.net/xswt"> <import xmlns="http://sweet_swt.sf.net/xswt"> <package name="java.lang"/> <package name="org.eclipse.swt.widgets"/> <package name="org.eclipse.swt.layout"/> </import> <!-- Set a layout on the parent, which wouldn't have to be the Shell --> <layout x:class="gridLayout" numColumns="2"/> <!-- Now do something with the Shell --> <getShell> <!-- In here, regular XSWT semantics apply --> <text x:p0="New title bar text" /> <x:children> <menu x:style="DROP_DOWN" x:id="fileMenu"> <x:children> <menuItem text="New"/> <menuItem text="Open"/> <menuItem x:style="SEPARATOR"/> <menuItem text="Exit"/> </x:children> </menu> </x:children> </getShell> <!-- Now for the children of the XSWT parent... --> <x:children> <label text="Java Editor settings:"> <layoutData x:class="GridData" /> </label> <label text="Java Editor settings:"> <layoutData x:class="GridData" /> </label> <label text="Java Editor settings:"> <layoutData x:class="GridData" /> </label> <label text="Java Editor settings:"> <layoutData x:class="GridData" /> </label> </x:children> </xswt> Notes: - In order to call a 0-arg method and operate on its result, you have to use the literal method name. Otherwise, we will get naming collisions. ie: does <shell> mean to call getShell() or mean to construct a new Shell? - Other than that, there are no changes to XSWT syntax. - Since you can use regular XSWT syntax inside the 0-arg method, you can also nest these things if you need to get the effect of writing: getSomething().getSomethingElse().add("whatever"); Thoughts, anyone? Regards, Dave Orme -- Got Java? Use SWTworkbench! <http://www.swtworkbench.com> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQGiBD9aRLsRBACTH5q/Z/42GOk0VVq2MC4pdqPAY+yOhdzp+nfyeFBbBTCZRFsd pnqiRY0+eCCBSar60bGG98acCgf9HwG2YGzrKZGUxf7GxY4iiiwcs89q3LFcp2xn Z7WeNzcNQsw0ZnfMs8fWPUF+5iHsmsYIU/IvgldwyGTQ/MWhaK28urehfwCgmVFV Y7eFawJZrlXCA7VjPhqlkzMD/jBsxNxHXUpMR2xzE/HN0Cz4nkkR7aaCQNPe0Lmy 9Y/D5NGcJunoNkwGI2rFO0wwgjqgE0Lknv7/U1yK1/085kTufBcDZNEgbw93uPmx 5mKnWe3oq+iTqV742DQSyOgWmQ4RqcK9whZDpIwXl3biRKw/aQIq2Vs1k6a6AxqT KLCXA/4zUPQ7gs0d44K6Fc4zVEJVPyD5pVf6iTSpQNjd8iTn++i9dGymEP73EIJd uVDDU7Y0P7OydVAwfISaZvnYmX9UvnOV5wr9JWgH+lcrANaRb2Xryz65mGnhj6QO qaTJyjU79M0N4kaVwu/8vENO7lg1K9hpW5Fb2LEDaZuxZYRDyLYAAAAtRGF2aWQg Si4gT3JtZSA8ZGpvQGNvY29udXQtcGFsbS1zb2Z0d2FyZS5jb20+iFsEExECABsF Aj9aRLsGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQSk7oR0hiGLp+bgCgix8nVvZs fpz4RJ5krVZRYPPeIwkAn3KK3Xwrdf0wO/8Q0RVi0Fj8AWrXuQENBD9aRLwQBACQ bFc6fV/LDSF1r9Apk/AM4KMLGjobKOsFRjILuEArsJeVkwe006IJEvV43LtmOY+5 cbMvb+CFo1vMUmyCPdmUVLsGIzCerGrFxyu5N+vhaD/ceNCmKRsuWuEDANgDV8hc qo0H8n0NVElfYhUVD5xq497QIZ9E5+QCajzpiDuf4wADBQP+Lv95PyYxmWxGJs6+ oWJMddIYoGNfJQjj3MI9w3N0Y0hRLIkh361TM0Hw7yvey+uixLBTNrWrK/IIY3D1 wm7PxwQnKBhmIujJHmdWHIf8ES3bmq7ElgSwigWGBg/y34DQNoNfUjT1fODuCdwi 3epPn2uDceBSqTkGhjYA0k3SS2qIRgQYEQIABgUCP1pEvAAKCRBKTuhHSGIYujIs AJ0TewnmAIzNX+8nPW+GcLM4dUivlgCfRpJ4bkDtf09m2FvhJVmlEw4obbw= =Zffd -----END PGP PUBLIC KEY BLOCK----- |
|
From: Dave O. <Da...@AS...> - 2004-09-22 13:26:34
|
The original use case for setData might be to associate arbitrary object (primitive or complex ones, or even another widget for custom layout data) to a Widget. Of course probably in most cases people stores strings only. I think I get it; you'd like to be able to write something like: <composite> <data x:name="someKey" x:class="someClassToConstruct" property1="value" property2="value" ... /> <!-- or --> <data x:name="someKey" x:object="anIDOfSomePreviouslyConstructedObject" /> </composite> But this really boils down to the problem of generically calling n-argument methods. Right now you can only call 1-arg methods, but if we could extend the syntax to be able to call n-arg methods, then you could get what you want with setData(), plus any other 2 or more argument method. Maybe something like this: <composite> <data x:arg0="someKey" x:class0="String" x:class1="someClassToConstruct" property1="value" property2="value" ... /> </composite> Of course (in the case of setData()) always having to specify that the data type of arg0 is a String will get tedious pretty fast, so we could just make the data type default to String if arg0Class.isAssignableFrom(java.lang.String.class) and nothing else is specified. You could also make x:class default to meaning x:classN where N is the number of arguments - 1. Then you could simply write: <composite> <data x:arg0="someKey" x:class="someClassToConstruct" property1="value" property2="value" ... /> <!-- or --> <data x:arg0="someKey" x:object="anIDOfSomePreviouslyConstructedObject" /> </composite> which would be syntactic sugar meaning the same thing as the previous example. > Similar concept can be found in Swing, putClientPropoerty/getClintProperty. > The current implementation is not a problem but I feel it may be good to > write it down as a TODO action point for next/future release. I agree. Dave |
|
From: <Yu...@no...> - 2004-09-20 12:49:54
|
Hi, can anyone teach me how to specify the Bounds? e.g. <?xml version=3D"1.0" encoding=3D"UTF-8"?> <xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt"> <import xmlns=3D"http://sweet_swt.sf.net/xswt"> <package name=3D"java.lang"/> <package name=3D"org.eclipse.swt.widgets"/> <package name=3D"org.eclipse.swt.graphics" /> <package name=3D"org.eclipse.swt.layout"/> </import> <rectangle x:id=3D"rect1" x=3D"10" y=3D"10" weight=3D"50" height=3D"50" = /> <x:children> <label text=3D"Hello World" > =20 <!-- wont work=20 <label text=3D"Hello World" bounds=3D"rect1"> --> <!-- wont work setBounds(x,y,w,h); <bounds x=3D"10" y=3D"10" weight=3D"50" height=3D"50" /> --> <!-- wont work either setBounds(Rectangle r); --> =20 </label> </x:children> </xswt> |
|
From: <Yu...@no...> - 2004-09-20 12:30:57
|
Hi, I noticed that XSWT is using CPL license, rather than EPL. Any plan to = change it? Yu |
|
From: David J. O. <dj...@co...> - 2004-09-16 15:26:29
|
On Thursday 16 September 2004 03:36 am, you wrote: > I seem to remember that we talked about a <shell> element some time ago. We did. And my recollection is that I think I begrudgingly agreed that we needed something like this, but wasn't exactly comfortable with the implementation. > At that time is was in relation to menus (as far as I'm concerned I'm > handling menus as JFace action which I really prefer my my project). Yes. > I think we need this for 2 reasons: > 1/ to fully create a Window/Dialog from an xswt file - this allows us > set size, position , styles > 2/ to set the layout type (org.eclipse.swt.widgets.Layout subclass) used > for the Window/Dialog Okay; these are two new use-cases I don't think we've discussed before. > About item 2 I have only seen from the examples that you use a hardcoded > Gridlayout like: > Shell shell = new Shell(display); > shell.setLayout(new GridLayout()); > But please correct me if I'm missing something here. Yes, all of my examples create the initial Shell and set its layout manager in Java code. And I believe you are correct to point out that this is a suboptimal design. > What I have done so far is to create a special namespace for handling > shell things like: > > <import xmlns="http://sweet_swt.sf.net/xswt"> > <package name="java.lang"/> > <package name="org.eclipse.swt.widgets"/> > </import> > <shell xmlns="mjxnamespace"> > <shell location="300 300" size="620 420" /> > </shell> > <x:children> > .... > But I think that this belongs to XSWT itself. I generally agree. > Please let me know what you think. Here's a counter-proposal: Instead of having a special <shell></shell> node, what if we provide the option to pass the Display as the parent argument to XSWT.create()? Then the top-level node beneath the first <x:children> node would be the shell--and it could do all the things you just discussed, but within XSWT's existing structure and without adding any new syntax to XSWT itself. The other use-case you brought up before was where you have a standard layout for a bunch of screens, but you want to have a different menu for each screen. I think that the best way to implement this would be through some sort of <x:include file="someHeader.xswt" /> mechanism... Then you can have several XSWT files that all call one another to bring standard content into the visual screens. > I am volunteering for this work in case. Thanks! I agree that it needs to be done. I just want to keep XSWT's own syntax as simple and clean as possible. ie: I don't want to add special cases (for the Shell or for anything else) unless it proves to be absolutely necessary. So I'm looking forward to your thoughts. Different topic, I'm CCing the xswt-developer mailing list so that others can see where we've come. Let's move our discussion to that list ASAP. Regards, Dave -- Got Java? Use SWTworkbench! <http://www.swtworkbench.com> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQGiBD9aRLsRBACTH5q/Z/42GOk0VVq2MC4pdqPAY+yOhdzp+nfyeFBbBTCZRFsd pnqiRY0+eCCBSar60bGG98acCgf9HwG2YGzrKZGUxf7GxY4iiiwcs89q3LFcp2xn Z7WeNzcNQsw0ZnfMs8fWPUF+5iHsmsYIU/IvgldwyGTQ/MWhaK28urehfwCgmVFV Y7eFawJZrlXCA7VjPhqlkzMD/jBsxNxHXUpMR2xzE/HN0Cz4nkkR7aaCQNPe0Lmy 9Y/D5NGcJunoNkwGI2rFO0wwgjqgE0Lknv7/U1yK1/085kTufBcDZNEgbw93uPmx 5mKnWe3oq+iTqV742DQSyOgWmQ4RqcK9whZDpIwXl3biRKw/aQIq2Vs1k6a6AxqT KLCXA/4zUPQ7gs0d44K6Fc4zVEJVPyD5pVf6iTSpQNjd8iTn++i9dGymEP73EIJd uVDDU7Y0P7OydVAwfISaZvnYmX9UvnOV5wr9JWgH+lcrANaRb2Xryz65mGnhj6QO qaTJyjU79M0N4kaVwu/8vENO7lg1K9hpW5Fb2LEDaZuxZYRDyLYAAAAtRGF2aWQg Si4gT3JtZSA8ZGpvQGNvY29udXQtcGFsbS1zb2Z0d2FyZS5jb20+iFsEExECABsF Aj9aRLsGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQSk7oR0hiGLp+bgCgix8nVvZs fpz4RJ5krVZRYPPeIwkAn3KK3Xwrdf0wO/8Q0RVi0Fj8AWrXuQENBD9aRLwQBACQ bFc6fV/LDSF1r9Apk/AM4KMLGjobKOsFRjILuEArsJeVkwe006IJEvV43LtmOY+5 cbMvb+CFo1vMUmyCPdmUVLsGIzCerGrFxyu5N+vhaD/ceNCmKRsuWuEDANgDV8hc qo0H8n0NVElfYhUVD5xq497QIZ9E5+QCajzpiDuf4wADBQP+Lv95PyYxmWxGJs6+ oWJMddIYoGNfJQjj3MI9w3N0Y0hRLIkh361TM0Hw7yvey+uixLBTNrWrK/IIY3D1 wm7PxwQnKBhmIujJHmdWHIf8ES3bmq7ElgSwigWGBg/y34DQNoNfUjT1fODuCdwi 3epPn2uDceBSqTkGhjYA0k3SS2qIRgQYEQIABgUCP1pEvAAKCRBKTuhHSGIYujIs AJ0TewnmAIzNX+8nPW+GcLM4dUivlgCfRpJ4bkDtf09m2FvhJVmlEw4obbw= =Zffd -----END PGP PUBLIC KEY BLOCK----- |
806 messages has been excluded from this view by a project administrator.
