You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Kay Schenk <ka...@gmail.com> on 2015/01/14 00:45:57 UTC
[DISCUSS] Qt as a replacement for VCL
Something I started thinking about and ta da...it's been proposed before --
http://markmail.org/message/gjvwudqnzejlzynz
In my mind, we could use some assistance in the maintenance of the
toolkit for our UI instead of continuing to do it ourselves. This said,
I know next to nothing about QT and from what I've seen, the licensing
is pretty complicated and might not work for the ASF --
http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
Main web site -- http://qt-project.org/
Thoughts?
--
-------------------------------------------------------------------------
MzK
"There's a bit of magic in everything,
and some loss to even things out."
-- Lou Reed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Louis Suárez-Potts <lu...@gmail.com>.
> On 14 Jan 2015, at 12:27, Dennis E. Hamilton <de...@acm.org> wrote:
>
> The TL;DR: I don't think there is a reasonable way to depend on Qt in AOO.
>
> I also don't think that depending on Qt, were it feasible, would satisfy the concern that started this thread concerning the difficulty of maintaining [with] VCL. It might just move the pea to a more-difficult third-party dependency, after requiring a mammoth cut-over to a new GUI framework.
Agreed.
The sole benefit, besides pleasing some, would be to bring in new developers and plausibly more companies. But I doubt the cost of switching would be paid by the influx of contributors and I would expect that if we do want to engage in a new, and probably ruthless refactoring, that we should look elsewhere.
louis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The TL;DR: I don't think there is a reasonable way to depend on Qt in AOO.
I also don't think that depending on Qt, were it feasible, would satisfy the concern that started this thread concerning the difficulty of maintaining [with] VCL. It might just move the pea to a more-difficult third-party dependency, after requiring a mammoth cut-over to a new GUI framework.
-- replying below to --
From: Louis Suárez-Potts [mailto:luispo@gmail.com]
Sent: Tuesday, January 13, 2015 20:59
To: dev@openoffice.apache.org
Subject: Re: [DISCUSS] Qt as a replacement for VCL
> On 13 Jan 2015, at 23:04, Dennis E. Hamilton <de...@acm.org> wrote:
[ ... ]
> PS: I thought there was a LGPL case where you could run QT as a DLL underneath an application, but I don't see how that can work with an ASF Project for a number of reasons. I also don't see anything about that featured in the current materials (although Wikipedia points to the Digia QT LGPL Exception, which is at the bottom of this page:
> <http://doc.qt.io/qt-5/lgpl.html#digia-qt-lgpl-exception-version-1-1>.
> Some of the gyrations may be related to how QT was spun into and out of Nokia. According to my email archives, I apparently stopped paying attention to it at the end of 2011. I may also may be thinking of a different project with regard to using a pre-built DLL and LIB.
>
>
I think Dennis summarised the point well, However, some more:
I had the impression that ASL 2 was compatible with (L)GPL3--but there is some salt here, and it also depends on what you want to infer by “compatible”. Where work would be done on the product using Qt licensed under LGPL or GPL is one issue, and the scope of the work is another. In this case, given the nature of the VCL, the result would probably also be licensed under Qt’s license.
<orcmid>
The ASLv2 compatibility with GPL is from the GPL side.
That is, ASLv2 code can be depended on in GPL projects.
The Apache Software Foundation has more constraints on
what releases under its auspices may depend upon.
There is a nice summary of the applicable principles
under discussion at this very moment:
<https://wiki.apache.org/incubator/ApacheProjectMaturityModel>.
</orcmid>
However, that does not mean that add-ons, plug-ins, and other such enhancements couldn’t be made using Qt and hosted off-site. And, yes, we’ve had this very discussion before, many times before, *many* times. (And also hosted extensions off-site, with varying licenses, to the annoyance of the FSF.)
<orcmid>
I don't doubt that an ALv2-licensed deliverable could depend on
LGPL-licensed code so long as the combined rules of LGPL and GPL
are satisfied by the way the LGPL-licensed code is handled.
However, what the ASF requires of its projects is more stringent
than that, going beyond the FSF-accepted compatibility to limit
what ASF-approved releases can impose on someone who wants to
employ them.
As far as I recall, that's why AOO must be buildable without
reliance on what are called category-X dependencies. The
case of writing tools and some others tend to be finessed via
the plug-in extension route, even if bundled in the AOO-provided
distributions.
Depending on Qt for being able to use AOO at all goes way
beyond that tolerance, it seems to me.
</orcmid>
Originally, the issue preventing use of Qt with OOo was that it forbade free commercial application. Sun didn’t like that as it loved StarOffice. But then Sun sank, OpenOffice got Apache’d and Qt’s license changed (wonder why) and went as Dennis describes it: open and also proprietary.
There are some Apache projects that do use Qt, and Qt itself does use ASL2 for some modules. But I think that replacing the longstanding VCL with the popular favourite Qt is not exactly feasible and that there are likely easier alternatives, if we want to change. Is it worth investigating again? I mean not just to reconsider Qt but also VCL.
<orcmid>
I am curious about Apache projects that use Qt.
I'd like to see how they navigate that.
Any links?
</orcmid>
But back to Qt: hope springs eternal, and Qt remains popular, whatever its license and other flaws. I don’t just mean that the Digia exception should give us hope—though why not? Establishing useful compatibility with Apache and for Apache, as well as for users of Qt independent of Apache, would dramatically expand the tool’s usage, I’d guess.
Qt’s pages are fairly good, and probably better than my interpretations. Stackoverflow is also good. See:
louis
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Louis Suárez-Potts <lu...@gmail.com>.
> On 13 Jan 2015, at 23:04, Dennis E. Hamilton <de...@acm.org> wrote:
>
> I think the licensing situation is very clear.
>
> There are two licensing arrangements.
>
> The free license is standard GPL3/LGPL3.
>
> There is a commercial license for proprietary, closed source work. That license has to be purchased and there are flavors of it, such as Indie Mobile, Professional, Enterprise, Device Creation, Cloud Services, etc. These do not qualify as open-source licenses.
>
> Here's the fee structure along with the license flavors: <http://www.qt.io/download/>.
>
> - Dennis
>
> PS: I thought there was a LGPL case where you could run QT as a DLL underneath an application, but I don't see how that can work with an ASF Project for a number of reasons. I also don't see anything about that featured in the current materials (although Wikipedia points to the Digia QT LGPL Exception, which is at the bottom of this page:
> <http://doc.qt.io/qt-5/lgpl.html#digia-qt-lgpl-exception-version-1-1>.
> Some of the gyrations may be related to how QT was spun into and out of Nokia. According to my email archives, I apparently stopped paying attention to it at the end of 2011. I may also may be thinking of a different project with regard to using a pre-built DLL and LIB.
>
>
I think Dennis summarised the point well, However, some more:
I had the impression that ASL 2 was compatible with (L)GPL3--but there is some salt here, and it also depends on what you want to infer by “compatible”. Where work would be done on the product using Qt licensed under LGPL or GPL is one issue, and the scope of the work is another. In this case, given the nature of the VCL, the result would probably also be licensed under Qt’s license.
However, that does not mean that add-ons, plug-ins, and other such enhancements couldn’t be made using Qt and hosted off-site. And, yes, we’ve had this very discussion before, many times before, *many* times. (And also hosted extensions off-site, with varying licenses, to the annoyance of the FSF.)
Originally, the issue preventing use of Qt with OOo was that it forbade free commercial application. Sun didn’t like that as it loved StarOffice. But then Sun sank, OpenOffice got Apache’d and Qt’s license changed (wonder why) and went as Dennis describes it: open and also proprietary.
There are some Apache projects that do use Qt, and Qt itself does use ASL2 for some modules. But I think that replacing the longstanding VCL with the popular favourite Qt is not exactly feasible and that there are likely easier alternatives, if we want to change. Is it worth investigating again? I mean not just to reconsider Qt but also VCL.
But back to Qt: hope springs eternal, and Qt remains popular, whatever its license and other flaws. I don’t just mean that the Digia exception should give us hope—though why not? Establishing useful compatibility with Apache and for Apache, as well as for users of Qt independent of Apache, would dramatically expand the tool’s usage, I’d guess.
Qt’s pages are fairly good, and probably better than my interpretations. Stackoverflow is also good. See:
louis
>
> -----Original Message-----
> From: Kay Schenk [mailto:kay.schenk@gmail.com]
> Sent: Tuesday, January 13, 2015 15:46
> To: OOo Apache
> Subject: [DISCUSS] Qt as a replacement for VCL
>
> Something I started thinking about and ta da...it's been proposed before --
>
> http://markmail.org/message/gjvwudqnzejlzynz
>
> In my mind, we could use some assistance in the maintenance of the
> toolkit for our UI instead of continuing to do it ourselves. This said,
> I know next to nothing about QT and from what I've seen, the licensing
> is pretty complicated and might not work for the ASF --
>
> http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
>
> Main web site -- http://qt-project.org/
>
> Thoughts?
>
> --
> -------------------------------------------------------------------------
> MzK
>
> "There's a bit of magic in everything,
> and some loss to even things out."
> -- Lou Reed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think the licensing situation is very clear.
There are two licensing arrangements.
The free license is standard GPL3/LGPL3.
There is a commercial license for proprietary, closed source work. That license has to be purchased and there are flavors of it, such as Indie Mobile, Professional, Enterprise, Device Creation, Cloud Services, etc. These do not qualify as open-source licenses.
Here's the fee structure along with the license flavors: <http://www.qt.io/download/>.
- Dennis
PS: I thought there was a LGPL case where you could run QT as a DLL underneath an application, but I don't see how that can work with an ASF Project for a number of reasons. I also don't see anything about that featured in the current materials (although Wikipedia points to the Digia QT LGPL Exception, which is at the bottom of this page:
<http://doc.qt.io/qt-5/lgpl.html#digia-qt-lgpl-exception-version-1-1>.
Some of the gyrations may be related to how QT was spun into and out of Nokia. According to my email archives, I apparently stopped paying attention to it at the end of 2011. I may also may be thinking of a different project with regard to using a pre-built DLL and LIB.
-----Original Message-----
From: Kay Schenk [mailto:kay.schenk@gmail.com]
Sent: Tuesday, January 13, 2015 15:46
To: OOo Apache
Subject: [DISCUSS] Qt as a replacement for VCL
Something I started thinking about and ta da...it's been proposed before --
http://markmail.org/message/gjvwudqnzejlzynz
In my mind, we could use some assistance in the maintenance of the
toolkit for our UI instead of continuing to do it ourselves. This said,
I know next to nothing about QT and from what I've seen, the licensing
is pretty complicated and might not work for the ASF --
http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
Main web site -- http://qt-project.org/
Thoughts?
--
-------------------------------------------------------------------------
MzK
"There's a bit of magic in everything,
and some loss to even things out."
-- Lou Reed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Rory O'Farrell <of...@iol.ie>.
On Wed, 14 Jan 2015 13:21:24 -0500
Louis Suárez-Potts <lu...@gmail.com> wrote:
>
> > On 14 Jan 2015, at 12:46, Rory O'Farrell <of...@iol.ie> wrote:
> >
> > On Wed, 14 Jan 2015 09:27:53 -0800
> > "Dennis E. Hamilton" <de...@acm.org> wrote:
> >
> >> Maintaining the independently-developed VCL GUI framework is an
> >> important concern. (Then there's UNO as a cross-platform COM
> >> derivative.)
> >>
> >> The problem with much of the complexity of AOO, it seems to me,
> >> is that it is difficult to find improvements that can be
> >> achieved with progressions of small changes that have every-
> >> think still working each step of the way. Combined with the
> >> level of expertise required to know what changes are safe
> >> and consistent with the architecture of AOO, there is a big
> >> challenge for identifying any major moves.
> >>
> >> It would be great to know what insights there are for
> >> cultivating and sustaining the necessary expertise and
> >> maybe simplifying the learning curve and entrance
> >> requirements. Maybe just keep doing more of what is
> >> already being done in this area?
> >>
> >
> > Changing a GUI framework as discussed here is a major task - fraught with difficulty and hidden "gotchas". It would be better to put the effort going into two areas: bug-fixing - there are many little bugs to be fixed; secondly, improvement in the functionality. Here is not the place to start a debate on what needs to be changed/improved, but we should bear in mind that "bells and whistles" always attract users. If we let competitive products outdistance us, we lose our share of the user base.
>
> What “competitive products” do you mean? LibreOffice? Microsoft Office?
>
> Or perhaps you mean Calligra, which actually went through an intense refactoring (successful, too) several years ago. (Calligra is nice, but does not work with Mac OS X very well at all and is not maintained. Plans exist, but I get the feeling it’s like fusion power.)
I didn't want to be over specific, but you mention three I had in mind. I tried Caligra about a year ago and it blew up on my test document (an .odt file of a book in progress of some 100K+ words). It has one potential attractive feature for me - Caligra Author - but this seems largely stalled and redirected towards eBooks - I start out with print books and can easily make an eBook using Calibre, so I lost interest.
>
> More to the point, and trying to be realistic…. OpenOffice is right now on maintenance mode, as far as I can tell. We will issue a 4.1.2 and probably further micro releases addressing bugs, midges, and gnats. But we’re not slaying dragons nor otherwise attempting ambitious projects.
Running on (X)Ubuntu 14.10 OpenOffice is absolutely reliable (in my experience and for my purposes), but there are frequent reported problems on the Forum with Spellcheck (possibly almost always User finger trouble) and with Impress; in both of these cases (in)compatibility with MS file formats comes up regularly (without mentioning any of the .nnnx formats)..
>
And it’s not a matter of bells and whistles—of glitter to appeal to fools who can’t otherwise see the gold. It’s rather matter of creating a product that the millions who are going to be using open source productivity applications can actually use on the platforms and environments they are given or buy. These will continue to be desktops (including laptops) but also mobile devices. That is: the future is not like the past and to pretend it is and will continue to so seems to me problematical.
>
> Yet any transition is bound to demand resources we can’t pull out of thin air. Note, this has always been the argument for the status quo here. (It was also coupled to the one you raised, earlier.) This obdurance is one reason I helped establish the new project Corinthia, which is a new thing altogether. But I also still believe that OpenOffice has a future and that investigating ways in which we can make OpenOffice not only easier to work on but to use would serve us—the overall community—well.
>
> louis
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Louis Suárez-Potts <lu...@gmail.com>.
> On 14 Jan 2015, at 12:46, Rory O'Farrell <of...@iol.ie> wrote:
>
> On Wed, 14 Jan 2015 09:27:53 -0800
> "Dennis E. Hamilton" <de...@acm.org> wrote:
>
>> Maintaining the independently-developed VCL GUI framework is an
>> important concern. (Then there's UNO as a cross-platform COM
>> derivative.)
>>
>> The problem with much of the complexity of AOO, it seems to me,
>> is that it is difficult to find improvements that can be
>> achieved with progressions of small changes that have every-
>> think still working each step of the way. Combined with the
>> level of expertise required to know what changes are safe
>> and consistent with the architecture of AOO, there is a big
>> challenge for identifying any major moves.
>>
>> It would be great to know what insights there are for
>> cultivating and sustaining the necessary expertise and
>> maybe simplifying the learning curve and entrance
>> requirements. Maybe just keep doing more of what is
>> already being done in this area?
>>
>
> Changing a GUI framework as discussed here is a major task - fraught with difficulty and hidden "gotchas". It would be better to put the effort going into two areas: bug-fixing - there are many little bugs to be fixed; secondly, improvement in the functionality. Here is not the place to start a debate on what needs to be changed/improved, but we should bear in mind that "bells and whistles" always attract users. If we let competitive products outdistance us, we lose our share of the user base.
What “competitive products” do you mean? LibreOffice? Microsoft Office?
Or perhaps you mean Calligra, which actually went through an intense refactoring (successful, too) several years ago. (Calligra is nice, but does not work with Mac OS X very well at all and is not maintained. Plans exist, but I get the feeling it’s like fusion power.)
More to the point, and trying to be realistic…. OpenOffice is right now on maintenance mode, as far as I can tell. We will issue a 4.1.2 and probably further micro releases addressing bugs, midges, and gnats. But we’re not slaying dragons nor otherwise attempting ambitious projects. And it’s not a matter of bells and whistles—of glitter to appeal to fools who can’t otherwise see the gold. It’s rather matter of creating a product that the millions who are going to be using open source productivity applications can actually use on the platforms and environments they are given or buy. These will continue to be desktops (including laptops) but also mobile devices. That is: the future is not like the past and to pretend it is and will continue to so seems to me problematical.
Yet any transition is bound to demand resources we can’t pull out of thin air. Note, this has always been the argument for the status quo here. (It was also coupled to the one you raised, earlier.) This obdurance is one reason I helped establish the new project Corinthia, which is a new thing altogether. But I also still believe that OpenOffice has a future and that investigating ways in which we can make OpenOffice not only easier to work on but to use would serve us—the overall community—well.
louis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Fernando Cassia <fc...@gmail.com>.
On Wed, Jan 14, 2015 at 5:42 PM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:
> I resonate with these remarks (two extracts below). I particularly want
> to acknowledge all of the work that Kay Schenk and several others have put
> into making AOO more approachable by new developers.
Ideed, "Innovation" for change's sake leads to Microsoft's "Ribbon" UI that
(almost) everyone hated.
In other words, when it comes to GUI design, "if it ain't broken, don't fix
it".
just my $0.02
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
RE: [DISCUSS] Qt as a replacement for VCL
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I resonate with these remarks (two extracts below). I particularly want to acknowledge all of the work that Kay Schenk and several others have put into making AOO more approachable by new developers.
-- Extract #1 --
From: Kay Schenk [mailto:kay.schenk@gmail.com]
Sent: Wednesday, January 14, 2015 10:17
To: dev@openoffice.apache.org
Subject: Re: [DISCUSS] Qt as a replacement for VCL
[ ... ]
Ongoing maintenance and new developer knowledge are more a factor to me
than "bells and whistles", really.
[ ... ]
-----Original Message-----
From: Louis Suárez-Potts [mailto:luispo@gmail.com]
Sent: Wednesday, January 14, 2015 10:21
To: dev@openoffice.apache.org
Subject: Re: [DISCUSS] Qt as a replacement for VCL
[ ... ]
More to the point, and trying to be realistic…. OpenOffice is right now on maintenance mode, as far as I can tell. We will issue a 4.1.2 and probably further micro releases addressing bugs, midges, and gnats. But we’re not slaying dragons nor otherwise attempting ambitious projects. And it’s not a matter of bells and whistles—of glitter to appeal to fools who can’t otherwise see the gold.
[It's a] matter of creating a product that the millions who are going to be using open source productivity applications can actually use on the platforms and environments they are given or buy. These will continue to be desktops (including laptops) but also mobile devices. That is: the future is not like the past and to pretend it is and will continue to so seems to me problematical.
Yet any transition is bound to demand resources we can’t pull out of thin air. [ ... ] But I also still believe that OpenOffice has a future and that investigating ways in which we can make OpenOffice not only easier to work on but to use would serve us—the overall community—well.
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Kay Schenk <ka...@gmail.com>.
On 01/14/2015 09:46 AM, Rory O'Farrell wrote:
> On Wed, 14 Jan 2015 09:27:53 -0800 "Dennis E. Hamilton"
> <de...@acm.org> wrote:
>
>> Maintaining the independently-developed VCL GUI framework is an
>> important concern. (Then there's UNO as a cross-platform COM
>> derivative.)
>>
>> The problem with much of the complexity of AOO, it seems to me, is
>> that it is difficult to find improvements that can be achieved with
>> progressions of small changes that have every- think still working
>> each step of the way. Combined with the level of expertise required
>> to know what changes are safe and consistent with the architecture
>> of AOO, there is a big challenge for identifying any major moves.
>>
>> It would be great to know what insights there are for cultivating
>> and sustaining the necessary expertise and maybe simplifying the
>> learning curve and entrance requirements. Maybe just keep doing
>> more of what is already being done in this area?
>>
>
> Changing a GUI framework as discussed here is a major task - fraught
> with difficulty and hidden "gotchas". It would be better to put the
> effort going into two areas: bug-fixing - there are many little bugs
> to be fixed; secondly, improvement in the functionality. Here is not
> the place to start a debate on what needs to be changed/improved, but
> we should bear in mind that "bells and whistles" always attract
> users. If we let competitive products outdistance us, we lose our
> share of the userbase.
Thanks for all the comments so far. Further thoughts --
* Given licensing conditions of Qt, I was hoping it could be handled as
our other category-b licenses. This would depend on what libraries are
used of course.
* Yes, a daunting task which is why it hasn't already been done.
* I was initially thinking that a migration like this would:
-- free up developer time to concentrate on other aspects of AOO
-- relieve developers from continual maintenance in graphical environments
-- position AOO better for use on non-desktop platforms
Rory's comments --
" Here is not
> the place to start a debate on what needs to be changed/improved, but
> we should bear in mind that "bells and whistles" always attract
> users.
Ongoing maintenance and new developer knowledge are more a factor to me
than "bells and whistles", really.
"If we let competitive products outdistance us, we lose our
> share of the userbase"
No argument there.
>
>
>>
>> -- replying below to --
>>> From: Kay Schenk [mailto:kay.schenk@gmail.com]
>> Sent: Tuesday, January 13, 2015 15:46 To: OOo Apache Subject:
>> [DISCUSS] Qt as a replacement for VCL
>>
>> Something I started thinking about and ta da...it's been proposed
>> before --
>>
>> http://markmail.org/message/gjvwudqnzejlzynz
>>
>> In my mind, we could use some assistance in the maintenance of the
>> toolkit for our UI instead of continuing to do it ourselves. This
>> said, I know next to nothing about QT and from what I've seen, the
>> licensing is pretty complicated and might not work for the ASF --
>>
>> http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
>>
>> <orcmid> I finally noticed and followed the markmail link above.
>> Of course, in January 2009, all of OpenOffice.org was under LGPL
>> and the license was not a concern for the open-source side of
>> things. The private commercial licensing of OO.o by Sun (e.g., to
>> IBM) would have been a concern. The dependency on what continued to
>> be a pretty closely-held project might have been a concern even
>> then. If The Document Foundation had decided this was a good idea,
>> the prospect of an ecumenical accommodation with LibreOffice would
>> be even stranger today than it already is [;<). </orcmid>
>>
>> Main web site -- http://qt-project.org/
>>
>> Thoughts?
>>
>> --
>> -------------------------------------------------------------------------
>>
>>
MzK
>>
>> "There's a bit of magic in everything, and some loss to even things
>> out." -- Lou Reed
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
--
-------------------------------------------------------------------------
MzK
"There's a bit of magic in everything,
and some loss to even things out."
-- Lou Reed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Rory O'Farrell <of...@iol.ie>.
On Wed, 14 Jan 2015 09:27:53 -0800
"Dennis E. Hamilton" <de...@acm.org> wrote:
> Maintaining the independently-developed VCL GUI framework is an
> important concern. (Then there's UNO as a cross-platform COM
> derivative.)
>
> The problem with much of the complexity of AOO, it seems to me,
> is that it is difficult to find improvements that can be
> achieved with progressions of small changes that have every-
> think still working each step of the way. Combined with the
> level of expertise required to know what changes are safe
> and consistent with the architecture of AOO, there is a big
> challenge for identifying any major moves.
>
> It would be great to know what insights there are for
> cultivating and sustaining the necessary expertise and
> maybe simplifying the learning curve and entrance
> requirements. Maybe just keep doing more of what is
> already being done in this area?
>
Changing a GUI framework as discussed here is a major task - fraught with difficulty and hidden "gotchas". It would be better to put the effort going into two areas: bug-fixing - there are many little bugs to be fixed; secondly, improvement in the functionality. Here is not the place to start a debate on what needs to be changed/improved, but we should bear in mind that "bells and whistles" always attract users. If we let competitive products outdistance us, we lose our share of the userbase.
>
> -- replying below to --
> >From: Kay Schenk [mailto:kay.schenk@gmail.com]
> Sent: Tuesday, January 13, 2015 15:46
> To: OOo Apache
> Subject: [DISCUSS] Qt as a replacement for VCL
>
> Something I started thinking about and ta da...it's been proposed before --
>
> http://markmail.org/message/gjvwudqnzejlzynz
>
> In my mind, we could use some assistance in the maintenance of the
> toolkit for our UI instead of continuing to do it ourselves. This said,
> I know next to nothing about QT and from what I've seen, the licensing
> is pretty complicated and might not work for the ASF --
>
> http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
>
> <orcmid>
> I finally noticed and followed the markmail link above. Of course,
> in January 2009, all of OpenOffice.org was under LGPL and the license
> was not a concern for the open-source side of things. The private
> commercial licensing of OO.o by Sun (e.g., to IBM) would have been a
> concern.
> The dependency on what continued to be a pretty closely-held project
> might have been a concern even then.
> If The Document Foundation had decided this was a good idea, the
> prospect of an ecumenical accommodation with LibreOffice would be even
> stranger today than it already is [;<).
> </orcmid>
>
> Main web site -- http://qt-project.org/
>
> Thoughts?
>
> --
> -------------------------------------------------------------------------
> MzK
>
> "There's a bit of magic in everything,
> and some loss to even things out."
> -- Lou Reed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think these proposals are interesting as food for thought ...
-- replying below to --
From: Fernando Cassia [mailto:fcassia@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.hamilton@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Fernando Cassia <fc...@gmail.com>.
On Wed, Jan 14, 2015 at 2:27 PM, Dennis E. Hamilton <dennis.hamilton@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.
1b Doing the same for UNO
#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..
#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/
Food for thought, thinking aloud.
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
RE: [DISCUSS] Qt as a replacement for VCL
Posted by Alexandro Colorado <jz...@oooes.org>.
In 2007 Nokia people were interested in taking this, they were pushing
mobile technology and having an office suite in Qt with the brand awareness
of OpenOffice.Org was a competitive advantage for their platform. I always
offer an open venue to get their sentiment relayed to some core sun
developers, however never really got a
real push on the ML. I would have loved to really see the deep technical
details between VCL and Qt's widgets.
On Jan 14, 2015 11:28 AM, "Dennis E. Hamilton" <de...@acm.org>
wrote:
> Maintaining the independently-developed VCL GUI framework is an
> important concern. (Then there's UNO as a cross-platform COM
> derivative.)
>
> The problem with much of the complexity of AOO, it seems to me,
> is that it is difficult to find improvements that can be
> achieved with progressions of small changes that have every-
> think still working each step of the way. Combined with the
> level of expertise required to know what changes are safe
> and consistent with the architecture of AOO, there is a big
> challenge for identifying any major moves.
>
> It would be great to know what insights there are for
> cultivating and sustaining the necessary expertise and
> maybe simplifying the learning curve and entrance
> requirements. Maybe just keep doing more of what is
> already being done in this area?
>
>
> -- replying below to --
> From: Kay Schenk [mailto:kay.schenk@gmail.com]
> Sent: Tuesday, January 13, 2015 15:46
> To: OOo Apache
> Subject: [DISCUSS] Qt as a replacement for VCL
>
> Something I started thinking about and ta da...it's been proposed before --
>
> http://markmail.org/message/gjvwudqnzejlzynz
>
> In my mind, we could use some assistance in the maintenance of the
> toolkit for our UI instead of continuing to do it ourselves. This said,
> I know next to nothing about QT and from what I've seen, the licensing
> is pretty complicated and might not work for the ASF --
>
> http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
>
> <orcmid>
> I finally noticed and followed the markmail link above. Of course,
> in January 2009, all of OpenOffice.org was under LGPL and the license
> was not a concern for the open-source side of things. The private
> commercial licensing of OO.o by Sun (e.g., to IBM) would have been a
> concern.
> The dependency on what continued to be a pretty closely-held project
> might have been a concern even then.
> If The Document Foundation had decided this was a good idea, the
> prospect of an ecumenical accommodation with LibreOffice would be even
> stranger today than it already is [;<).
> </orcmid>
>
> Main web site -- http://qt-project.org/
>
> Thoughts?
>
> --
> -------------------------------------------------------------------------
> MzK
>
> "There's a bit of magic in everything,
> and some loss to even things out."
> -- Lou Reed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
RE: [DISCUSS] Qt as a replacement for VCL
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Maintaining the independently-developed VCL GUI framework is an
important concern. (Then there's UNO as a cross-platform COM
derivative.)
The problem with much of the complexity of AOO, it seems to me,
is that it is difficult to find improvements that can be
achieved with progressions of small changes that have every-
think still working each step of the way. Combined with the
level of expertise required to know what changes are safe
and consistent with the architecture of AOO, there is a big
challenge for identifying any major moves.
It would be great to know what insights there are for
cultivating and sustaining the necessary expertise and
maybe simplifying the learning curve and entrance
requirements. Maybe just keep doing more of what is
already being done in this area?
-- replying below to --
From: Kay Schenk [mailto:kay.schenk@gmail.com]
Sent: Tuesday, January 13, 2015 15:46
To: OOo Apache
Subject: [DISCUSS] Qt as a replacement for VCL
Something I started thinking about and ta da...it's been proposed before --
http://markmail.org/message/gjvwudqnzejlzynz
In my mind, we could use some assistance in the maintenance of the
toolkit for our UI instead of continuing to do it ourselves. This said,
I know next to nothing about QT and from what I've seen, the licensing
is pretty complicated and might not work for the ASF --
http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
<orcmid>
I finally noticed and followed the markmail link above. Of course,
in January 2009, all of OpenOffice.org was under LGPL and the license
was not a concern for the open-source side of things. The private
commercial licensing of OO.o by Sun (e.g., to IBM) would have been a
concern.
The dependency on what continued to be a pretty closely-held project
might have been a concern even then.
If The Document Foundation had decided this was a good idea, the
prospect of an ecumenical accommodation with LibreOffice would be even
stranger today than it already is [;<).
</orcmid>
Main web site -- http://qt-project.org/
Thoughts?
--
-------------------------------------------------------------------------
MzK
"There's a bit of magic in everything,
and some loss to even things out."
-- Lou Reed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Fernando Cassia <fc...@gmail.com>.
On Wed, Jan 14, 2015 at 1:45 AM, Fernando Cassia <fc...@gmail.com> wrote:
> oweted
I intended to write "ported"
FC
Re: [DISCUSS] Qt as a replacement for VCL
Posted by Fernando Cassia <fc...@gmail.com>.
On Tue, Jan 13, 2015 at 8:57 PM, jan i <ja...@apache.org> wrote:
>
> I have been working with Qt for many years and have in one project made a
> converter from something similar to our UI descriptions to a Qt
> environment.
I have only experience as an end user of poweted QT apps to the windows
platform, and I can say: avoid it like the plague.
QT apps on Windows tend to become hugue, the bloat added by QT libs is
considerable and plus, the QT apps ported to windows are SLOW TO LOAD.
The size of all the QT libs loading before the app can even be displayed
surely plays a role.
Just my $0.02
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell
Re: [DISCUSS] Qt as a replacement for VCL
Posted by jan i <ja...@apache.org>.
On Wednesday, January 14, 2015, Kay Schenk <ka...@gmail.com> wrote:
> Something I started thinking about and ta da...it's been proposed before --
>
> http://markmail.org/message/gjvwudqnzejlzynz
>
> In my mind, we could use some assistance in the maintenance of the
> toolkit for our UI instead of continuing to do it ourselves. This said,
> I know next to nothing about QT and from what I've seen, the licensing
> is pretty complicated and might not work for the ASF --
I have been working with Qt for many years and have in one project made a
converter from something similar to our UI descriptions to a Qt environment.
I can only recommend such a step.
As a side remark, translations will become a factor easier, because the
are stored in their own fileset, meaning we only need to compile once for
all languages.
rgds
jan i
>
> http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt
>
> Main web site -- http://qt-project.org/
>
> Thoughts?
>
> --
> -------------------------------------------------------------------------
> MzK
>
> "There's a bit of magic in everything,
> and some loss to even things out."
> -- Lou Reed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> <javascript:;>
> For additional commands, e-mail: dev-help@openoffice.apache.org
> <javascript:;>
>
>
--
Sent from My iPad, sorry for any misspellings.