Interesting - no mention of OS X. I know the OS X port has now essentially been left to the excellent NeoOffice - I wonder if a beta 2.0 of that is now on the cards?
I am tempted to help with hacking neo when they get to NeoOffice 2.0
I guess I was not totally clear. I love OSX. It rocks. However, it is always good to have an alternative to consider and Gnome is the next best thing regarding refined interefaces.
Windows interfaces have always and will continue to suck well into the future.
Also, in most large corporate environments, having a mac is considered a joke although I totally disagree. In such cases, Linux is a possible alternative to either expensive Unix boxes or crappy win32 boxes. When linux is the option, I will be selecting Gnome as the desktop and application framework.
Personally, I would vote for Gnome over KDE. Gnome's strict adherence to GUI standards where less is more will get them to a lot more usage in the future. KDE, although very feature friendly, is not nearly as refined as Gnome from a UI perspective and this will bite them in the ass as it has bit Microsoft.
When I look at the latest screenshots, I am blown away with the finite details that the UI designers have gone through. Most importantly, they seem to have stuck with the minimal real estate impact that I have come to love with OSX.
Real estate is where Microsoft have failed in the past with XP sytles and from what I have seen with their replacements, they are only getting worse with tons of real estate taken up by oversized and over spaced text on pretty but poorly contrasted backgrounds.
Keep up the good work Gnome... You are the best bet for me to move to Linus or *bsd besides OSX.
JsD
Side bit - L&M of car manufacturers. Honda (Apple)
- Less but works more but better General Motors (Microsoft)
- More but works less and worse.
Microsoft knows that the bleeding will not stop, they just are putting duct tape (SCO lawsuite) to prevent a flow of their customer base. It gives them a chance to `change their strategies`.
I hope that Driv3r PC and potentially Driv4r don't get effected by this.
I simply loved D1 & 2 and it would be a shame to see those games disapear. If I had to depend on driving with Need for speed or similar games, I'd rather take up full contact basket weaving:|
Just install Subversion, configuration and maintenance is a breeze. Which makes me happy because I have to use it and administer it (or not in the case of svn:)
I love it so much, I am actually considering installing svn on my families computer so they can keep track of their most beloved digital documents as well.
If I had two identically priced and featured products and one was running on.Net and the other JME, I would not even think twice about selecting latter.
There are many in the world who have had enough of the instabilities and insecurity of microsoft software who will do just the same. Just look at the ratio of enterprise applications running on java vs.net. It seems that.net is for the little guy's who are too cheap to spend the money on an enterprise product.
Microsoft has traditionaly avoided following well documented standards such as: CSS, (X)HTML, JS-DOM. Common standards such as: Naming of protocols, file naming paradigms and many others have been avoided.
[q] Will Microsoft continue along these lines of obfuscating standards and common processes in order to distract the users from how the rest of the IT world (*nix) does things?
Limit Scope of Session Cookies - 117222
on
Firefox Roadmap Update
·
· Score: 2, Insightful
The biggest bug I see in *zilla is definitely the session cookie handling:
IE (unfortunately) does a very good job at handling session cookies where: Any window launched from a browser window (window.open(), file>new>window, ctrl-N, ctrl-T open link in new window...) should share the same session cookie. Any new Browser window launched from the Operating System level icon or menu should have it's own session cookie.
Unfortunately, this bug has not been picked up by anybody and is not on the roadmap for any release.
As you can read from the threads, some users have serious problem with this bug as it does impact some multi-user security issues.
The scope of fixing this is probably very huge and impacts many subsets of the mozilla frameworks. But is it not possible to do this just for Firefox? Maybe it being a `Browser Only` could allow hackers to branch some code designs in such a way that they can get a simplified model working and write it in a way that can be merged to the moz trunk without too much pain.
Personally, this one is just way too huge for a minor hacker like I to tackle but I'm sure there are some brave souls willing to tackle this Everest of an issue.
GNUStep's Objective-C programming language is just plain sweet and by adding a native Python bridge and it would be even sweeter. I hope that the developers of PyObjC can get their code trees to work on GNUStep solidly so that coders can bring PyObjC based apps to win32 and *nix environments.
Looked at those Finderworks products and they look sweet. A little expensive but the gesturing interface is not only intuitive.
[q] How is the feel of the keyboard though? Is the keyboard textured in any way so you can feel where home row is or do you have to look down to find home?
Cool with the Mac Laptop keyboard replacement too.
An O.R. framework should be the core model of any enterprise quality workflow framework.
I agree, Objects should be stupid. That's why you declare an object `Type` that has `Attributes` and you declare `Policies` that govern the object types. This way you can have one object that is governed by multiple policies. The policy is the abstraction level where you would declare lifecycles and access.
When an object is instantiated in the ORMF it is specified what policy governs that instance and inherits the policies declared lifecycle and access.
From what I've heard, future versions of Naked Objects will have `Similar Functionality` but I have my doubts. Such a model could be built on the cayenne but would need alot of coding.
Hibernate looks good, but it would only be for developers to hack with (not a bad thing for job security though). The ideal framework for enterprise deployments should allow for schema architects/integration specialists to sit down and just model the business schema without having to do any coding or at least minimal scripting for giving the system a little more depth.
I have not seen any open source projects that can do this out of the box (yet) but the customers will line up at the door when it does (namely most fortune 1000 companies who want to save some big bucks)
First of all, if you are planning on changing the worflows often, you probably want to look at a multi-tier framework that will enable you to model your data in an OO methodology. By using a Object Relational Mapping framework, you can build your implementations on top of a framework that will take care of all your RDBMS work. With these systems, you can more easilly change your model since you are following a generic object model.
The other thing to keep in mind is to not depend on a product to give you a core framework and a UI all in one package. The UI should always be considered secondary to the core framework and you should be able to implement the UI in any way you choose (DHTML, Applet, Thick client...)
I have only seen two Open source frameworks that can follow these conepts. They are:
1) Naked Objects
- http://nakedobjects.org/
- Could be used as a backbone to a workflow system although they are still in the process of realeasing a new version that will.
2) Cayenne
- http://www.objectstyle.org/cayenne/
- Much more enterprise grade framework for building object data models. Probably your best bet.
Currently I use eMatrix which has an awesome core framework but it very expensive to licence and it is a bit of a resource pig. The beauty of eMatrix is the flexibility of the core framework - I can deploy any system you desire on their core framework and not have to worry about any RDBMS coding, PDM, PLM, Workflow, Doc Management, you name it.
I am looking for more alternatives to relieve our licencing costs though and the two noted above are probably the best bets at the current time.
Yes you are correct, JSON parsing is not a lower level than XML, however it is at least as efficient. Just look at the total number of bytes in a JSON data structure vs an XML data structure. The only way to make XML as efficient is to compile it in some form but I've never seen compiled XML or support for such frameworks. Just gzip and you can gzip JSON too.
I'd be surprised if JSON eval is slower than an XML parse.
Another beautiful advantage of JSON is that again it is a native JavaScript data structure. A JSON is an object is a hashmap...
It's the sweetest thing I have ever found in any language. Now if only I did'nt ignore that chapter when I was studying JavaScript way back when...
I use the hidden iFrame technique quite extensivly in an enterprise system and the code needed to make it work solidly is rather complex. Aside from complexity, the hidden iFrame also has issues with the user easily killing the submit/get of the iFrame. This killing of the iFrame must be detected or blocked by the code else the DHTML application fails and the user blames the developer (as expected).
I have gotten around this by poping up a modal window with some eye candy to capture all refreshes, stops, hotkeys etc, while the hidden iFrame is being processed.
The advantage to this JSON-RPC methodology is that the code is completely synchronous. If you look at the source code, the request to the server and the response is on the same line. In the hidden iFrame, the event must be serialized and the loading of the iFrame must de-serialize that thread and continue the code. With JSON-RPC, you are on the next line of code.
Much, much simpler and faster.
Now hopefully, If I can get IE 5.5sp1 to work solidly, all my client side DHTML apps are going this way. Since I've been doing strong client side DHTML apps for years using hidden iframes as an RPC framework, I can turn JSON-RPC on in just a few days:]
Unfortunatly our corp still has images floating around with IE 5.5 sp1 installed. It carries MSXML version 8.0.5226. Has anybody gotten JSON-RPC to work solidly on these versions of IE?
I'm having a bit of trouble tracking down a machine with it installed but I know it's out there.
Java Script Object Notation is a native construct of JavaScript. As such JavaScript interpreters for parsing a JSON construct would be very highly refined requiring minimal resources from the host machine.
JSON parsing was written way before any XML parsing and would be compiled at a lower level since again it is a native construct.
Sure you can use gzip for server-client but you cannot gzip upwards. I have used gzip filters and they work ok. The only unfortunate thing about gzip is with IE - They do not support gzipping of resource files like JS, CSS etc. And unfortunately there was no way I could gate the servlet filter based on the browser's mime type. Although, I could probably hack the servlet filter code but I was not interested in hacking that at the time.
I have given serious consideration to jython for the exact same reasons and I believe I will go there one day but right now my app needs to be enterprise quality and adding jython does not make sense (yet).
For now I have a method for converting an serialized Name Value String to a hashmap to pass a HM colletion from JS to Java. Not super efficient but it does work solidly.
I was converted to using JSON about 2 years ago to enable my rather complex DHTML applications to go to the next level. The transition was so sucessfull that I now use JSON in many levels such as:
1) Server to client hashmaps: JSON is great for passing hashmaps of data and for storing specifications meta data for applications. eg: ServerReport={serverFailed: true, errorMessage: "you used XML dummy"}
2) Application meta data: Storing application configuration using JSON is not only efficient but very easy to maintain and read.
3) Singleton Object Declaration for utility objects: By using JSON to define objects in JavaScript, a singleton object can be used very well to be used as utility objects. By nesting the methods and properties within a JSON spec, you can save on namespace. And as any script programmer (especially JavaScript), namespace is everything.
eg: (real exerpt) _SC=SearchComponent={
log: [],// Private - Condition Index Log
ind: -1,// Private - Condition index
elem: null,// Read only - use setElem
atts: [],// Read only, setAtts()
buildBody: function SC_buildBody(){
return _GUI.buildCurveTable(
(
"table...
4) Function/method arguments: When dealing with many arguments of functions, often the calling code and the method/func get out of hand. By using JSON to pass arguments, you can still read your code from both ends. ie: (another real exerpt I wrote yesterday) function ExtNav_downloadFile(j){
if(
!isJSON(j) ||
!isJSRec(j.fileRec) ||
!isBool(j.lock))
{ debugErr("j must a JSON and contain: fileRec: ~JSRecord~, lock: ~Bool~") }
if(!confirm(ExtNav.buildCMText({ action: (j.lock?"checkout":"download"), fileRec: j.fileRec, userRec: User, popup: false}))){return}
ExtNav.postIt(
(j.lock?"checkout":"download"),
[
"oid",j.fileRec.ID,
"type",j.fileRec.Type,
"filename",j.fileRec.FileName
]
) }
One important note though, It is still better to pass tables of data without the fields being specified. It should be the programmers job to understand that the server sent a table with n fields that are in a particular order. By only passing the data (in a JavaScript array not JSON), the data size is greatly reduced. ie: aTableDat=[
["r1f1","r1f2","r1f3"],
["r2f1","r2f2","r2f3"] ]
Another interesting thing is that Python has JSON natively interpreted like JavaScript. Meaning that a Python based servlet could very efficiently communicate information with the client application.
Anybody sucessfully get printing to work with Open Office via X11 the first time. I have followed all the documentation on how to hack the printing engine , install all the proper dependancies and configure them and it's never worked:[
The end solution was to export to PDF then open the PDF in preview and then print. Kinda like a Microsoft workflow:p.
Is there any reason that Apple cannot create a bridge to enable X11 apps to print directly through the OSX printing frameworks?
Tighter Quartz WM integrations would be sweet too such as x11 apps showing up on doc and X11 acting more as a system level application instead of a regular dockable application.
Considering that OOO have dumped Native Aqua port, it would be nice to have Apples X11 less intimidating for non-*nix hackers.
Slashdot Mirror
Not so cheesy database GUI.
Interesting - no mention of OS X. I know the OS X port has now essentially been left to the excellent NeoOffice - I wonder if a beta 2.0 of that is now on the cards?
I am tempted to help with hacking neo when they get to NeoOffice 2.0
I guess I was not totally clear. I love OSX. It rocks. However, it is always good to have an alternative to consider and Gnome is the next best thing regarding refined interefaces.
Windows interfaces have always and will continue to suck well into the future.
Also, in most large corporate environments, having a mac is considered a joke although I totally disagree. In such cases, Linux is a possible alternative to either expensive Unix boxes or crappy win32 boxes. When linux is the option, I will be selecting Gnome as the desktop and application framework.
Personally, I would vote for Gnome over KDE. Gnome's strict adherence to GUI standards where less is more will get them to a lot more usage in the future. KDE, although very feature friendly, is not nearly as refined as Gnome from a UI perspective and this will bite them in the ass as it has bit Microsoft.
... You are the best bet for me to move to Linus or *bsd besides OSX.
When I look at the latest screenshots, I am blown away with the finite details that the UI designers have gone through. Most importantly, they seem to have stuck with the minimal real estate impact that I have come to love with OSX.
Real estate is where Microsoft have failed in the past with XP sytles and from what I have seen with their replacements, they are only getting worse with tons of real estate taken up by oversized and over spaced text on pretty but poorly contrasted backgrounds.
Keep up the good work Gnome
JsD
Side bit - L&M of car manufacturers.
Honda (Apple)
- Less but works more but better
General Motors (Microsoft)
- More but works less and worse.
The only reason Driv3r was so expensive is that the developers are pushing the xbox and PS2 to the raw limits of what they can do.
:]
The physics from Driver 1 and 2 were brilliant. I hope that the main developers continue along their physics purist vain.
Sure it's expensive, but sure beats denting up my honda in toronto traffic
Lets face it. Some people can't see the truth.
:]
Microsoft knows that the bleeding will not stop, they just are putting duct tape (SCO lawsuite) to prevent a flow of their customer base. It gives them a chance to `change their strategies`.
[: Only Sheeps Avoid the FireFox
I hope that Driv3r PC and potentially Driv4r don't get effected by this.
:|
I simply loved D1 & 2 and it would be a shame to see those games disapear. If I had to depend on driving with Need for speed or similar games, I'd rather take up full contact basket weaving
Just install Subversion, configuration and maintenance is a breeze. Which makes me happy because I have to use it and administer it (or not in the case of svn:)
I love it so much, I am actually considering installing svn on my families computer so they can keep track of their most beloved digital documents as well.
JsD
If I had two identically priced and featured products and one was running on .Net and the other JME, I would not even think twice about selecting latter.
.net. It seems that .net is for the little guy's who are too cheap to spend the money on an enterprise product.
There are many in the world who have had enough of the instabilities and insecurity of microsoft software who will do just the same. Just look at the ratio of enterprise applications running on java vs
Time to buy those Options on Microsoft Stocks.
JsD
[karma=(moz+nix+ooo)-ms]
Microsoft has traditionaly avoided following well documented standards such as: CSS, (X)HTML, JS-DOM. Common standards such as: Naming of protocols, file naming paradigms and many others have been avoided.
[q] Will Microsoft continue along these lines of obfuscating standards and common processes in order to distract the users from how the rest of the IT world (*nix) does things?
The biggest bug I see in *zilla is definitely the session cookie handling:
7 22 2
https://bugzilla.mozilla.org/show_bug.cgi?id=11
IE (unfortunately) does a very good job at handling session cookies where: Any window launched from a browser window (window.open(), file>new>window, ctrl-N, ctrl-T open link in new window...) should share the same session cookie. Any new Browser window launched from the Operating System level icon or menu should have it's own session cookie.
Unfortunately, this bug has not been picked up by anybody and is not on the roadmap for any release.
As you can read from the threads, some users have serious problem with this bug as it does impact some multi-user security issues.
The scope of fixing this is probably very huge and impacts many subsets of the mozilla frameworks. But is it not possible to do this just for Firefox? Maybe it being a `Browser Only` could allow hackers to branch some code designs in such a way that they can get a simplified model working and write it in a way that can be merged to the moz trunk without too much pain.
Personally, this one is just way too huge for a minor hacker like I to tackle but I'm sure there are some brave souls willing to tackle this Everest of an issue.
JsD
Although the Apple LT comes with a trackpad, it is not needed anymore once you get this new keyboard from Fingerworks:
m l
http://www.fingerworks.com/MacNTouch_product.ht
I don't own it (yet) but from what I see so far, they are going down the right path.
GNUStep's Objective-C programming language is just plain sweet and by adding a native Python bridge and it would be even sweeter. I hope that the developers of PyObjC can get their code trees to work on GNUStep solidly so that coders can bring PyObjC based apps to win32 and *nix environments.
Currently, PyObjC is kind of limited to OSX.
JsD
Doooh! - Tydo... er ...Typo
Looked at those Finderworks products and they look sweet. A little expensive but the gesturing interface is not only intuitive.
[q] How is the feel of the keyboard though? Is the keyboard textured in any way so you can feel where home row is or do you have to look down to find home?
Cool with the Mac Laptop keyboard replacement too.
An O.R. framework should be the core model of any enterprise quality workflow framework.
I agree, Objects should be stupid. That's why you declare an object `Type` that has `Attributes` and you declare `Policies` that govern the object types. This way you can have one object that is governed by multiple policies. The policy is the abstraction level where you would declare lifecycles and access.
When an object is instantiated in the ORMF it is specified what policy governs that instance and inherits the policies declared lifecycle and access.
From what I've heard, future versions of Naked Objects will have `Similar Functionality` but I have my doubts. Such a model could be built on the cayenne but would need alot of coding.
Hibernate looks good, but it would only be for developers to hack with (not a bad thing for job security though). The ideal framework for enterprise deployments should allow for schema architects/integration specialists to sit down and just model the business schema without having to do any coding or at least minimal scripting for giving the system a little more depth.
I have not seen any open source projects that can do this out of the box (yet) but the customers will line up at the door when it does (namely most fortune 1000 companies who want to save some big bucks)
First of all, if you are planning on changing the worflows often, you probably want to look at a multi-tier framework that will enable you to model your data in an OO methodology. By using a Object Relational Mapping framework, you can build your implementations on top of a framework that will take care of all your RDBMS work. With these systems, you can more easilly change your model since you are following a generic object model.
The other thing to keep in mind is to not depend on a product to give you a core framework and a UI all in one package. The UI should always be considered secondary to the core framework and you should be able to implement the UI in any way you choose (DHTML, Applet, Thick client...)
I have only seen two Open source frameworks that can follow these conepts. They are:
1) Naked Objects
- http://nakedobjects.org/
- Could be used as a backbone to a workflow system although they are still in the process of realeasing a new version that will.
2) Cayenne
- http://www.objectstyle.org/cayenne/
- Much more enterprise grade framework for building object data models. Probably your best bet.
Currently I use eMatrix which has an awesome core framework but it very expensive to licence and it is a bit of a resource pig. The beauty of eMatrix is the flexibility of the core framework - I can deploy any system you desire on their core framework and not have to worry about any RDBMS coding, PDM, PLM, Workflow, Doc Management, you name it.
I am looking for more alternatives to relieve our licencing costs though and the two noted above are probably the best bets at the current time.
JsD
Yes you are correct, JSON parsing is not a lower level than XML, however it is at least as efficient. Just look at the total number of bytes in a JSON data structure vs an XML data structure. The only way to make XML as efficient is to compile it in some form but I've never seen compiled XML or support for such frameworks. Just gzip and you can gzip JSON too.
I'd be surprised if JSON eval is slower than an XML parse.
Another beautiful advantage of JSON is that again it is a native JavaScript data structure. A JSON is an object is a hashmap...
It's the sweetest thing I have ever found in any language. Now if only I did'nt ignore that chapter when I was studying JavaScript way back when...
I use the hidden iFrame technique quite extensivly in an enterprise system and the code needed to make it work solidly is rather complex. Aside from complexity, the hidden iFrame also has issues with the user easily killing the submit/get of the iFrame. This killing of the iFrame must be detected or blocked by the code else the DHTML application fails and the user blames the developer (as expected).
:]
I have gotten around this by poping up a modal window with some eye candy to capture all refreshes, stops, hotkeys etc, while the hidden iFrame is being processed.
The advantage to this JSON-RPC methodology is that the code is completely synchronous. If you look at the source code, the request to the server and the response is on the same line. In the hidden iFrame, the event must be serialized and the loading of the iFrame must de-serialize that thread and continue the code. With JSON-RPC, you are on the next line of code.
Much, much simpler and faster.
Now hopefully, If I can get IE 5.5sp1 to work solidly, all my client side DHTML apps are going this way. Since I've been doing strong client side DHTML apps for years using hidden iframes as an RPC framework, I can turn JSON-RPC on in just a few days
Unfortunatly our corp still has images floating around with IE 5.5 sp1 installed. It carries MSXML version 8.0.5226. Has anybody gotten JSON-RPC to work solidly on these versions of IE?
I'm having a bit of trouble tracking down a machine with it installed but I know it's out there.
Tnx
JsD
Java Script Object Notation is a native construct of JavaScript. As such JavaScript interpreters for parsing a JSON construct would be very highly refined requiring minimal resources from the host machine.
JSON parsing was written way before any XML parsing and would be compiled at a lower level since again it is a native construct.
Python would be the same.
Sure you can use gzip for server-client but you cannot gzip upwards. I have used gzip filters and they work ok. The only unfortunate thing about gzip is with IE - They do not support gzipping of resource files like JS, CSS etc. And unfortunately there was no way I could gate the servlet filter based on the browser's mime type. Although, I could probably hack the servlet filter code but I was not interested in hacking that at the time.
I have given serious consideration to jython for the exact same reasons and I believe I will go there one day but right now my app needs to be enterprise quality and adding jython does not make sense (yet).
For now I have a method for converting an serialized Name Value String to a hashmap to pass a HM colletion from JS to Java. Not super efficient but it does work solidly.
I was converted to using JSON about 2 years ago to enable my rather complex DHTML applications to go to the next level. The transition was so sucessfull that I now use JSON in many levels such as:
// Private - Condition Index Log // Private - Condition index // Read only - use setElem // Read only, setAtts() ...
1) Server to client hashmaps:
JSON is great for passing hashmaps of data and for storing specifications meta data for applications.
eg:
ServerReport={serverFailed: true, errorMessage: "you used XML dummy"}
2) Application meta data:
Storing application configuration using JSON is not only efficient but very easy to maintain and read.
3) Singleton Object Declaration for utility objects:
By using JSON to define objects in JavaScript, a singleton object can be used very well to be used as utility objects. By nesting the methods and properties within a JSON spec, you can save on namespace. And as any script programmer (especially JavaScript), namespace is everything.
eg: (real exerpt)
_SC=SearchComponent={
log: [],
ind: -1,
elem: null,
atts: [],
buildBody: function SC_buildBody(){
return _GUI.buildCurveTable(
(
"table
4) Function/method arguments:
When dealing with many arguments of functions, often the calling code and the method/func get out of hand. By using JSON to pass arguments, you can still read your code from both ends.
ie: (another real exerpt I wrote yesterday)
function ExtNav_downloadFile(j){
if(
!isJSON(j) ||
!isJSRec(j.fileRec) ||
!isBool(j.lock))
{ debugErr("j must a JSON and contain: fileRec: ~JSRecord~, lock: ~Bool~") }
if(!confirm(ExtNav.buildCMText({ action: (j.lock?"checkout":"download"), fileRec: j.fileRec, userRec: User, popup: false}))){return}
ExtNav.postIt(
(j.lock?"checkout":"download"),
[
"oid",j.fileRec.ID,
"type",j.fileRec.Type,
"filename",j.fileRec.FileName
]
)
}
One important note though, It is still better to pass tables of data without the fields being specified. It should be the programmers job to understand that the server sent a table with n fields that are in a particular order. By only passing the data (in a JavaScript array not JSON), the data size is greatly reduced. ie:
aTableDat=[
["r1f1","r1f2","r1f3"],
["r2f1","r2f2","r2f3"]
]
Another interesting thing is that Python has JSON natively interpreted like JavaScript. Meaning that a Python based servlet could very efficiently communicate information with the client application.
JsD
[Use FireFox and JSON or Die:]
Well, I now see why NeoOffice wins.
I guess I should completely dump the concept of installing OOO X11 on anybody's machines from now on and just go to your package.
I assume that X11 version of OOO will just be for those who either want the `latest OOO` or just love to use X11 (not sure who or why but...)
Thanks for the info. I've downloaded latest NeoOffice and it works great.
Keep up the great work!
JsD
Anybody sucessfully get printing to work with Open Office via X11 the first time. I have followed all the documentation on how to hack the printing engine , install all the proper dependancies and configure them and it's never worked :[
:p.
The end solution was to export to PDF then open the PDF in preview and then print. Kinda like a Microsoft workflow
Is there any reason that Apple cannot create a bridge to enable X11 apps to print directly through the OSX printing frameworks?
Tighter Quartz WM integrations would be sweet too such as x11 apps showing up on doc and X11 acting more as a system level application instead of a regular dockable application.
Considering that OOO have dumped Native Aqua port, it would be nice to have Apples X11 less intimidating for non-*nix hackers.
JsD