Interesting.
I did read the article Mr. Pennington wrote and he's addressing/discussing several issues. Quite a box full of ideas, concepts and issues to think about that's for sure. XAML sounds quite scary in what it's trying to do. It's literally taking over *everything*. I wonder what Adobe feels about this. How about Macromedia? I've always said that the best way Linux can help take down MSW is by luring the big S/W developers over to Linux. MS may indeed be creating a self fulfilling prophesy by doing this because Macromedia and Adobe are going to be out in the street if this XAML thing ever flies.
Anyways, back to the post to this group and the specific question about GTK+ 3.0. I have a nasty idea that would not only stick it to M$ but as well up the technological ante in the war of OS superior. At the end of this article, Mr. Pennington describes 3 platform elements:
1.) Elements that determine how the desktop works, looks, and feels
2.) Elements that define interactions or interfaces among applications
3.) Elements that are user-invisible and can be decided application-by-application
2.) Elements that define interactions or interfaces among applications
3.) Elements that are user-invisible and can be decided application-by-application
First off, to get all of this up and running it would take much too long to build all from scratch at the same time why reinvent the wheel right?
For 1.) simply pick a XUI (or some of you are calling it a XUL :oP). A XUI should be cross platform *and* cross language so that the platform that GNOME is using can use whatever language it requires (C, C++, C#, Java, etc.). I good choice would be a XUI that either has a tagset for handling events or a a cross platform /cross language language that is used to describe what happens with the events. For choice #1 (tagset supporting events) the advantage is that it is all one tagset and thus only one specification. The downside is however that the tagset is huge, heavy and can cause event handling to become quite inefficient. For choice #2, I would choose an XOOP (pronounced 'zoop'). That is an XML Object Oriented Programming language. SuperX++ is one such language. This would be my choice since it would offer a separate language for programming keeping it separate from the language used to describe the UI. Both could be tied together and since they are both high enough abstractions, Java could be used for one and C++ could be used for another.
You can also dump SVG into here as well. It's powerful, useful and can and will be expanded on in the future. Since it's XML, there's the ability to dump SVG elements into XUI elements as well. Maybe that's another requirement for a good XUI (one that mine currently does not contain - oh well :o/).
For markup of text, why not just stick with XHTML? It's nothing fancy or pretty but because it's XML, it can follow the same rules as above where it can be dumped into other XML elements from different tagsets (e.g. XUI tagset, SVG tagset, etc.)
For 2.) I don't see why something like SOAP couldn't be used. Again dont' reinvent the wheel.
For 3.) I'm not sure if I correctly understand what it means but what I read it to mean is an abstraction of the application from the data and it's type. I have for the last 2 years been waiting to see someone come up with an XML based file system where 'files' are really just XML nodes. Each node contains information about what the node is about. Nodes could be really large (i.e. > 1MB) or really small (i.e. < 2Kb). Each node would have a header in it which would describe the type of data, owner, copyright, category, sub category, etc. An excellent technology to use for this type of description would be to adopt RDF along with the Dublin Core so that Semantic Web applications could chew through the XML file system and be able to use inference rules to decide what data could be used for a certain application. Of course at some point it would also become beneficial to throw in some DAML or an XML version of KQML so that agents could be run as processes within the OS that act as waiters to the user. The user could be as flaky and wingy as me when trying to remember the name of a file and tell the agent that "it has information about snow boarding *and* was saved somewhere around Christmas time - but I can't remember all of the other details about that article/file."
This all of course goes well and beyond a simple desktop system. It suggests a new way of storing data and new ways for applications to treat data. But then again, if you really want to try to stick it to M$, this may be a step in the right direction. It would also make Linux ever more superior over any Windoze version that M$ comes up with no matter how "pretty" they make their UI.
Arron Ferguson
[EMAIL PROTECTED] wrote: -----
<snip>
Havoc writes:
One discussion the desktop community should have in
parallel with the language issue: how do we address
XAML, and how do we evolve GTK+, Qt, XUL, and so forth
to provide an alternative? Perhaps XAML is a vaporware
silly idea we can ignore, but we need to get far
enough along with some serious thinking to feel
confident in that. If XAML is for real, it could
replace HTML and the Internet becomes MSN, as
Microsoft dreamed 10 years ago.
The high-level language and XAML discussions flow
naturally into the question of what GTK+ 3.0 should be
like.
<snip>
NHS^隊X'uS+l.)ۭޱy
zThm'^֧t!:(!h'-櫝ޯ+ax wZj[-̬vhkjبmv,vw(xF"w~\'$mjY&j)b bn֥X( ~zwilqzlX)ߣn֥
One discussion the desktop community should have in
parallel with the language issue: how do we address
XAML, and how do we evolve GTK+, Qt, XUL, and so forth
to provide an alternative? Perhaps XAML is a vaporware
silly idea we can ignore, but we need to get far
enough along with some serious thinking to feel
confident in that. If XAML is for real, it could
replace HTML and the Internet becomes MSN, as
Microsoft dreamed 10 years ago.
The high-level language and XAML discussions flow
naturally into the question of what GTK+ 3.0 should be
like.
<snip>
