Re: [xul-talk] Comments on MSXAML story by CSS Zen Garden creator
Gerald Bauer wrote: Joe Marini comments: 1. XAML is not just a XUL ripoff. XUL is entirely about presentation structure. No, it's an abstract UI language. Though it's not entirely divorced from the presentation, most of the actual presentation is defined in CSS. XUL also has templates, data sources (RDF) and other UI-related features that are NOT presentational in nature. Yes, XAML contains presentation information, but it goes WAY beyond that and provides a way of specifying not just physical appearance but interactive behavior and abstract object instantiation. It goes a long way toward declarative programming, and provides some very nifty ways of making sure the two stay separate. In fact, Ive built entire examples of XAML-only functionality that would require a lot of script programming in the past (you can see them on my site). 2. Microsoft is not ignoring standards like CSS and SVG. CSS was in fact deeply investigated, and doesnt have the necessary power or extensibility to accomplish what you can do in XAML. (Please note that questions asked below are not necessarily rhetorical.) This leads me to the following questions: 1) If Microsoft is going to use custom presentational attributes for specific elements anyways, why not combine that with CSS support? XUL has both custom presentational attributes and attributes that overlap CSS, while CSS supports presentation that isn't possible with XUL alone. (I get the distinct feeling this is because the styling in XAML is not entirely presentational. I think MS wants a general styling model that includes behavior, et cetera.) 2) Is there a reason Microsoft can't just extend XSL for style sheets? 3) How do you separate the programmer from the graphics designer? It seems to me that in the Microsoft model the graphics designer is doubling as the UI developer, while the programmer is forced to write to whatever interface the graphics designer wishes to provide. The only way for the programmer to add buttons or change the interface at a high level is to temporarily assume the authority of the graphics designer. What does MS provide that allows one person to develop the high level markup and code (example: JS+HTML), while another develops the presentational aspects of the UI (CSS+XBL)? On a side note, I've seen many comments to the effect of the weakness of CSS properties is that you never know which one applies to an element. Why would you want a presentational styling system that requires you to memorize a tree of properties that expands with every element you add to the markup language, rather than a flat list of properties? Heck, the property name for the same presentational effect could differ between two elements. Do XAML developers even have a flat list of basic presentational properties they have to support for each element? Does XAML even allow the styling of an unknown element??? Neither does SVG, which was built and pushed by its creators primarily to be an animation engine. Thats not XAMLs primary mission. This doesn't really explain why they can't design XAML to use SVG for vector graphics. What's the problem with using compound documents (XAML+SVG)? 3. XAML is not MS just making another IE-proprietary language to shut out other browsers. Many of you may find this hard to believe, but the ratio of intranet applications to internet apps is somewhere around 10 to 1. Companies would never use mixed systems? Mac, Windows and Linux can't exist inside the same company? Intranets can't ever be accessed from an employee's home machine? Intranets don't use internal apps based on web technologies? For scenarios where you can control the runtime environment, web delivery of Avalon apps makes a lot of sense. Only if Avalon can be easily and consistently deployed on ALL the systems using the apps in question. One thing that bugs me about XAML is how it encourages mixing styling with content. For instance, watch the following streaming video: http://www.microsoft.com/winme/0504/24295/avalon_interview_and_demo_MBR.asx This video makes it clear that Microsoft has no concept of alternative or user-defined stylesheets. It's very similar to their attitudes toward skins. They think programmers should determine the presentation of the interface rather than users. They actually joke about having an Export to XAML option in MS Paint. Once again, Microsoft shows that they'd rather empower the developer than the user. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ xul-talk mailing list xul-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] XUL or not XUL
Arron Ferguson wrote: XUL is a technology, not a brand name. It's both. Companies trademark the names of their technologies all the time. XUI is a technology (the same type of technology as a XUL) not a brand name. I'm not sure the software vendor Xoetrope, who lists XUI as one of its products, would agree with you. Gerald is right in calling it XUL. Mozilla cannot claim XUL as a brand name since it is an acronym that represents a technology, not a brand name. Mozilla originated the term, they claim it as a copyright, and members of the Mozilla Foundation have attempted to discourage its use as a generic term. What else can they do other than haul people into court? --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ xul-talk mailing list xul-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] XUL TEXTBOX ELEMENT: VALUE PROPERTY UPDATE PROBLEM
Karthik wrote:
I have a problem with the textbox element in XUL unable to set new values to
its VALUE property as it changes (As I call the onchange event)
Here's my code snippet in XUL File
hbox
label value=LABEL/
textbox id=txtBoxLabel onchange=setTheNewValues()/
/hbox
hbox
button label=NEW TEST onclick=setElemProps()
This line should be the following:
| button id=button1 label=NEW TEST onclick=setElemProps()/
/hbox
function setTheNewValues()
{
tempNewValue =
document.getElementById(txtBoxLabel).getAttribute(value);
Change line this to:
| tempNewValue = document.getElementById(txtBoxLabel).value;
alert(tempNewValue);
document.getElementById(button1).setAttribute(label,tempNewValue);
}
The problem is the VALUE property in TEXTBOX stays the same and does not
change. Is there any refresh knid of mechanism where the moment I change
the VALUE in TEXTBOX, the LABEL in BUTTON(button1) changes.
Yeah, for some reason the property value doesn't match the
attribute. I think this is because you use |value| in the markup to set
the initial contents of the textbox, so the attribute has to stay the
same in order for you to obtain the initial value once the contents of
the textbox have changed. Use the property instead, as shown in the
code I gave you above.
Please Help me in this matter as its critical for a project.
Let me know if you have any further problems with this.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] Poll Update: What do you plan to use XAML for?
Gerald Bauer wrote: Just to let you know that the XAML Developers Group poll asking What do you plan to use XAML for? [Snip!] Here's the standing as of October, 28th: o To create windows forms 5 votes (27.78%) o To create animation 3 votes (16.67%) o To create web forms/web pages 3 vote (16.67%) o To create technical diagrams 2 vote (11.11%) o To create still images 2 vote (11.11%) o To create print documents 2 vote (11.11%) o Other 1 vote (5.56%) I don't mean to offend, but the voter sample you have here just isn't statistically significant. You can't expect solid information from a poll with only 18 people voting. One could poll their friends and family in the course of a single day and get that many voters. Is there a way we can get more meaningful poll results? --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] Is WAML the new XUL/XAML?
Gerald Bauer wrote:
It is much a 'XUIL' as XHTML. More so, in fact, by
design.
I don't really understand the term 'XUIL', though,
it's a bit like 'UUIL' ('Unicode User Interface
Language') or 'UILUET' ('User Interface Language Using
English Tags') -- highlighting one minor aspect of the
language to the exclusion of others.
[Quotation above added.]
[Snip.]
Hear. Hear. Wasn't Mr. Ian Hixie Hickson the
leading advocate for using the XUIL acronym here on
xul-talk?
I think it would be a bit more accurate to say he was an advocate of
NOT using XUL as a generic term. He probably doesn't remember actually
suggesting the acronym XUIL.
Is WAML the new XUIL?
I don't understand the question, especially regarding the, since
it is clear that no one was suggesting using the acronym WAML to
replace XUIL.
As for whether WAML is A new XUIL, Ian clearly stated in the same
email you quoted from that WAML will simply be part of the next version
of HTML. The idea is that HTML itself will become more like a basic XUIL.
A good question is whether giving HTML more XUIL-like features makes
HTML an XUIL in itself. If that's the case, HTML widget programs like
Apple's Dashboard may become the dominant web applications platforms.
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] XUL/XUI/XUIL/XML-UI - It's Your Choice
Gerald Bauer wrote: Just to let you know I invite you to use whatever acronym you feel most comfortable with on xul-talk. Be it XUL, XUI, XUIL, XML-UI, XPML, XAML, UIML, UML, WML etc. It's your choice and I ask everyone to respect it. XUL - Many already claim that this is a trademark of Mozilla. Since XUL is the only name for Mozilla's XML user interface language, there can be little doubt that the use of this term would cause confusion within the Mozilla community, whether Mozilla actually claims it as a trademark or not. XUI - Don't know too much about this one, but if several groups are fighting over who has a copyright to it, it should probably be avoided. Apparently, XUI also stands for X User Interface (as in X Windows). XUIL - This term is probably the least problematic. It's the only acronym I know of created to _specifically_ be used as a generic term. VXF uses this term on their website: http://vxf.sourceforge.net XML-UI - This has possibilities, but could be confused for a method of displaying XML rather than an XML language for user interfaces. XPML - Please, I'm was confused enough by XPCOM. A random individual looks at this, and for all they know it means Xeroderma Pigmentosum Medical Lasing. XAML - Not only is this the name specifically for Microsoft's XML user interface language, but it also used to stand for Transaction Authority Markup Language. See this URL: http://www.xml.com/pub/r/811 UIML - This doesn't really communicate that it's XML-based. In theory, this term could be describing a broader group of markup languages. That could be good or bad depending on how you look at it. UML - Stands for Unified Modeling Language. It's a frequent term in business environments with large corporate databases. Don't touch this one with a ten foot pole. If I were to rate these in order: XUIL, XML-UI, UIML, XUI, XPML. I dropped XUL, XAML and UML, because each is used to identify a single, specific technology. We may wish to avoid XUI as well until those claiming it come to an agreement on its use. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] XUL/XUI/XUIL/XML-UI - It's Your Choice
Laurent Jouanneau wrote: Mozilla.org claims that XUL IS a trademark : http://www.mozilla.org/foundation/licensing.html In that case, use of XUL as a generic term is clearly a violation of trademark. And i confirm : the use of XUL term for other technologies than Mozilla's XML user interface language, cause confusion for newbies who discover http://xul.sourceforge.net site... Some xulfr.org users wrote it to me by email... Yeah, when I was developing my XUL Basic suggestion for the WHAT WG mailing list, I personally had a hard time finding info on software that supported subsets of XUL because of its misuse. It was rather irritating. Well, why don't we use XML-UIL ? ;-) Great! We could call it XUIL for short! ;) How about Extensible Markup Application Interface Language? --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] XUL/XUI/XUIL/XML-UI - It's Your Choice
Pike wrote: because the L is doubled. in full, that reads Extensible Markup Language User Interface Language Even with XUIL, the L(anguage) is already in the X (of XML) If you view XUIL as XML-based User Interface Language, then I don't see what the issue is. what were gerald bauer's hesitations on the name XUI ? XUI is used genericallly by the Purnama Project, but there is a Source Forge project called XUI that does not use the term generically. Also, XUI is a product produced by the JWay Group. It appears to be come kind of server-side XUIL that gets translated into XHTML/CSS using XSLT. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] The Future of the Web - HTML 4, HTML 4.3, (X)HTML 5?
Gerald Bauer wrote: [Snip!] The viewpoints expressed on the first day seemed to fall into four categories: 1) This is a non-issue. The Web as it stands is more than adequate to the task of delivering applications. A few presenters emphasized that it is possible to create sophisticated applications, even interactive games, with today's browsers running DHTML. 2) With XHTML, XForms and SVG, and a way of combining these languages, the problem can be solved. This is what's meant by compound documents -- can a browsing environment (or multiple environment profiles) be created in which these existing languages are harmonized to enable rich interactivity in a rationalized, standrardized manner? This approach was advocated by Adobe and others, and ultimately won the group's approval. 3) A few discrete extensions to DHTML will solve the problem. This was advocated by representatives of Mozilla and Opera, who later formed a working group called WHAT-WG to specify these add-ons. 4) We need a new unifying language/spec, which may subsume other W3C specs, for building Web applications. This position was advocated by Sun, and OpenWave. It is also the path being taken by Laszlo, along with most rich Internet companies, and to some extent by Microsoft, though they were at pains to position XAML as a way to write Windows apps, not Web apps. [Snip!] What position do you you favor? Let us know. I guess my ideal would be a mix of the following: * XHTML1.1 + Web Forms 2.0 + Web Apps 1.0 + Web Controls 1.0. * CSS 3.0. * Javascript 2.0 * sXBL (or XBL 2.0, whatever they want to call it). * SVG 1.0. * Perhaps XForms, XPath, et cetera. * A W3C XUIL standard based on XUL. By basing in on XHTML, you create a migration path for existing web apps. There's already a profile for using SVG inside XHTML, and it could be included as an image file for backgrounds and such using CSS. I'd love to use CSS+XBL2+JS2+SVG+XUL2 to create widgets so powerful, you'd think they were natively coded. Plus, if you're using alternative stylesheets, the user can change the entire UI layout and functionality. Really powerful stuff. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] Michael Gloegls (of Team Hibernate) on XUL
There are several reasons why (X)HTML/XUL is superior to Java for customization of a GUI: 1) You can easily and dynamically generate HTML and XML-based languages from a database on a web server. In fact, the server can even dynamically generate pages for specific languages. The client side need never even worry about such details. In fact, the code doesn't even need to change, because you can import the Javascript code from a separate file. While the same dynamic content is possible in Java with a little work, the tools for HTML and XML-based markup are more evolved and there are more people trained to use them. 2) As Ian pointed out, XHTML/XUL can use CSS to generate any look the client wants. This is especially powerful when combined with post-DOM binding technologies like XBL. 3) Although XUL (and to some degree, XHTML) describes UI elements, it does so at a fairly high level. The last two are important, because you don't want to have to worry about the style of the UI every time you add or remove a UI element. Styling technologies such as CSS should handle presentation of higher level elements, not the application code. Granted, there are specific cases where you want fine control of presentation in the application code, but in that case why are you writing an Adobe Illustrator clone in Java? As for MS XAML, I don't think it will catch on as quickly as some people think. If you're coming from an HTML web applications background, you effectively have to completely retrain and retool your development staff to use it, and it's going to be really hard to justify that kind of investment until the release of Longhorn. In the meantime, browser developers will continue to enhance HTML, and XUL will gain in support an popularity. All Mozilla needs to become a complete web applications solution is the completion of SVG support and perhaps a better scripting language. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
Re: [xul-talk] Re: Michael Gloegls (of Team Hibernate) on XUL
Michael Gloegl wrote: I just wanted to refute the argument that just because something is in XML it is not necessarily easier to handle - especially not regarding the multiple paralell versions problem. I fail to see how you've succeeded in that regard. If you're still not convinced why not try to recreate lets say the Amazon.com frontpage using Java Swing online @ http://www.amazon.com for some more insight? Or why do you think is Sun's frontpage @ http://www.sun.com not a full-page Java applet? Well, has anybody done that with XUL yet? No, because HTML+CSS+Javascript is more than capable of handling it, and because XUL isn't supported in IE. That doesn't mean it would be any easier to support in Java, or that it would be any easier with the Java-like Microsoft VM. (Hint! Hint!) I really don't know. I have not much XUL experience, which I freely admit. But I suspect (like it always is) that easier usage comes with reduced flexibility, not just because one is Java and the other XML. Of course. You can always invent some strange widget that would be hard to implement in XUL. However, if 99.9% of your GUI it made up of common UI widgets, flexibility isn't an issue. Furthermore, once you develop the XUL needed for a specific widget, you can use XBL to bind it to an element, thus making the XUL code reusable. Since the XBL file you use is part of the style sheet, you can use a different XBL file for every alternative style sheet. This makes choosing the GUI customization of your choice as easy as clicking View-Use Style-[Style Name] in your browser menu (assuming your browser supports multiple style sheets). So I'd be really interested to see an Application using things like heavily customized JLists or JTrees, or one of the other Components that make Swing so complex. I doubt it would be much easier or understandable than the equivalent Swing code. I'm not familiar with JLists or JTrees, but it would appear that this is an issue of the level of customizability, which is not the same as managing customizations. Do you see why Java is irrelevant and why a REST-style XML format beats an API anytime? If you wouldn't hand out such extreme and IMHO untrue comments, probably XUL would gain more acceptance. I agree. What I think he means, though, is that technologies like XUL and Web Forms 2.0 may result in a decline in the use of Java for web applications. Whether Java is better suited for the development of a specific kind of web app depends on the application in question. In reality, I suspect we'll see a lot of Java serverlets with some kind of XUIL on the client side. This is especially true for businesses that want to keep their data algorithms a secret. Besides, most people and businesses don't need a heavy level of customization. Giving people more options than they need can be a distraction from the task at hand. For proof, just look at the last two Star Wars movies. ;) This is one of the reasons I don't think XAML will do well as a language for web apps. There's so much you can do with XAML, and yet there's so little separation between the semantics and the presentation. Everything I've seen of MS XAML so far has convinced me that it's designed to create a single detailed GUI rather than a high level layout that is fleshed out using style sheets. Microsoft just doesn't get the whole concept of themes and skins. The want a GUI to be totally under the control of the programmer. By contrast, things like themes and alternative style sheets put more and more power in hands of users to control appearance and layout. Meanwhile, how do technologies like XAML improve the lives of users aside from providing some nice eyecandy? Better to use a simpler, easily skinnable XUIL like XUL, which would be easy to implement on top of Avalon. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
