Coder “t3rmin4t0r” seems to have ported MyXAML to Linux. Here is a screenshot of the default WinForms powered MyXAML calculator demonstration, and here is the same demonstration running under DotGNU’s work-in-progress Qt-powered WinForms backend.
MyXAML Ported on DotGNU
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
57 Comments
2004-05-01 2:23 am
Anonymous
Why aren’t they using XUL? That’s what you gotta ask yourself, man.
Shapeshifter since you like the word dig too much (#4) 
i say that you and foljs dig previous posts, theres historical reasons for why XUL isnt so accepted nowadays. And i mention some, apple choice for safari, mozilla fork and netscape end.
Mozilla foundation has only what 10 months?! whats missing? lobbying, money, visibillity,…
And I agree with Anil about the sandbox and what roadmap mozillafoundation should take.
Someone mentioned a comparison of books, something about how many they found at Amazon.com for XAML and XUL.
About the books, i didnt came up with that out from my ass, it was to answer foljs sugestion that xaml is/would be something bigger since it had more apps/books released. About oeone its profit driven, i had use the trial version long time ago, i must thank rycamor for recalling that.
And here are some well known mozilla firefox extensions http://www.texturizer.net/firefox/extensions/ for the ones that say theres few things available. Yes some are simple, yes many use simples things like css, xslts javascript..
but my point here is, and what i said before, multiplataform. Since a real cool aspect of this xul thing is that you can run it almost everywhere you can run mozilla.
The same way i use it here in linux, or at home in freebsd, my cousin in windows, or my girlfriend in macosx at work.
Many of this extensions are simple, yes, but many are built and made of UIs with dialogs for openfiles, print and wathsoever for the guest OS.
Something that xaml will not provide to others plataforms beside windows, and others project will need to feature a layer or hack to accomplish the same core code but on or with different xml UIs widgets.
And this “trying to keep up with Microsoft technology” and use glue to make it run, is what seems wrong for the oss. Its easy for microsoft, since its the one running the show, to put legal constraints. Or evil ones by not documenting features or just making standards of some, on the intereset of stoping further development and wider acceptance. Same happened to wine/samba projects as already said before.
so Icaza’s fears now can slowly go down. ONce this porting is complete, XAML can no longer be a great threat to other envs. But are there licensing issues with this porting? can M$ can sue them in future or demand royalty from them ???????
…in the aspect that Eugenia posted the article I submitted (#SO) and the fact that this seems to open up a realm of possibilities, given that MyXAML can be “wired” to GTK#, wx.NET, etc…
Its also probably a little less sweat off of Migeul’s brow now that MyXaml is running on Linux – hey, man, now all you have to do is work on tying it into a graphics system. Peace of cake, right, man? ;p
IIRC, MyXAML is not 100% compartible with XAML… at least that’s what I read some time ago on the MyXAML webpage.
yep, you read that right. MyXAML is NOT XAML…
From the MyXAML FAQ:
“Can I Use Third Party Controls ?
Absolutely. Map the assembly in your markup, assign a namespace prefix, and you can instantiate any class, initialize properties, and wire up events.”
Read as: It is not necessarily compataible now, but if you can use third party controls, one would assume that includes things in the Avalon namespace – so while that means the .xaml produced by MyXaml would not necessarily to compatiable with Microsoft’s XAML, nothing stops you from “wiring” MyXaml up to to the MSAvalon namespaces and essentially having the very same thing, with only minor differences in syntax.
Then again: its an open-source project. You could make it compatiable if you really wanted with a few tweaks, but Longhorn isn’t here yet, so why bother right now?
There are definitely some patents entangling a lot of this .NET stuff (I’m including XAML in the bunch for simplicity). It seems IBM is developing more of a relationship with Novell (because of SuSE) so it would be interesting to see what would happen if Microsoft took aim at Novell (because of Mono). Would IBM help out any? They kind of need Novell to push Linux in the enterprise.
Keep in mind, though, IBM has a lot of business riding on Java (read, J2EE). From what I have heard, IBM has a large patent portfolio of its own. And IBM is probably one of the few companies that has enough money to withstand the litigation games of Microsoft.
Exciting times ahead.
Amazing work, especially so fast!
Sorry did not knew that. Then what does this development means to Open Source/Linux/GNU community. Can it lead to atleast some XAML stuff to run under linux ????/
i don’t get it, why are some people in the NIX world scared of longhorn? XAML is no different to me than any other Windows software. I seriously doubt my dad would write a killer app in XAML and for me to find a reason to install or even have the desire to run longhorn to run XAML apps.
Like today…I wish I could run Photoshop…or Office…not on a emulator like vmware nor some second grade app like gimp or openoffice (not a troll)…let’s face it openoffice does not par up to office 2003, at least feature wise.
I believe microsoft won a patent regarding the use of scripting embedded within XML…and I think XAML was one of the soul purpose for it…so yea of course Microsoft is going to raise hell.
But hey I like the idea….write GUI in XML…and program the logic in C#.
unified devel platform for everything under the sun.
i’d like to ask everyone to actually write an app which actually uses XML before they start saying XML is a good idea for gui’s. parsing xml just sucks.
so Icaza’s fears now can slowly go down.
Because DotGNU (which is not Mono) supports MyXaml and Mono doesn’t ?.
This is the result of nearly 1 year of Windows.Forms development on DotGNU … (of course it took me just around 7 hours to get it working).
Btw, I work from India … which is outside US Patent laws (and we don’t have e-patents yet !!)
This is some really nice stuff. I never expected this to work so soon! It’s a good thing the t3rmin4t0r is on our side!!
sorry, but i’m not very inside the subject of XAML/Longhorn. But for what I’ve read here, how is XAML different from building and application using libglade?
I mean, the interface is in a XML file, and can be loaded at runtime from that file. We can even change it without need for recompiling the app.
similiar?
In what way does OpenOffice.org not compare to MS Office 2003, then? It’s not like there’s a *huge* difference between the two. I agree that the toolbars are not as kiddy looking as in MS Office 2003, but I can *really* live with that! No seriously, how does MS Office 2003 work with autocompletion, and what about the stylist? I think those are two killer features of OpenOffice.org.
But the way I see it now, is that you’d rather find a way to use MS Office 2003 on Linux, rather than to help an alternative to get ‘on par’. I think you’re just stubborn.
I agree with you on The GIMP though. It isn’t anywhere close to Photoshop.
…more patent talk eh – so is there ACTUALLY a patent on XAML or is this just more loose talk?
XAML looks up Members with Reflection … so You can easily plug your controls into it … Try that with glade (or *if* you can write your own control in gtk, then try that).
Most people in .NET use customcontrols … For example all DotGNU’s controls are owner drawn and do not depend on any native toolkit controls . So it’d run anywhere from a mobile phone running on a custom windowing system (think symbian) or a Zaurus with FrameBuffer drivers — provided someone sits down and ports the Graphics object to draw lines and fill rectangles.
Even the MDI is based on custom drawing (ok, it looks kinda ugly when a windows titlebar appears for a MDI form when the rest is all in bluecurve, but the Qt themer will fix that)
“Most people in .NET use customcontrols … For example all DotGNU’s controls are owner drawn and do not depend on any native toolkit controls . So it’d run anywhere from a mobile phone running on a custom windowing system (think symbian) or a Zaurus with FrameBuffer drivers — provided someone sits down and ports the Graphics object to draw lines and fill rectangles.”
Take a look at evas, wich is basically capable of doing your low level drawing and amazingly on a lot of different systems (read: x, fb, … )
XAML, as described by Microsoft, doesn’t use reflection, it uses partial classes.
It doesn’t load the XML file at runtime to create the GUI, instead you have to compile the XAML into a .Net assembly.
You can create GUIs by loading XAML files but you cannot attach event handlers to them unless you compile the XAML along with the code-behind first.
MyXAML and similar use reflection as partial classes are not available until Whidbey.
Partial classes and runtime compilation will be a huge hit on performance. We’re reducing desktop applications to the level of ASP.NET and similar runtime compiled to IL languages.
Hmm… Partial classes are going to be one PITA to JIT properly
. Almost reminds of strongalias/weakalias things.
But the point is that DotGNU’s advanced enough in Windows.Forms to just plug in and run such things.
excellent blog. He even provides a visual designer [extra beta at the moment as he says]
http://www.myxaml.com/marcclifton/
it will/can support msXAML namespace in the future.
Now we’re talking about SWF & WEBUI
I still do not understand what is so great about XML described UIs. There are obvious links related to Web Browsers but for “real” apps, describing UI as an XML file doesn’t make it more flexible than a dynamic language loading packages for UIs. What is so amazingly great about XML ?
XML guys seems to discovers concepts that have slept for 20 years since the invention of Smalltalk.
One day, Microsoft guys will tout the new invention of Exploratory Programming allowing to tune the UI and the whole program dynamically and FOSS hackers will readily try to clone Microsoft… Why doesn’t people see where we are going ?
i’ve been modded down once for saying that De Icaza should code instead of keep talking like a businessman, and now, someone that did what i suggested has been successful in creating something close to the target of Miguel…
see what i mean?
seems nice, but I’m going to try out XUL also if I get a chance. I would prefer XUL instead of XAML, certainly since it is cross platform and open I think.
The precisse words of icaza on netcraft regarding xaml were,
A lot of people today cannot migrate to Linux or cannot migrate to Mozilla because a lot of their internal Web sites happen to use IE extensions. Now imagine a world where you can only use XAML.
It’s massive – I’m so scared.
I really, too dont understand this drill about xaml when we have long dated xul. Xaml doesnt even exists, and just see how many mozilla extensions in xul are, and all multiplataform.
Dont take this as flame comment, congrats for the myxaml author, and this dotgnu “hacker” to port it, or atleast make it run, with dotgnu framework and qt.
Miguel’s fear is not because `Mono does not support Winforms and DotGnu does’. Which is incorrect, Mono *does* support Winforms just fine, MyXaml included.
The problem with Xaml is not the markup language, that is a
triviality. The problem is not Avalon, which is a lot of
extra work (a completely new toolkit, which is completely
new: not compatible in any way or form to the work that
you or us have been doing in Windows.Forms).
The danger of Xaml/Avalon/Longhorn is that it creates a new
deployment model for rich applications. Xaml per se, is
useless.
Read Miguel’s post on the subject.
I really, too dont understand this drill about xaml when we have long dated xul. Xaml doesnt even exists, and just see how many mozilla extensions in xul are, and all multiplataform.
The fear is all about getting Linux on the desktop – first the corporate desktop then the consumer one. Currently open source has better browsers than IE (Gecko and KHTML based). Effectively Mozilla has taken back the web.
If after the Launch of Longhorn there is widespread adoption of XAML to produce rich web content that displays in native widget sets, then once again Open Source browsers and operating systems could find themselves locked out of much web content again.
Unless open source cross platform browsers can handle XAML for Winforms then OSS is locked out and MS moves towards its objective of a closed MS “owned” web. No matter how good or equivalent XUL is, unless it becomes the predominant way of delivering this sort of rich content before the launch of Longhorn, then MS will be able to use its predominance as a desktop client to force the use of XAML.
If this happens then effectively cloning XAML becomes vital. t3rmin4t0r has shown that this is possible. The next question is can MS stop this by using patents ? Maybe but there are to factors holding them back here:
First.. The fear of renewed anti-trust actions.
Second.. The embedded XML patent and probably others can be broken. The prior art of XUL for a start – the question is would someone put up the several millions dallars required to break tha patent (Novell, IBM ?)
The fear of Longhorn/.NET/Avalon/XAML seems to be a great spur to FLOSS innovation.
Good lord. If Microsoft can patent XAML or the concept of embedded scripting in XML (I mean, what’s the CDATA tag for, after all???) then I’m going to become a sanitation engineer.
Marc
It’s just a way to instanciate objects by declaring them through an XML syntax.
The problem is Avalon, which XAML apps will use for their presentation.
I really, too dont understand this drill about xaml when we have long dated xul.
XUL is a toolkit that all three people use, in a browser that all three people use (Mozilla, Firefox). I’m using Firefox to type this, now, but please understand: Firefox/Mozilla and XUL are insignificant from usage percentage perspective.
Also: XUL is only a GUI binding API with probable embedded functions etc. XAML is INTEGRATED with a whole lot of framework and EXCELLENT documentation already exists, with more to be written. XUL could eventually be integrated with something. But this “eventually” will be even more in the future that the arrival of Longhorn in two years.
Just because several things exist in various diconnected states, don’t mean you can (or should) overestimate the power of Open Source to deliver on them. For example, GTK+ still lacks a decent complete documentation after 6 years (check the site). My bet: even when Longhorn ships, GTK+ will still lack documentation. Now, if something THIS basic cannot be catered, what makes you think other things will be in top form?
Xaml doesnt even exists, and just see how many mozilla extensions in xul are, and all multiplataform.
Even though XUL already exists for several years there are FAR MORE people using XAML TODAY (programmers and companies learning Whidbey programming in their longhorn betas) that people that use XUL. There are even more books about XAML.
Also, as Longhorn comes nearer, this will be there for 90% of the people. And the programmers and books will get sky high.
Most of the existing Mozilla extensions, btw, are very simple, some are jokes, and there are no more that 100 programmers that do them.
Miguel’s fear is not because `Mono does not support Winforms and DotGnu does’. Which is incorrect, Mono *does* support Winforms just fine, MyXaml included.
I’ve read the http://www.go-mono.com/mono-roadmap.html . It clearly mentions that Windows.Forms is not being developed by Novell/Ximian . That implementation is a wrapper over wine, which does not work unless you compile mono to run as a wine application which destroys any advantages a JIT has.
Have a look at http://lists.ximian.com/archives/public/mono-winforms-list/2004-Apr…
and compare it to DotGNU . Can you honestly say that Mono “supports” winforms ?. Compare that to http://pnet.homelinux.org/screenShots.htm ?. Or have a look at Portable.Studio at http://216.58.40.193/ide2.png .
For sheer radicalness , have a look at http://dotgnu.org/screenshot12.html which runs Gedit and KCalc inside a single Form !. Or running Windows.Forms on an XBOX or maybe an IPaq ? . libICE support, DCOP … you name it, we’re on.
Or whidbey features like System.IO.Ports (yes, I can dial out to my network provider with that) and Console handling implemented in DotGNU (http://dotgnu.org/screenshot13.html)
DotGNU’s Windows.Forms does run with Mono’s just like Mono’s ADO.NET runs on DotGNU .. We’ve made sure of that (both from our end, purely to avoid duplication of effort). DotGNU is the underdog here, I admit .. But that just drives some of us harder each day .
Btw, have a look at XWT … http://www.xwt.org/ for a fully functional XML based application deployment system.
Their motto is
You don’t “install” web pages; you simply visit them.
Why should applications be any different?
Which is what XAML+Avalon is going to do … only with Hardware acceleration on Avalon
The reason this stuff keeps getting reinvented is that it is useful, but mainstream languages aren’t expressive enough to support it properly. That’s why you have hacky stuff like XAML instead of just biting the bullet and realizing that you need a language that can simultanously describe both code and data easily. Let me give you a small example in Dylan:
horizontally()
make(*button*, label: “Hello”);
make(*button*, label: “Goodbye”);
end;
That’s how (when you replace ** with angle brackets, anyway) you lay out buttons horizontally. You don’t have to go to the trouble of actually making the horizontal layout container, the macro does it for you. Need GUIs to be editable on the fly and loadble at runtime? Just put the layout in a seperate file and depend on the runtime compiler to compile it for you (Smalltalk, Python, and a number of other languages can do this). The cool thing about using an expressive language rather than a hack is that when your complexity increases, things scale sanely, instead of suddenly getting much more complex because you need to embed C# in XML!
i still put my faith here
http://sourceforge.net/projects/xul
http://mail.gnome.org/archives/foundation-list/2004-April/msg00008….
whats missing? lobbying, money, visibillity, and yes probably apple choose for konqueror team, was a blown and a counterback for a wider acceptence of mozilla, and probably the fork and all the probs mozilla got wouldnt happen, but i think the mozilla foundation is keen to push up this to up front.
The best way to avoid all sort of microsoft fears, patents, code lawsuits isnt by the emulation or trying to make it equal, Samba is a sucess, wine/x are either but at what cost? and do they really represent what we want the oss to be? Who uses wine apis to develop crossplataform code? Dotgnu is talking about wine integration to solve libs deps, mono hasnt its windows.forms class complete, and to avoid lawsuits many things need to be re-built differently.
I dont see avalon xaml as a treat, if we can came with something good, but not at expense of a replica. Because it will not always be the same.
For anything except the most trivial applications people will most likely be doing something like ‘code-behind’ in the xml. So that the programmer can say to the gui designer here’s the event names that I need you to put in the xml and then the gui designer never even sees the C# code.
Who uses wine apis to develop crossplataform code? Dotgnu is talking about wine integration to solve libs deps, mono hasnt its windows.forms class complete, and to avoid lawsuits many things need to be re-built differently.
You’re confused. It’s mono that is using wine as a SWF dependency, not dotGNU. dotGNU’s SWF implementation uses X as it’s backend on Unix and gdi on windows. The reason that Mono chose to have wine as a dependency for their implementation of SWF is to handle the pinvoke problem. They want windows SWF program to just work out of the box on Mono. dotGNU will not be able to handle a program that uses a native windows call.
People don’t use Wine APIs to develop cross-platform. They use windows apis and hope it just works on windows.
Dotgnu is talking about wine integration to solve libs deps
What ?… DotGNU is completely drawn lightweight .. Mono has it based on Wine.
You can’t imagine the heartburn we went through to implement and optimize the TextControl, TreeView, Tab and Scrollable with double buffering (Xdbe)
Not to mention FileDialog or PrintDialog (Button and label are the only easy ones) Now there’s RTFBox still left to hack on.
Or Lightweight MDI components . Swing MDI sucks in comparison to http://pnet.homelinux.org/images/MDI.jpg .
Please, note , we do not use Wine and we run on other platforms than x86 , especially arm . (and a working IA-64 native code unroller !!)
The pinvoke problem is quite important and a purely native SWF implementation just doesn’t cut it unless your goal is to allow developpers to use the less than stellar SWF to build completely new applications. I’d rather use GTK#, at least it’s a clean and potent API.
I fully agree with you Raynier. Why does open sources celebrities ( like Havoc, Icaza, … ) focus on cloning Microsoft’s feats instead of more radical architectures.
IMHO, the futures of GUI-rich software lies more in Smalltalk, Self, NewtonScript ( I don’t know Dylan ) and smart script languages than in XML tweaks.
HTML ( and related works, like Javascript, CSS, … ) has shown that XML style documents can be used for everything. It doesn’t mean that it is always an efficient solution.
In what way does OpenOffice.org not compare to MS Office 2003, then?
I’m no fan of Office by any means (or of office suites in general), but the two things that keep me using Office over OpenOffice are:
1) Keyboard shortcuts. Things like Ctrl-shift-f for the font picklist are reflex by now. Sure, I suspect OOo has its own equivalent – and hopefully a way to re-map keyboard shortcuts – but it doesn’t really offer anything over Office enticing enough for me to go through the effort of re-learning hotkeys.
2) Memory use. I’m stuck on a Duron 1.2 with 256MB RAM at work and I regularly use big mem-sucking adobe apps like PS and Illustrator. In that situation, given the choice between loading a spreadsheet in Excel, which will take up about 15MB RAM, and loading it in OOo, which will take up about 60MB RAM, guess which one I’ll go with?
foljs,
Even though XUL already exists for several years there are FAR MORE people using XAML TODAY (programmers and companies learning Whidbey programming in their longhorn betas) that people that use XUL. There are even more books about XAML.
Also, as Longhorn comes nearer, this will be there for 90% of the people. And the programmers and books will get sky high.
Not flaming but can you point some xaml work? the hundreds of books you talk? And its kind funny you say xul mozilla extensions are “mostly a joke”, when the only thing about xaml i see is calendars and calculators.
Lumbergh, t3rmin4t0r, sry if it sound that way, but i didnt said its using, i know mono uses it, i said dotgnu is thinking about it to solve libs deps issues as i read once on a ml. And actually its right there on the faq section
Some people have suggested interfacing “ilrun” to Wine so as to pick up many of the Windows dependencies. This may work, but we need someone to volunteer to do it first.
For me, and i dont want to take the demerit of this accomplish, this issue of avalon/xaml will be on the same order of wine/x and samba projects, everything fine until you hit ballmer’s foot.
I find quite the opposite. MSOffice is resource hog while you can confine OO to 9 MB or even less. It will be somewhat slower though. I know people who prefer OO over MSOffice just for this reason!!!Also can’t you customize shortcuts for keyboards????
xispes,
‘foljs’ must be trolling… There are plenty of real software projects using XUL. And I mean moneymaking projects, such as OEOne Desktop, Komodo, etc… (I was even hired to do a full commercial product based on XUL).
Also, there have been to date at least three major books about XUL. Which 3 major books have XAML in the title?
All 10 results for xaml in Computers & Internet :
All 41 results for xul in Computers & Internet :
i would love to see yours, despite i do believe when you said, it could superseed when longhorns cames out. The problem is that technology like xaml isnt new, and isnt xul the only matter in this world. terminator already mention XWT, but there are others like luxor, thinlet/swixml or zulu
From what I understand, they key reason XAML will stick is that it is a replacement for MS Windows resource files that gives Glade-like features to MS applications. Anyone who writes a nonweb app for Windows will love it just as GNOME users love Glade. If this was all there is to it, XAML wouldn’t be a big deal. Windows apps are already incompatible with Linux unless you use something like WINE to bridge the gap.
The key issue is that MS is pushing XAML as a quick way to port your nonweb applications to the web without doing much work. If it’s done well, then a whole class of programmers who know nothing about web design will enter the web market and companies can gain the advantages of thin clients without “any” retraining. Of couse, web-XAML is hooked into .NET so there *is* retraining, but that’s ignored by managers in favour of all the things that are now supposed to get “for free” from .NET.
Microsoft’s key problem is that unless XAML runs on all legacy machines, it won’t go far. Since they’ve stopped updating IE, they’re faced with the task of convincing people to move wholesale to Longhorn. What are the odds of that happening, especially since there are still a sizeable number of computers out on the Windows platform who have not upgraded to IE 6.0 (which is a free download)? The Word 6.0 format used is still going strong and hasn’t been replaced by the newer WordXP releases. Netscape 4.x *still* isn’t dead even though it should’ve died ages ago.
This “legacy problem” gives OSS software a bit of time, but it needs to start now. XUL *can* be made into an effective competitor for XAML, but it needs to do the following:
* it should be possible to use XUL in the same way Glade is used for GNOME applications. It may be possible to write a styleshoot to convert XUL into Glade since both are XML. If there are any architecture differences that would prevent this, those need to be sorted out.
* Mozilla needs to create a sandboxed version of XUL.
* The XUL GUI creator currently being worked on needs to be finished.
* Mozilla needs to create a scripting module that supports several sandboxed scripting languages like Java, Python, and even Mono that have accessed to the sandboxed XUL. Until Sun gives up control over Java distribution, the scripting module would use an open source Java. It’s true GNU Classlib has weak AWT and Swing support, but that’s not important since XUL will be the way things get rendered.
* All Mozilla products would need to ship the the sandboxed XUL and scripting module installed by default. The XUL GUI Creator would be displayed prominently on the Mozilla website.
This would effectively give you most of the benefits of XUL fairly quickly and allow people to deploy XUL solutions a few years before that can deploy XAML solutions. (I don’t count XAML Beta testers as deploying anything serious. After all who writes serious software based on a beta framework that has no support and may change at any moment?)
“Why does open sources celebrities ( like Havoc, Icaza, … ) focus on cloning Microsoft’s feats instead of more radical architectures.
”
No. you got it all wrong. miguel talks about an alternative mono stack including ifolder and such while Havoc says its better to come up with our own stuff than include mono
>horizontally()
>make(*button*, label: “Hello”);
>make(*button*, label: “Goodbye”);
>end;
In XUL (also replacing * with brackets):
*hbox*
*button label=”Hello”/*
*button label=”Goodbye”/*
*/hbox*
I am not too familiar with XAML, but why is the XML/GUI approach such a “hack”? To me it seems like GUI layout/style is one of the few *valid* uses for XML. (I.E. Not data management). While I am a (somewhat newbie-ish) fan of functional languages, I still don’t know quite see the benefit to the GUI methods you describe. With XUL, I can interact with the above form elements in *several* programming languages, without ever having to embed any code in XML. In fact, I have nice clean separation of style, form controls, and program logic, allowing me to change CSS styles separately as well as program logic. Also, in my main program code, I can easily define new GUI elements dynamically, or redefine existing ones.
(Also, please understand; I am not just talking about the “web application” approach, but in using XUL for client-side apps)
So, what am I missing? (just curious for your comments…)
Amil,
I think you have hit it dead on. XUL is positioned perfectly to take advantage of these situations, if the right people just grab the opportunity. I would add also that KDE apps use a similar XML approach to the GUI, so potentially, there could be stylesheets to promote interop between XUL, Glade and KDE. (In fact, there is already a KDE project called Kaxul, which allows embedding of XUL in KDE). Now wouldn’t that rock?
XAML its patented by MS?
Thanks for the Kaxul link, I found these links:
http://article.gmane.org/gmane.lisp.scheme.plt/4608
http://www.mail-archive.com/[email protected]/msg0…
http://www.phppatterns.com/index.php/article/articleview/48/1/2/
Not flaming but can you point some xaml work?
Real companies all over the work are evaluating XAML. Which is more than can be said about XUL, isn’t it? There are several XAML projects on the net, one was even posted on this very site.
the hundreds of books you talk?
What I said was “more” not hundreds. And the hundreds of books are coming before long. Just as books for C# are on par with books on Java now.
And its kind funny you say xul mozilla extensions are “mostly a joke”, when the only thing about xaml i see is calendars and calculators.
You talk about demo applications. Real applications will differ. So far XUL is 4+ years old, and only has the equivalent of calculators, calendards and mozilla extensions to show for.
And I mean moneymaking projects, such as OEOne Desktop, Komodo
Komodo and EOne Desktop are “moneymaking projects”? Sure, they are commercial, but moneymaking is a great exaggeration. They are the equivalent of a obsure CD-R brand that noone recognizes. Commercial, but not exactly Coca Cola or BBEdit.
Nice work on the port – people looking for a good markup language for Mono or Portable.NET no doubt have you to thank now. So, rock on, man!
About XUL: XUL would be nice, you know, if it wasn’t whacky-glued to the hipbone of Mozilla and just one language, dig? Someone mentioned a comparison of books, something about how many they found at Amazon.com for XAML and XUL. 10 books on XAML, and that’s the problem, you dig? There are 10 books for something that isn’t even ‘functional’ on non-Longhorn builds. There are already ten books for something that is about a year or two away. That’s dangerous mindshare, man; I mean, how many XUL books were floating around before the UI of Mozilla was just a twinkle in someone’s eye? Hell, even imitators like MyXaml and the rest are just cropping up out of nowhere… and people are using them. Why aren’t they using XUL? That’s what you gotta ask yourself, man.
Imagine what’s going to happen when XAML becomes readily available, you know, its coming with every .NET distribution, sitting on every new computer sold? Better to assimilate now or offer language-agonistic alternatives right now, I say. You can never be too ahead in the game, you know?
Komodo and EOne Desktop are “moneymaking projects”? Sure, they are commercial, but moneymaking is a great exaggeration. They are the equivalent of a obsure CD-R brand that noone recognizes. Commercial, but not exactly Coca Cola or BBEdit.
Umm… if they are in fact making money, that qualifies as “moneymaking”. Yes, I know we are not talking about billions here, but Komodo and Oeone are viable commercial products (Especially Komodo has survived the test of time). I personally am working on a viable XUL-based product, with existing sales volume.
I am not saying XAML is a loser, by any means. I’m sure it will do quite well, and be used in higher volumes than XUL, but just like Linux is doing well, even though Windows gets higher volume, XUL will do just fine.
That’s a fair comment. IMO, the key reason XUL isn’t as wide spread is that it’s a Mozilla-only technology.
Seriously, why *should* the typical developer learn XUL if that’s all it buys you.
If, however, XUL were used by the Mozilla application, the Mozilla web sandbox for running web applications, GNOME, KDE, and other projects (e.g. Eclipse and OpenOffice), wxWindows, there would be much more of a reason to learn. None of these projects has to “give up” their current GUI framework XML format. They only need to be able to translate XUL into that format.
Not to be a bore here, but “10 books on XAML”? If you do a search on Amazon for XAML, you find several books with a *reference* to XAML, but if you do a title search for XAML, you get nothing. Not that books on XUL are plentiful, but the situation is not quite what you describe. There are at least 3 solid books about Mozilla/XUL development(“Essential XUL Programming”, “Creating Applications with Mozilla”, and “Rapid Application Development with Mozilla”), and in an Amazon search you will find quite a few books with a reference to Mozilla or XUL.
Also, it is a misconception that XUL is tied to only one programming language. In fact, anyone can write a binding to XUL, although at present there are C, C++, Python, Perl, Javascript, and a Java binding is in development. Also, XUL is an open spec. Anyone can write a XUL rendering runtime, and I believe it has already been done in Java, ActiveX, and, of all things, Flash.
I mean really, in the end XUL/XAML, whatever… it doesn’t matter. Those are just XML formats; they don’t dictate the programming platform or the rendering platform. The whole point about many of our apprehensions is the possibility that Microsoft will try to pull some sort of cynical stunt with the U.S. Patent office to make life more difficult for the rest of us. If XAML will be a truly open spec, then I say fine, no harm done! In an *ideal* development world, interoperability between XUL/XAML/Glade/Qt/etc would be not only possible but fun for all ;-).
XUL is a lot more popular than most people (including me) realize. Check out this web site which provides a list of several open source and commercial closed sourced implementations of XUL:
http://xul.sourceforge.net/
I am not too familiar with XAML, but why is the XML/GUI approach such a “hack”?
XML for the GUI isn’t inherently a hack. The hack comes in when you need XML GUI files that aren’t just simple descriptions, but procedural descriptions. In a language with macros, you do GUI layout stuff (actually, *any* domain specific stuff), in the same language you regularly program in. With the C# + XML paradigm, you’ve got special hacks to use C# in XML documents (XAML), and hacks to use XML in C# (Xen). When you’ve got metaprogramming available to you, you just have your one language, and can use the full power of that language in your data files. XSL, for example, is a prime example of what happens when you try to work around the lack of programmability in your description language.
In general, static data files are *so* passe. Think of how 3D has evolved. In the past, you had static 3D models and static 2D pictures. Now, your 3D model is manipulated via a bunch of vertex shader programs, and your 2D texture is actually a procedural pixel shader program. Active data is so much more powerful and flexible.
To me it seems like GUI layout/style is one of the few *valid* uses for XML. (I.E. Not data management).
While I am a (somewhat newbie-ish) fan of functional languages
This isn’t really a functional language feature, but more a feature of dynamic languages. Python, for example, can be used to great effect as a replacement for XML. SCONS, the Python-based build system, is a ton easier to use and to extend than the XML + Java-based ANT.
“XUL is a lot more popular than most people (including me) realize. Check out this web site which provides a list of several open source and commercial closed sourced implementations of XUL: