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

Reply via email to