On Mon, Jan 26, 2015 at 3:18 PM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > > On 01/20/2015 01:32 PM, Kay Schenk wrote: > > > > > > On 01/20/2015 11:28 AM, Dennis E. Hamilton wrote: > >> Louis asks about a dependency on LGPL. > >> > >> -- replying below to -- > >> From: Louis Suárez-Potts [mailto:lui...@gmail.com] > >> Sent: Tuesday, January 20, 2015 07:05 > >> To: dev@openoffice.apache.org > >> Subject: Re: [DISCUSS] Qt as a replacement for VCL > >> > >> [ ... ] > >> > >> Indeed, thanks. But let me get this straight. The Qt license, which for > us would be LGPL, is not an obstacle? (I know you described a possible > usage that did not seem to transgress license. But we should need to be > rather careful here.) > >> > >> <orcmid> > >> Yuri had intentionally stayed away from the license question and > >> simply described his impression of Qt in terms of technology. > >> However, I do believe that having Qt in place of VCL would be > >> very serious (although allowing Qt under VCL as an *option* is > different). > >> > >> I believe the governing conditions in the Apache Project Maturity > Model > >> (https://wiki.apache.org/incubator/ApacheProjectMaturityModel) are > CD20, > >> CD30, and especially LC20. > >> Going to Qt would be more than a requirement for using the > compiled > >> code, it would also be a requirement for being able to compile the > code. > > > > My impression was only the latter in the same way we use other libraries > > outside of AOO to build. See info on the QuickCompiler page -- > > http://doc.qt.io/QtQuickCompiler/index.html > > > >> In the case of writing aids that are made available with AOO binaries > >> (or as extensions), there is no dependency concerning licensed > material > >> at the AOO source-code level. The license accompanies the extension, > >> but the extension's usage at the AOO level is indifferent and the > >> extensions are replaceable. Recall the project was very careful > about > >> that. > >> > >> Relying on Qt, even as a redistributable shared library obtained > from the > >> Qt project, makes it not possible to build AOO without that > dependency, > >> and it would permeate the APIs and source-code architecture > everywhere. > >> Apart from the effort required to do that, I think that is a serious > >> intrusion of an LGPL dependency into the entire project. > >> > >> I think there is an open question about sliding Qt under VCL as > simply a > >> platform adaptation. My question to Yuri was about what he knew > concerning > >> lifecycle management in handling that. I believe that remains to be > >> explored. That might be someone's itch to scratch, but I don't > think it > >> should distract the project at this point. I think there are many > other > >> pressing matters that require someone with both an itch and the > means to > >> scratch it. > >> > >> I also think there is some sort of confusion of Qt with respect to > Webkit. > >> I am not certain what that is. However, to the degree one is > interested > >> in moving toward light-weight GUIs that take advantage of the HTML5, > CSS, > >> and JavaScript support on devices and the cloud, there seem to be > more > >> direct avenues that one might consider for AOO, although I for one am > >> completely ignorant of what that would disrupt in the current AOO > >> architecture and source-code structures. > >> > >> Squirrel !;<). > >> </orcmid> > >> > >> > >> > >> > > It's taken me a while to get back to this thread. As further points of > interest in this discussion: > > * Our Mac OSX version uses a native port to Aqua with minimal hooks to > VCL -- > see > > https://wiki.openoffice.org/wiki/User:Ericb#What_do_we_have_to_build_in_vcl.3F > > Also see sources in: > http://svn.apache.org/viewvc/openoffice/trunk/main/vcl/ > > Not being a Mac builder, I was not aware of this. > > * We already have "plugins" from vcl to gtk, kde, and kde4. > I would need to get into the code more to see how these function as > opposed to what I'm on now --vcl. A plugin to qt would work the same way > I suspect. > > My research so far has produced more questions at this point. > It is definitely true that "trying" to pull out vcl completely (as was > done with the aqua port for the most part I imagine) and using qt is the > best way to determine any viability. Not in trunk of course. > > This might be a fun experiment for a class of CSCI students. > ... and yet another observation. Our Linux builds actually use the vcl/gtk+ plugin by default unless disabled. Who knew. > -- > ------------------------------------------------------------------------- > MzK > > "An old horse for a long, hard road, > a young pony for a quick ride." > -- Texas Bix Bender > -- ------------------------------------------------------------------------------------------------- MzK "An old horse for a long, hard road, a young pony for a quick ride." -- Texas Bix Bender
