I think these proposals are interesting as food for thought ... -- replying below to -- From: Fernando Cassia [mailto:fcas...@gmail.com] Sent: Thursday, January 15, 2015 09:00 To: dev@openoffice.apache.org; Dennis Hamilton Subject: Re: [DISCUSS] Qt as a replacement for VCL
On Wed, Jan 14, 2015 at 2:27 PM, Dennis E. Hamilton <dennis.hamil...@acm.org > wrote: > Maintaining the independently-developed VCL GUI framework is an > important concern. (Then there's UNO as a cross-platform COM > derivative.) > There's two possible approaches that I could see, long-term. #1 Separating the VCL GUI Framework as a separate Apache project, boosting its adoption into OTHER FOSS and Apache projects. This way, it gets more developers, more usage, and more fixes, faster. <orcmid> I don't know enough about VCL to know how to stack it up against other GUI frameworks, most of which are sustaining quite successfully on their own. It might make more sense to see if there is an abstraction layer that makes integration in other GUI frameworks easier, but I suspect that there are well-known difficulties with that idea. I think it is important to have a portable, cross-platform approach, but it can also be very appealing to be able to adapt to native technologies that have performance and platform adaptability of their own, and have good sustainability. I have no insight into any of that. Any exploration that comes to mind would be on something much smaller than AOO in order to have confidence in a proof-of-concept. Another consideration: How well one can get VCL interfaces tied to an underlying HTML/CSS/JavaScript mechanism, say WebKit or some flavoring of node.js? </orcmid> 1b Doing the same for UNO <orcmid> There are similar considerations here. At an initial level of scrutiny, UNO is a Microsoft COM work-alike that avoids some platform messiness. (I.e., the System Manager doesn't have to be ported everywhere.) That's a good idea but it would also be a good idea, if feasible, to ensure binary interoperability with COM. (I know that was figured out for JNI on Windows.) That should still provide the scripting inter-op, extension plug-ins, and allow reliance on native provisions where there is existing support, which means more off-loading to the platform when there are already COM interfaces to exploit. </orcmid> #2 Making AOO.Next use OpenJFX 2.2+, which is, incidentally, what ORCL wanted to do with OpenOffice.org and StarOffice before the LO freedom fighters *pun intended* caused the demise of the product and the layoffs. http://www.devx.com/blog/2009/06/ellison-hints-at-oracles-java.html OpenJFX is open source, and beginning with 2.2, allows native packaging of JFX apps without requiring the installation or availability of the JRE. Plus, OpenJFX allows the GUIs tweakling to be done in CSS, which in turn allows for simple portability to mobile devices. see http://code.makery.ch/blog/javafx-vs-html5/ So far, JavaFX seems to be pretty robust for mission critical apps... if in doubt ask NASA ;) http://tune.pk/video/2534676/polaris-javafx-controlsfx-and-fxyz-supporting-nasa-missions For #2, however, there's licensing issues (OpenJFX being GPL) which I won't get into because I'm not a lawyer, so I don't know how easy it'd be to integrate with AOO.. <orcmid> The licensing issue apart, this means basically a switch of GUI and more Java-ness, however one manages to provide the runtime, if I understand what is involved. This strikes me as completely abandoning VCL (and I have no idea what it does for all the places where UNO is exposed). Now I wonder about gradualism and how one might migrate. I can get my head around UNO migration, and I may even be delusional about that. It is very difficult to conceive of a rewrite into a completely different framework and execution model. So this raises the question about the relationship of AOO.next to AOO.present and whether we're talking about a new personal productivity suite with migration from AOO.past. </orcmid> #3 (I know I said two... but...) There's Apache Pivot's WTK tookit. I have no idea of how well it compared to JavaFX http://pivot.apache.org/tutorials/ <orcmid> OK, so it is more commitment to JVM languages. No licensing problem, apparently, but it may cut us off from the direction mobile applications are going. </orcmid> Food for thought, thinking aloud. FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
