luxor-xul-develop Mailing List for Luxor XUL (Page 3)
Status: Beta
Brought to you by:
vamp201
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(8) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
2004 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(17) |
Jun
(9) |
Jul
(5) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2005 |
Jan
(1) |
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Gerald B. <ge...@va...> - 2004-04-19 09:00:38
|
Hello Dale, > Sure, that would be good. If you did the initial > import, that would > help me get up and running. Let me know when > everything is ready. Please give me two to three days to get everything ready and setup. > Also, would it be possible to add a /lib with all > the current > dependencies? Well, I know that the Luxor library dependency is a major hassle. Welcome to jar hell. There's no easy way to solve it. I'm not sure if checking in libraries would help. One alternative is to upload the latest libraries to the sourceforge site e.g http://luxor-xul.sourceforge.net/lib/* My prefered model is to use Maven to manage dependencies and to offer on-demand loading of libraries using repositories. I will take up the Maven switch over for real this week because the current situation is holding everybody back. Let me know if anyone has any ideas or alternative approaches on how to "solve" the dependency problem. Please note that cutting back on third-party libraries is a non-solution. The only way forward is reuse, reuse, reuse and that means building heavily on the work of others. Just using Sun only "standard" libraries is not the way forward. I'm sorry if anyone feels that this is a deal breaker/show stopper. - Gerald |
From: R. D. A. <lux...@da...> - 2004-04-18 22:24:43
|
On Sun, 2004-04-18 at 03:50, Gerald Bauer wrote: > Hello Dale, > ... > I'm pretty new to AspectJ. I suggest starting by > copying all Luxor sources in a new module such as > luxor-aspectj so you can start refactoring > crosscutting concerns and we can see it all in action > and try it out. > Good idea. > Let me know if you're interested and I'll add you to > the developer list and also let me know if you want me > to do the initial import into the sourceforge CVS. > Also if you want to use a different approach let us > know. > Sure, that would be good. If you did the initial import, that would help me get up and running. Let me know when everything is ready. Also, would it be possible to add a /lib with all the current dependencies? Regards, Dale > - Gerald > > PS: For more info about Dale's AspectJ use see the > Memphis Sun blog story titled "AspectJ In Action: > Weave In Your Own Luxor XUL Widget Attributes" online > @ http://luxor-xul.sourceforge.net/sun/2004/01/aspectj_in_action_weave_in_your_own_luxor_xul_widget_attributes.html |
From: Gerald B. <ge...@va...> - 2004-04-18 18:27:29
|
Hello David, > Is there a document anywhere that specifies the > goals of the Luxor > project, and the plan for acheiving them? Well, there's a "Blue Sky - What's Next?" which is about two years old I think. For high-level goals you might wonna check out the VanX talk titled "Luxor: The "Linux Kernel" for Desktop Apps - Uniting XUL, SVG, HTML, Velocity, Web Start, XSL/T, Python and more online @ http://luxor-xul.sourceforge.net/talk/vanx-jul-2002/slides.html If I may quote: Luxor Xul Design Principles - Freedom, Choice, Excellence * Reuse, Reuse, Reuse. Build on existing infrastructure. Don't reinvent the wheel, the tooth brush or the alphabet. * No hidden agenda. No backdoor. No lock-in. * No sacred cows. Cut the crap. No bullshit. Clean it up, Mr. Fix. * No kings or queens. Everyone is welcome. Working code beats know-it-all blabber. * Release early. Release often. No big bang and design behind closed door a la Billy Boy and the Yes-man brigade. * Modul-mania. Extensible. Embeddable. Five Freedoms - Xul Charter * Freedom to Choose Your Runtime - Java, Mono, C/C++ * Freedom to Choose Your GUI Designer - * Freedom to Choose Your GUI Toolkit - Swing, SWT, Gtk#, Qt * Freedom to Choose Your Scripting Language - Python, Perl, Tcl * Freedom to Choose Your Programming Language - Java, C#, Shark > >From the Luxor overview: > -Separate the UI into 4 distinct parts: content, > appearance, behavior, > locale > -Make UI building easier than writing it all in Java > -Free from GUI toolkit lock-in > > Others I think should be included: > -Ease of development (rewording of #2 above; > easy-to-use API with complete documentation) Definitely. Everyone agrees on making the API much easier to use. Also I guess everyone agrees on complete documentation. However, who's going to put in some cycles? One idea is to use XDoclet tags to mark public API methods and use the XDoclet tags to generate some docs. The current API reference is online @ http://luxor-xul.sourceforge.net/apiref.html > -Well-defined XML formats Definitely. I've started to use the Relax NG XML schema language to define the XML UI format. Again I suggest using XDoclet tags to mark XUL tags e.g. @xul.tag.name=hbox etc. > -Simplicity (avoiding feature creep, excess XUL > tags, etc.) I'm all for keep it simple stupid and also for cleaning up the current API. > -Use "standard" libraries when appropriate > -Dependencies on external libraries only when > "needed" Well, the Luxor philosophy is don't reinvent the wheel, the toothbrush and so on and also to avoid the not invented here (NIH) syndrom. I consider Apache libraries such as log4j, Velocity, commons-collection, commons-beanutils, etc. "standard". Another philosophy of Luxor is modul-mania, that is, to put non-Luxor code in separate libraries/modules (e.g. Rachel, Salsa, Caramel, Houston, etc.) to help reuse. If you think that "branding" each library is excessive I open to fold all libraries under a single umbrella/namespace. > With these in mind, I think that the first goal > should be ease of > development, with the discussion in the user list on > Thursday in mind, > starting with discussion of how we think users > should interact with the > Luxor API, and then design of an API that > facilitates this. > > An approach: > -Have a class (for now, call it XulManager) with the > following methods: > Object getRootComponent(final String path); > Object getComponent(final String path, final String > id); Your suggested helper methods are more than welcome. I suggest using get() instead of getComponent() and loadForm() instead of getRootComponent() for example. > The "path" argument is the name of a XUL bundle (set > of XML files), which > defines a top-level window (frame, dialog, etc.). > Using getRootComponent, > you can retrieve that window. Alternatively, using > getComponent, you can > retrieve any arbitrary component within the window > by id as specified in > the XUL. > > In this example, the return types are Object. This > allows flexibility as > to the GUI toolkit used to implement the manager. > > -For a particular GUI toolkit, provide a Facade. > For example, a SwingFacade might provide the > following methods: > public final JPanel getPanel(final String path, > final String id); > public final JFrame getFrame(final String path); > public final JDialog getDialog(final String path); > public final JWindow getWindow(final String path); > public final JTextArea getTextArea(final String > path, final String id); > public final JTextField getTextField(final String > path, final String id); > ... I support your idea of using type-safe helper methods. As far as I rember I already started to create some e.g. getPanel, getFrame, etc. > If it turned out that retreiving components by id > was a frequent > operation Well, I think getting widgets by id is the most important operation, thus, my suggestion to use simply get( String id ). > we could have a variation on the Facade > that was specific to a > XUL bundle, thus requiring only the component id as > an argument. > > -XML format restructuring > As stated on the Luxor overview, we wish to separate > the UI into 4 > distinct parts. Our existing XUL format handles > content/layout fairly > well, though it could use a bit of tuning. > > Appearance can be handled by CSS, which is a > standard format with a > standard API to read (SAC). Rather than embed our > styling information in > the XUL file, I would prefer to have it in an > external file, to promote > distinctness between the 4 UI parts. Well, Anakreon just checked in his code into CVS that supports external CSS sytlesheets. I wrote up a Memphis Sun story a while ago. See http://luxor-xul.sourceforge.net/sun/2003/12/luxor_xul_now_sports_external_css_stylesheets.html > I think that behavior should be handled by some form > of behavior mapping > XML file, where you associate standard GUI > controller classes with > components defined in the layout file. For example, > you could have an > entry specifying that the action for the OK button > should be > com.something.OKAction, and that the mouse listener > for a certain table > should be com.something.MyListener. This might also > be an appropriate > place to allow things like setting custom models, > renderers, editors, etc. Well, for behavior I suggest scripting and also auto-wiring using reflection using naming conventions as you suggested. > For localization, traditional Properties > ResourceBundles are a good start. Sorry. Resource Bundles are too Java specific. The idea of XUL is to be language independent. Thus, I suggest using simple string tables, that is, Java properties files but without any Java resource bundle classes and use our own locale-sensitive/culture-sensitive lookup instead similar to Mozilla or Microsoft .Net. > These could be linked into the layout file either by > defining certain > attributes to specify the name of a key in the > ResourceBundle, or by using > a ${key} syntax to allow localization in any > attribute. Well, this already works using Velocity preprocessing of XUL documents. Sorry, if it's not advertised anywhere. > I'm less > clear on how the internationalization of layouts > themselves works. For > example, when in a locale with right-to-left reading > order, the labels > should be to the right of their associated GUI > objects. Perhaps to > support this, we should look up layout files by > locale similarly to how > localization properties files are located. Sounds like a reasonable approach. Let me know if this answers your questions and what part you want to take on. - Gerald |
From: David C. <da...@ca...> - 2004-04-18 15:27:37
|
Is there a document anywhere that specifies the goals of the Luxor project, and the plan for acheiving them? >From the Luxor overview: -Separate the UI into 4 distinct parts: content, appearance, behavior, locale -Make UI building easier than writing it all in Java -Free from GUI toolkit lock-in Others I think should be included: -Ease of development (rewording of #2 above; easy-to-use API with complete documentation) -Well-defined XML formats -Simplicity (avoiding feature creep, excess XUL tags, etc.) -Use "standard" libraries when appropriate -Dependencies on external libraries only when "needed" With these in mind, I think that the first goal should be ease of development, with the discussion in the user list on Thursday in mind, starting with discussion of how we think users should interact with the Luxor API, and then design of an API that facilitates this. An approach: -Have a class (for now, call it XulManager) with the following methods: Object getRootComponent(final String path); Object getComponent(final String path, final String id); The "path" argument is the name of a XUL bundle (set of XML files), which defines a top-level window (frame, dialog, etc.). Using getRootComponent, you can retrieve that window. Alternatively, using getComponent, you can retrieve any arbitrary component within the window by id as specified in the XUL. In this example, the return types are Object. This allows flexibility as to the GUI toolkit used to implement the manager. -For a particular GUI toolkit, provide a Facade. For example, a SwingFacade might provide the following methods: public final JPanel getPanel(final String path, final String id); public final JFrame getFrame(final String path); public final JDialog getDialog(final String path); public final JWindow getWindow(final String path); public final JTextArea getTextArea(final String path, final String id); public final JTextField getTextField(final String path, final String id); ... If it turned out that retreiving components by id was a frequent operation, we could have a variation on the Facade that was specific to a XUL bundle, thus requiring only the component id as an argument. -XML format restructuring As stated on the Luxor overview, we wish to separate the UI into 4 distinct parts. Our existing XUL format handles content/layout fairly well, though it could use a bit of tuning. Appearance can be handled by CSS, which is a standard format with a standard API to read (SAC). Rather than embed our styling information in the XUL file, I would prefer to have it in an external file, to promote distinctness between the 4 UI parts. I think that behavior should be handled by some form of behavior mapping XML file, where you associate standard GUI controller classes with components defined in the layout file. For example, you could have an entry specifying that the action for the OK button should be com.something.OKAction, and that the mouse listener for a certain table should be com.something.MyListener. This might also be an appropriate place to allow things like setting custom models, renderers, editors, etc. For localization, traditional Properties ResourceBundles are a good start. These could be linked into the layout file either by defining certain attributes to specify the name of a key in the ResourceBundle, or by using a ${key} syntax to allow localization in any attribute. I'm less clear on how the internationalization of layouts themselves works. For example, when in a locale with right-to-left reading order, the labels should be to the right of their associated GUI objects. Perhaps to support this, we should look up layout files by locale similarly to how localization properties files are located. ----------------------------- David Carr ----------------------------- Email: da...@ca... ----------------------------- |
From: Gerald B. <ge...@va...> - 2004-04-18 08:50:35
|
Hello Dale, > How would the team feel if I started refactoring > crosscutting concerns > using AspectJ? > > This would put a build dependency on the ajc > compiler and a build and > runtime dependency on aspectjrt.jar (29k). I > understand that the > biggest dependency is on developers feeling > comfortable with this new > approach. I'm pretty new to AspectJ. I suggest starting by copying all Luxor sources in a new module such as luxor-aspectj so you can start refactoring crosscutting concerns and we can see it all in action and try it out. Let me know if you're interested and I'll add you to the developer list and also let me know if you want me to do the initial import into the sourceforge CVS. Also if you want to use a different approach let us know. - Gerald PS: For more info about Dale's AspectJ use see the Memphis Sun blog story titled "AspectJ In Action: Weave In Your Own Luxor XUL Widget Attributes" online @ http://luxor-xul.sourceforge.net/sun/2004/01/aspectj_in_action_weave_in_your_own_luxor_xul_widget_attributes.html |
From: R. D. A. <lux...@da...> - 2004-04-17 23:21:25
|
Hello all, How would the team feel if I started refactoring crosscutting concerns using AspectJ? This would put a build dependency on the ajc compiler and a build and runtime dependency on aspectjrt.jar (29k). I understand that the biggest dependency is on developers feeling comfortable with this new approach. Regards, Dale |
From: Gerald B. <ge...@va...> - 2003-12-23 23:19:44
|
Hello Dale, > I just realized after looking at the samples, that > font styles are selected > using the "font: 15 italic" format. I apologize for > not investigating this > before asking the list. No worries. The Luxor XUL documentation is unfortunately far from complete. - Gerald |
From: Gerald B. <ge...@va...> - 2003-12-23 23:17:44
|
Hello Dale, >> Can you post an example of what you're trying to >> achieve? > > Sure... > > <label value="Welcome to the Installer" > style="font-size: 10; font-style: > normal; font-family: arial" /> > <button label="Next" style="font-size: 10; > font-weight: bold; font-family: > sans-serif" /> > > It seems that these styles don't work on Swing apps. Thanks for the example. As you already found out Luxor currently supports only the all-in-one font property. > I have an open source project (judy.jini.org) that > requires significant > configuration to run properly. Since it is open > source, I don't want to > rely on the "free" versions of the commercial > installers. That lead to some > investigations of open source installers out there. > Unfortunately, I was > disappointed with the lack of features in the few > that I found, and almost > all of them were difficult to use or extend. I > temporarily decided to use > IzPack (www.izforge.com/izpack/). It can do some > very simple installations, > however, configuring a Jini service can get quite > involved and I realized I > could write some Ant scripts to fill in the missing > functionality. > Unfortunately, the project owner objected to that > use of the izpack code. I > considered how long it would take to implement calls > to Ant scripts and the > difficulty in maintaining a fork and decided to look > elsewhere. I looked at > Jelly, was very impressed, but didn't like the > dependency on Maven. I > finally came across XUL and Luxor and realized I had > a great match. > > So far, I've implemented very basic features for > loosely coupling XulActions > to xul components. I'm able to define simple > screens that navigate back and > forth (which can be dynamically reloaded to pick up > changes made to the XUL > source files) and I did it with about 30 hours of > coding! As I progress, I > plan on implementing an AntScriptAction that calls > Ant scripts and various > other convenience actions (like enabling/disabling > other buttons). Frankly, > I think I've accomplished more in a shorter time > frame by building it around > XUL than it would have taken to enhance any other > installer product. > > The installer is open source licensed under the CPL. > I will be hosting the > project on java.net, but am more interested in > getting it working for my > Jini project first ;-) If anyone else is interested > in contributing, I can > put it up now! Whow. That sounds fantastic. I can't wait to see it. I will do all I can to promote it. I invite you to keep us up-to-date. I also invite you to zip up your sources and send them to my private email address (that is, ge...@va...) and I'll add your package to luxor-contrib right away and start promoting it. > Would you object to Installux for > the project name > considering the closeness to Luxor? No, go ahead. Since your project is open source you have my full support. You might also consider naming it Install Luxe or Installer DeLuxe or similar. Keep it up. Great stuff. - Gerald |
From: R. D. A. <lux...@da...> - 2003-12-23 19:18:14
|
I just realized after looking at the samples, that font styles are selected using the "font: 15 italic" format. I apologize for not investigating this before asking the list. > -----Original Message----- > From: lux...@li... > [mailto:lux...@li...]On Behalf Of R. > Dale Asberry > Sent: Tuesday, December 23, 2003 10:40 AM > To: lux...@li... > Subject: [luxor-xul-develop] Using css to set font props in Swing app > > > I'm developing an XUL-based Swing app around a framework that loosely > couples actions to xul components. The goal of my project is to easily > create rich, scriptable installation packages. > > The problem I want to solve is to minimize the amount of > custom/Swing/action > code needed by the scripter for simple things like setting various font > properties like typeface, modifiers like italic, and font size. The Luxor > XUL CSS reference in the overview paragraph suggests that these things can > be set using CSS, however, it doesn't appear to work. Am I missing > something? If the code to enable this is incomplete, where would I start > for implementing it? > > Thanks, > Dale Asberry > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > luxor-xul-develop mailing list > lux...@li... > https://lists.sourceforge.net/lists/listinfo/luxor-xul-develop > |
From: R. D. A. <lux...@da...> - 2003-12-23 17:48:54
|
> Hi Dale, > > > The problem I want to solve is to minimize the > > amount of custom/Swing/action > > code needed by the scripter for simple things like > > setting various font > > properties like typeface, modifiers like italic, and > > font size. The Luxor > > XUL CSS reference in the overview paragraph suggests > > that these things can > > be set using CSS, however, it doesn't appear to > > work. Am I missing > > something? If the code to enable this is > > incomplete, where would I start > > for implementing it? > > Can you post an example of what you're trying to > achieve? Sure... <label value="Welcome to the Installer" style="font-size: 10; font-style: normal; font-family: arial" /> <button label="Next" style="font-size: 10; font-weight: bold; font-family: sans-serif" /> It seems that these styles don't work on Swing apps. > > Also can you let us know more about your project to > create rich, scriptable installation packages? Is it > open-source? Is it hosted on sourceforge? etc. I have an open source project (judy.jini.org) that requires significant configuration to run properly. Since it is open source, I don't want to rely on the "free" versions of the commercial installers. That lead to some investigations of open source installers out there. Unfortunately, I was disappointed with the lack of features in the few that I found, and almost all of them were difficult to use or extend. I temporarily decided to use IzPack (www.izforge.com/izpack/). It can do some very simple installations, however, configuring a Jini service can get quite involved and I realized I could write some Ant scripts to fill in the missing functionality. Unfortunately, the project owner objected to that use of the izpack code. I considered how long it would take to implement calls to Ant scripts and the difficulty in maintaining a fork and decided to look elsewhere. I looked at Jelly, was very impressed, but didn't like the dependency on Maven. I finally came across XUL and Luxor and realized I had a great match. So far, I've implemented very basic features for loosely coupling XulActions to xul components. I'm able to define simple screens that navigate back and forth (which can be dynamically reloaded to pick up changes made to the XUL source files) and I did it with about 30 hours of coding! As I progress, I plan on implementing an AntScriptAction that calls Ant scripts and various other convenience actions (like enabling/disabling other buttons). Frankly, I think I've accomplished more in a shorter time frame by building it around XUL than it would have taken to enhance any other installer product. The installer is open source licensed under the CPL. I will be hosting the project on java.net, but am more interested in getting it working for my Jini project first ;-) If anyone else is interested in contributing, I can put it up now! Would you object to Installux for the project name considering the closeness to Luxor? Dale |
From: Gerald B. <ge...@va...> - 2003-12-23 16:17:34
|
Hi Dale, > I'm developing an XUL-based Swing app around a > framework that loosely > couples actions to xul components. The goal of my > project is to easily > create rich, scriptable installation packages. > > The problem I want to solve is to minimize the > amount of custom/Swing/action > code needed by the scripter for simple things like > setting various font > properties like typeface, modifiers like italic, and > font size. The Luxor > XUL CSS reference in the overview paragraph suggests > that these things can > be set using CSS, however, it doesn't appear to > work. Am I missing > something? If the code to enable this is > incomplete, where would I start > for implementing it? Can you post an example of what you're trying to achieve? Also can you let us know more about your project to create rich, scriptable installation packages? Is it open-source? Is it hosted on sourceforge? etc. - Gerald |
From: R. D. A. <lux...@da...> - 2003-12-23 15:38:06
|
I'm developing an XUL-based Swing app around a framework that loosely couples actions to xul components. The goal of my project is to easily create rich, scriptable installation packages. The problem I want to solve is to minimize the amount of custom/Swing/action code needed by the scripter for simple things like setting various font properties like typeface, modifiers like italic, and font size. The Luxor XUL CSS reference in the overview paragraph suggests that these things can be set using CSS, however, it doesn't appear to work. Am I missing something? If the code to enable this is incomplete, where would I start for implementing it? Thanks, Dale Asberry |
From: R. D. A. <dal...@da...> - 2003-12-23 15:34:09
|
I'm developing an XUL-based Swing app around a framework that loosely couples actions to xul components. The goal of my project is to easily create rich, scriptable installation packages. The problem I want to solve is to minimize the amount of custom/Swing/action code needed by the scripter for simple things like setting various font properties like typeface, modifiers like italic, and font size. The Luxor XUL CSS reference in the overview paragraph suggests that these things can be set using CSS, however, it doesn't appear to work. Am I missing something? If the code to enable this is incomplete, where would I start for implementing it? Thanks, Dale Asberry |
From: Gerald B. <ge...@va...> - 2003-12-08 18:01:19
|
Hello David Carr, > I noticed that these files had numerous fix and todo > comments to allow > proper loading of config and bootstrap entries. > Attached are versions > with implementations for those methods. The index > file used by the > ClassResourceLoader is just a properties file; the > keys are ignored, and > all values are added to the entries. Thanks for sending in your patch. I invite you to fix up your property lookup. The property lookup is supposed to be locale/culture sensitive, that is, depending on your default locale you will get different values back. Also I don't see a need for a separate property index file. Can you explain why it's needed? Let me know if you're intersted in improving your patch. It shouldn't be too hard. If you have any questions let me know. - Gerald |
From: David C. <da...@ca...> - 2003-12-07 07:20:33
|
I noticed that these files had numerous fix and todo comments to allow proper loading of config and bootstrap entries. Attached are versions with implementations for those methods. The index file used by the ClassResourceLoader is just a properties file; the keys are ignored, and all values are added to the entries. ----------------------------- David Carr ----------------------------- Email: da...@ca... AIM : davidmc24/Varzof Phone: 518-272-3901 Web : http://david.carr.name ----------------------------- |
From: Klaus H. <js...@gm...> - 2003-06-05 19:12:47
|
Damien Merenne wrote: > Is there some luxor related project to generate an awt gui wich would be > usable on a pda ? Did someone made some experiences wih an SWT-XUL motor on PocketPC? As far as I know SWT should work on a PocketPC: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/dev.html#pocketsnippets |
From: Gerald B. <ge...@va...> - 2002-12-02 17:35:52
|
Hi Damien, > Is there some luxor related project to generate an > awt gui wich would be > usable on a pda ? You might want to check out Thinlet online at http://www.thinlet.com - a XUL motor in Java using AWT and created for mobile devices. - Gerald |
From: Damien M. <da...@ca...> - 2002-12-01 15:54:57
|
Hi, Is there some luxor related project to generate an awt gui wich would be usable on a pda ? Damien -- Damien Merenne <da...@ca...> |
From: Gerald B. <ge...@va...> - 2002-10-10 06:55:34
|
Hi Martin, Great to hear from you. Your SWT prototype is tallying up hundreds of downloads. I will start work on Nile once I have uploaded the Ramses Beta Refresh (that includes a couple of new examples) hopefully by Friday. Thanks for your suggestions. I will also try to include all your previous SWT suggestions to make Nile not dependent on a single toolkit. > * Although I'm a fan of Jython, it make sense to be > open for other scripting > languages like Javascript, BeanShell, Dynamic Java, > Pnuts, etc. > So why not use IBM's free Bean Scripting Framework For now I'm not a supporter of the Bean Scripting Framework as I don't believe in lowest common denominator. I will check it again to see if I'm mistaken. I chose Python because it offers the most features/power lacking from BeanShell, Javascript, Pnuts, etc. and Python is truly cross-platform and also truly open-source and available in C and C# flavors too, not just Java. > * Usage of the commons-logging from > jakarta.apache.org as a replacement of > the houston Logger. There are two major logging > packages out there: Log4J > from Apache and the java.util.logging package from > JDK 1.4. The > commons-logging package library is a common layer > for both and quite easy to > use. > BTW, do you really need a separate Status class with > similar functionality > like a logging ? I used to use log4j but I switchted for Java 1.4 to Java's new built-in logging package. To allow easy switching to a different logging toolkit such as log4j I created houston as a light-weight layer on top. I will check the Apache commons-logging package and use it if it is logging package wrapper like houston. I don't want to reinvent yet another logging toolkit. > Have you taken a look on the Jelly project (see > http://jakarta.apache.org/commons/sandbox/jelly/index.html) > ? Such a XML > processing engine can be useful for Luxor, too. Jelly looks promising and I will add it once I have tried it. - Gerald |
From: <mar...@t-...> - 2002-10-09 20:50:31
|
Hi Gerald, It's great that you are back ! On Wed, 2002-10-09 at 12:21, Gerald Bauer wrote: > I will start work on project Nile next week. Nile in > a nutshell will be a stripped down Luxor Lite/Core > version that transforms markup from input streams into > UIs. > > Also a goal of Luxor is to let you replace module > (e.g. logging, resource loading, etc.) as you see fit. In this context I want to comment: * Usage of the commons-logging from jakarta.apache.org as a replacement of the houston Logger. There are two major logging packages out there: Log4J from Apache and the java.util.logging package from JDK 1.4. The commons-logging package library is a common layer for both and quite easy to use. BTW, do you really need a separate Status class with similar functionality like a logging ? * Although I'm a fan of Jython, it make sense to be open for other scripting languages like Javascript, BeanShell, Dynamic Java, Pnuts, etc. So why not use IBM's free Bean Scripting Framework as an abstraction layer ? (see e.g. http://www.javaworld.com/javaworld/jw-04-2002/jw-0405-scripts.html as a starting point) * Have you taken a look on the Jelly project (see http://jakarta.apache.org/commons/sandbox/jelly/index.html) ? Such a XML processing engine can be useful for Luxor, too. cheers, Martin Weindel |
From: Gerald B. <ge...@va...> - 2002-08-30 19:46:41
|
Hi, Looks great. I had something similar in mind to make it easier to add new xul tags (something along the lines of new ant tasks). > It's just a quick hack, and it might be better to > use an xml file format where the content can be > extended eg: > <xul-tag name="button" > node="luxor.core.input.ButtonDef" /> I guess the best way is to follow the Ant model, that is, use java properties for built-in tags and allow xml tags in arbitrary xul docs for custom tags (similar to ant's taskdef). > One benefit here is that the set of tags can be > extended, especially if > the 'discovery' mechanism searches for these tag > mapping files on the class > path. Allowing easy extensibility with your own tags is a major priority and I will add it as soon as possible. Great stuff, keep it up. > I would prefer to have a separate class to deal with > this mapping (XulNodeMap?) and let XulLoader deal > with it via an interface. The > implementation of the interface could be decided > from a config file > which would make the thing pluggable (Swing/SWT?) Having a XulNodeMapper/XulNodeMap/XulTagMapper or however you name it makes definitely sense. I disagree with plugable Swing/SWT config files. I rather have two different distros/packages to keep the messy internals easy to maintain without having to know more than one toolkit (along the line of the SWT architecture in constrast to AWT disaster). However, this doesn't exclude a common core for both toolkits. I don't see a need to switch toolkits (SWT/Swing) at runtime. It also bloats the distro and gets out of hand once you add another toolkit such as Gtk.Java or Qt.Java or whatever. - Gerald |
From: mhenderson <mhe...@be...> - 2002-08-30 18:11:18
|
Hi, I looked over the 1.0b5 source code and tried a technique to externalize the mapping from xul element tag (<button>, etc) to the XULNode class. I modified XulLoader.java: /* ** Luxor - XML User Interface Language (XUL) Toolkit ** Copyright (c) 2001, 2002 by Gerald Bauer ** ** This program is free software. ** ** You may redistribute it and/or modify it under the terms of the GNU ** General Public License as published by the Free Software Foundation. ** Version 2 of the license should be included with this distribution in ** the file LICENSE, as well as License.html. If the license is not ** included with this distribution, you may find a copy at the FSF web ** site at 'www.gnu.org' or 'www.fsf.org', or you may write to the ** Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139 USA. ** ** THIS SOFTWARE IS PROVIDED AS-IS WITHOUT WARRANTY OF ANY KIND, ** NOT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY. THE AUTHOR ** OF THIS SOFTWARE, ASSUMES _NO_ RESPONSIBILITY FOR ANY ** CONSEQUENCE RESULTING FROM THE USE, MODIFICATION, OR ** REDISTRIBUTION OF THIS SOFTWARE. ** */ package luxor.core; import java.lang.reflect.*; import java.io.*; import java.util.*; import org.jdom.*; import org.jdom.input.*; import luxor.core.box.*; import luxor.core.data.*; import luxor.core.grid.*; import luxor.core.input.*; import luxor.core.menu.*; import luxor.core.misc.*; import luxor.core.portal.*; import luxor.core.tab.*; import luxor.core.table.*; import luxor.core.toolbar.*; import luxor.core.widget.*; import luxor.core.xslt.*; import houston.*; import luxor.*; public class XulLoader { private static Properties defMap; static { try { defMap = new Properties(); defMap.load(XulLoader.class.getResourceAsStream("XulNodeMap.properties")); } catch (Exception ex) { } } private static String getDefClassNameForType(String type) { return (String)defMap.get(type); } static Logger T = Logger.getLogger( XulLoader.class ); private XulManager _manager; public XulLoader( XulManager manager ) { _manager = manager; } public void load( String name ) { try { T.debug( "loading xul file " + name ); InputStream in = _manager.getResourceAsStream( name ); SAXBuilder builder = new SAXBuilder(); Document doc = builder.build( in ); Element xul = doc.getRootElement(); createElements( null, xul ); T.debug( "xul file " + name + " successfully loaded" ); } catch( JDOMException jex ) { Xul.error( "failed to load xul file '" + name + "': " + jex.toString() ); } } protected void createElements( XulContainer parent, Element element ) { String type = element.getName(); if( type.equals( Xul.Element.XUL ) ) { parent = new XulDef( element, _manager ); } else { try { String defClassName = getDefClassNameForType(type); Class defClass = Class.forName(defClassName); Class[] types = new Class[] { Element.class, }; Constructor constructor = defClass.getConstructor(types); Object[] args = new Object[] { element }; XulNode def = (XulNode)constructor.newInstance(args); parent.add(def); parent = (def instanceof XulContainer) ? (XulContainer)def : null; } catch (Exception ex) { System.out.println("Exception: " + ex); ex.printStackTrace(); Xul.syntax( "unsupported element '" + type + "'" ); } } if (parent != null) { // process children List list = element.getChildren(); for( Iterator it = list.iterator(); it.hasNext(); ) { Element child = ( Element ) it.next(); createElements( parent, child ); } } } } // END of source and added a properties file: anim=luxor.core.misc.AnimDef box=luxor.core.box.BoxDef button=luxor.core.input.ButtonDef caption=luxor.core.box.CaptionDef checkbox=luxor.core.input.CheckBoxDef choice=luxor.core.input.ChoiceDef col=luxor.core.widget.ColDef colgroup=luxor.core.widget.ColGroupDef column=luxor.core.grid.ColumnDef columns=luxor.core.grid.ColumnsDef command=luxor.core.misc.CommandDef componentref=luxor.core.widget.ComponentRef datagrid=luxor.core.widget.DataGridDef displayurl=luxor.core.menu.DisplayUrlDef entry=luxor.core.data.ListEntryDef gadgetluxor.core.widget.ComponentRef grid=luxor.core.grid.GridDef groupbox=luxor.core.box.GroupBoxDef hbox=luxor.core.box.HBoxDef icon=luxor.core.misc.IconDef iframe=luxor.core.widget.IFrameDef image=luxor.core.widget.ImageDef key=luxor.core.misc.KeyDef keyset=luxor.core.misc.KeySetDef # more fancy synomym for componentref label=luxor.core.input.LabelDef list=luxor.core.data.ListDef map=luxor.core.data.MapDef mchoice=luxor.core.input.MChoiceDef menu=luxor.core.menu.MenuDef menubar=luxor.core.menu.MenuBarDef menuitem=luxor.core.menu.MenuItemDef menupopup=luxor.core.menu.MenuPopupDef menuref=luxor.core.menu.MenuRef menuseparator=luxor.core.menu.MenuSeparatorDef password=luxor.core.input.PasswordDef popup=luxor.core.menu.PopupDef portal=luxor.core.PortalDef portlet=luxor.core.PortletRef pre=luxor.core.misc.PreDef row=luxor.core.grid.RowDef rows=luxor.core.grid.RowsDef separator=luxor.core.widget.SeparatorDef spacer=luxor.core.widget.SpacerDef stylesheet=luxor.core.xslt.StylesheetDef tab=luxor.core.tab.TabDef tabbox=luxor.core.tab.TabBoxDef table=luxor.core.table.TableDef tabpanel=luxor.core.tab.TabPanelDef tabpanels=luxor.core.tab.TabPanelsDef tabs=luxor.core.tab.TabsDef td=luxor.core.table.TableDataDef text=luxor.core.input.TextDef textarea=luxor.core.input.TextAreaDef toolbar=luxor.core.toolbar.ToolBarDef toolbarbutton=luxor.core.toolbar.ToolBarButtonDef toolbarseparator=luxor.core.toolbar.ToolBarSeparatorDef tr=luxor.core.table.TableRowDef tree=luxor.core.widget.TreeDef vbox=luxor.core.box.VBoxDef I tested this with box.jnlp in ramses and it seemd to work. It's just a quick hack, and it might be better to use an xml file format where the content can be extended eg: <xul-tag name="button" node="luxor.core.input.ButtonDef" /> One benefit here is that the set of tags can be extended, especially if the 'discovery' mechanism searches for these tag mapping files on the class path. I would prefer to have a separate class to deal with this mapping (XulNodeMap?) and let XulLoader deal with it via an interface. The implementation of the interface could be decided from a config file which would make the thing pluggable (Swing/SWT?) What do you think? Mike |
From: Gerald B. <ge...@va...> - 2002-08-27 20:20:34
|
Hi Daniel, > I am very interested in getting involved in the work > with this project. You are more than welcome to join in. > The first concern is > that their is only one > developer listed on the sourceforge site. I don't hand out "committer" status willy-nilly. Check out jxul and see why this doesn't work. However, I plan to cut down the red tape and make it easier to contribute to the source. Using CVS for now is just unnesessary overhead. See the discussion threads http://sourceforge.net/mailarchive/forum.php?thread_id=899528&forum_id=9424 and http://sourceforge.net/mailarchive/forum.php?thread_id=906295&forum_id=9425 for details. Eventually once the source is more stable I move it into CVS. > I don't > believe that this is > a one-man show; No it isn't. My grandma is helping me out. > however, it concerns me that I can > only view the source > on-line...i.e. I cannot access the source, run > builds against it You can download the source. You can built Luxor and Ramses and so on. Please check again. > If others are developing this > framework, where is > this code submitted to and why is the source for > these new submissions Please see the threads mentioned above. > Modul-mania. New modules include: Apollo, > Caramel, Houston, Rachel, > and Salsa > o Apollo - Test Skeleton for Web > Start/JNLP > o Caramel - Java Extensions (non-GUI > only) > o Houston - Yet Another Status and > Logging Toolkit > o Rachel - Resource Loading (includes > HTTP web service) > o Salsa - Swing GUI Add-Ons > > not viewable or accessible except in binary format > (JAR files)? I will post the source once I get back from my holiday. Eventually I want to create a site for each module, for now, however, I will bundle the source with Luxor. > I would like to become a contributor, however this > project "smells" like > a proprietary project under the guise of > "OpenSource". If I am wrong I > sincerely apologies -- I am not out to flame anyone You are wrong. Luxor use the GNU GPL. Please educate yourself at the Free Software Foundation for details. If the GPL doesn't work for you, check out Xulux - a Java Xul project just starting using the Apache License. > -- I just want to be > given a fair chance to contribute my piece...without > fear of having it > taken away by someone "dual" licensing my > contributions; Again Luxor is licensed under the GPL. For commercial projects that don't want to be bound by the GPL rules I offer paid licenses. The license money funds further Luxor development and docs. I also plan to hand out cash to contributors (so that noone feels ripped off). > thus barring my > opportunity to build a proprietary application upon > this framework. You can build a proprietary app on Luxor as long as you follow the GPL rules. - Gerald |
From: Daniel K. <dk...@kc...> - 2002-08-26 23:18:27
|
I am very interested in getting involved in the work with this project. In a way it frustrates me...I think that for once I spawn an original idea just to learn that someone else is already exploring it. :) What I am looking to put together is a general application framework that is fully configurable via XML. This general application can then load plug-in modules (each customized via XML and scripting) to add the business functionality. I would like this framework to support customizable rendering and scripting engines, component services, etc. In a sense, I would like to bring a component-hosting environment to the desktop similar to how J2EE has brought a component-hosting environment to the server. I have tracked down many news threads regarding this project and have some concerns regarding it. The first concern is that their is only one developer listed on the sourceforge site. I don't believe that this is a one-man show; however, it concerns me that I can only view the source on-line...i.e. I cannot access the source, run builds against it, view test suites, etc. If others are developing this framework, where is this code submitted to and why is the source for these new submissions -- Modul-mania. New modules include: Apollo, Caramel, Houston, Rachel, and Salsa o Apollo - Test Skeleton for Web Start/JNLP o Caramel - Java Extensions (non-GUI only) o Houston - Yet Another Status and Logging Toolkit o Rachel - Resource Loading (includes HTTP web service) o Salsa - Swing GUI Add-Ons not viewable or accessible except in binary format (JAR files)? I would like to become a contributor, however this project "smells" like a proprietary project under the guise of "OpenSource". If I am wrong I sincerely apologies -- I am not out to flame anyone -- I just want to be given a fair chance to contribute my piece...without fear of having it taken away by someone "dual" licensing my contributions; thus barring my opportunity to build a proprietary application upon this framework. |
From: Gerald B. <ge...@va...> - 2002-07-19 18:08:24
|
Servus Waldemar, > sorry for my bad english Nothing to be sorry about. > Which JDK version is used to build Luxor. I tried to > use jdk 1.2.2, > but there are a couple of problems with swing. Luxor requires Java 1.4. > Is there a list of libraries needed by the core > luxor library? I packed all libraries into the ramses distro. To see what libraries you need, check out the Luxor ant buildfile, especially the classpath element in the compile target. > Where do I contribute my source changes and how? The first step is to sign-up for the luxor-xul-develop mailing list. You have already done it. Welcome to the show. If you want to contribute source code, please post them here. Cut and paste them into your email. Please, don't use any styled text (e.g. HTML) or so on, just plain-vanilla text. Separate your multiple files using =============================================== or a similar device. For bigger contributions I will setup another mailing list where you can send your contribution bundled up in a zip archive. > Is there something like an architectureal overview > on the luxor > pachages? Check out my talk series: * The "Linux Kernel" for Desktop Apps - Uniting XUL, SVG, HTML, Velocity, Web Start, XSL/T, Python and more at http://luxor-xul.sourceforge.net/talk/vanx-jul-2002/slides.html * Luxor: Beyond Swing and HTML: Building Rich, Cross-Platform, Zero-Admin Desktop Apps on Open Standards Today online at http://luxor-xul.sourceforge.net/talk/jug-oct-2001/slides.html More to come in the future. > Final question before lunch: > Luxor is a library, right? Can I use this library in > a commercial > application without affecting the licence of the > commercal > application? Luxor is released under the GPL. You can use it for commercial applications for free (zero-euro) as long as you follow the GPL rules (explained in plain-English in the license itself). See http://luxor-xul.sourceforge.net/license.html for details. Enjoy your lunch. - Gerald |