Re: [DISCUSS] Qt as a replacement for VCL
On Mon, Jul 6, 2015 at 7:49 AM, Malte Timmermann malte_timmerm...@gmx.com wrote: This approach would mean that you mostly don't use Qt at all. VCL uses SAL to get a top level window from the os, and then renders all widgets on it's own. Using Qt simply as yet an other SAL implementation would mean that you still only get the top level window (via Qt then), but widget rendering wouldn't change. Really using Qt would probably be a quite huge effort. Malte. Yes, to redo using Qt well basically natively would be a huge effort, and this is what I was thinking when I suggested this. I think we already basically have a SAL (VCL)-Qt bridge anyway if you configure with using KDE. (Well this might be a bridge based on KDE3 rather than 4+). We don't use this now but might have before. On 18.01.2015 19:41, Fernando Cassia wrote: On Sun, Jan 18, 2015 at 12:43 PM, Yuri Dario mc6...@mclink.it wrote: having written or updated most of the OS/2 code in VCL project, I have some experience with it. I'm not enterint the debate QT-yes/QT-no, I will only offer a developer point of view. We can simply use QT like an existing operanting system API, like OS/2 PM or windows GDI/windowing. As we create a window using the os native api, we can also create a window using QT API. Same for drawing, printing, etc... So, what you suggest is actually a VCL-to-QT bridge. If that is actually doable, technically speaking, that sounds like a good FOSS project to start on its own. Don´t restrict it to the realm of AOO, make it a separate endeavour then it can be used in AOO. Just saying... don´t restrict the mindshare and reach of the project to AOO, make it as wide and far-reaching as possible. FC - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK We can all sleep easy at night knowing that somewhere at any given time, the Foo Fighters are out there fighting Foo. -- David Letterman
Re: [DISCUSS] Qt as a replacement for VCL
This approach would mean that you mostly don't use Qt at all. VCL uses SAL to get a top level window from the os, and then renders all widgets on it's own. Using Qt simply as yet an other SAL implementation would mean that you still only get the top level window (via Qt then), but widget rendering wouldn't change. Really using Qt would probably be a quite huge effort. Malte. On 18.01.2015 19:41, Fernando Cassia wrote: On Sun, Jan 18, 2015 at 12:43 PM, Yuri Dario mc6...@mclink.it wrote: having written or updated most of the OS/2 code in VCL project, I have some experience with it. I'm not enterint the debate QT-yes/QT-no, I will only offer a developer point of view. We can simply use QT like an existing operanting system API, like OS/2 PM or windows GDI/windowing. As we create a window using the os native api, we can also create a window using QT API. Same for drawing, printing, etc... So, what you suggest is actually a VCL-to-QT bridge. If that is actually doable, technically speaking, that sounds like a good FOSS project to start on its own. Don´t restrict it to the realm of AOO, make it a separate endeavour then it can be used in AOO. Just saying... don´t restrict the mindshare and reach of the project to AOO, make it as wide and far-reaching as possible. FC - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
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
Re: [DISCUSS] Qt as a replacement for VCL
On 26 Jan 2015, at 03:42, Fernando Cassia fcas...@gmail.com wrote: On Sun, Jan 25, 2015 at 8:16 PM, Louis Suárez-Potts lui...@gmail.com wrote: * One conceivable drawback is that Kivy also uses Kivy Language, for creating sophisticated user interfaces[,] though it does not seem to be required for creating naive UIs. Kivy is in Python and their conference presentations seem to be mostly at PyCons. One might wonder about the use of Python for something claiming speed as a virtue. Ouch. FC :-) They get around the speed issue associated with a language like Python by pointing out that nearly all graphical tasks invoked by the script won’t be managed by it, but actually, via Cython, via the C compiler; and also by the GPU, which they task. I think that part is good and promising. louis - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Sun, Jan 25, 2015 at 8:16 PM, Louis Suárez-Potts lui...@gmail.com wrote: * One conceivable drawback is that Kivy also uses Kivy Language, for creating sophisticated user interfaces[,] though it does not seem to be required for creating naive UIs. Kivy is in Python and their conference presentations seem to be mostly at PyCons. One might wonder about the use of Python for something claiming speed as a virtue. Ouch. FC
Re: [DISCUSS] Qt as a replacement for VCL
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. -- - MzK An old horse for a long, hard road, a young pony for a quick ride. -- Texas Bix Bender - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Dennis, On 22 Jan 2015, at 23:05, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I just ran into a great little project, Kivy. I am not making a serious proposal about a GUI framework, although Kivy is interesting in that regard. What I find more appealing is the project organization and the quality of the documentation. The project repository is on GitHub, of course: https://github.com/kivy/kivy. To get some sense of it I looked into the doc/ folder there. First impression: All open-source documentation should be this good. Go here: http://kivy.org/docs/. Try out the architectural overview that is mentioned in the introduction. The next page on the events and properties has a juicy diagram too. I have no idea how or whether this is similar to VCL. I'm just admiring Kivy with no particular context in mind. Thanks for pointing us to this project. (Actually, thanks, too, at least from me, and very sincerely—a phrase that normally suggests its obverse—for posting your rumination on AOO in the world, which I'll be not-quite-savaging shortly. Actually, not savaging it at all. :-) ) A few points on this Kivy…. * What it is, from GitHub: quote Innovative User Interfaces Made Easy. Kivy is a Python framework for the development of multi-touch enabled media rich applications. The aim is to allow for quick and easy interaction design and rapid prototyping whilst making your code reusable and deployable. Kivy is written in Python and Cython, based on OpenGL ES 2, supports various input devices and has an extensive widget library. With the same codebase, you can target Windows, OSX, Linux, Android and iOS. All our widgets are built with multitouch support. Kivy is MIT licensed, actively developed by a great community and is supported by many projects managed by the Kivy organisation. /quote * The docs are indeed remarkably good. But so is the architecture of the project and I must assume the code itself that does things. There are several good things in Kivy that I wish we had more clearly laid out on OpenOffice. These include philosophy, architecture, and other useful abstractions. In addition to the docs page you cite, there’s also O’Reilly; see: http://shop.oreilly.com/product/9781783281596.do * I’m particularly taken with the philosophy page (http://kivy.org/docs/philosophy.html#philosophy), as it explains the raison d’être of the project. And it’s not just marketing churn. (A similar, persuasive claim is made with the Meteor project, in its assertion of utility over Angular JS, which remains overwhelmingly popular.) * I can’t weigh in on whether it would be a good replacement for VCL or even an alternative. The claims made by Kivy, however, suggest that its use would open opportunities. * One conceivable drawback is that Kivy also uses Kivy Language, for creating sophisticated user interfaces[,] though it does not seem to be required for creating naive UIs. Kivy is in Python and their conference presentations seem to be mostly at PyCons. One might wonder about the use of Python for something claiming speed as a virtue. They answer that worry in their Project FAQ. See http://kivy.org/docs/faq.html#why-do-you-use-python-isn-t-it-slow * Kivy is still new. It doesn’t seem to have a Wikipedia entry (Ye Gods!)—nor does it seem to have a separate foundation supporting activity; Google Groups and GitHub seem to do the job. There also does not seem to be any major sponsor. Actually, from these points one could draw the line suggesting a nearly perfect open source project, at least in the international, direct-democratic/meritocratic and kind of friendly sense. But nothing this side of the Eden is perfect, so I’m probably missing something. :-) * Did you contact the Kivy Project? The website is at http://kivy.org/#home . * Finally, one thing I discovered earlier was that fun projects that could be useful but need not be are excellent ways to include more contributors. Cheers, louis - Dennis -Original Message- From: Louis Suárez-Potts [mailto:lui...@gmail.com] Sent: Tuesday, January 20, 2015 11:54 To: dev@openoffice.apache.org; Dennis E. Hamilton Subject: Re: [DISCUSS] Qt as a replacement for VCL [ ... ] orcmid I'm just using this to stay on the thread. /orcmid - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
I just ran into a great little project, Kivy. I am not making a serious proposal about a GUI framework, although Kivy is interesting in that regard. What I find more appealing is the project organization and the quality of the documentation. The project repository is on GitHub, of course: https://github.com/kivy/kivy. To get some sense of it I looked into the doc/ folder there. First impression: All open-source documentation should be this good. Go here: http://kivy.org/docs/. Try out the architectural overview that is mentioned in the introduction. The next page on the events and properties has a juicy diagram too. I have no idea how or whether this is similar to VCL. I'm just admiring Kivy with no particular context in mind. - Dennis -Original Message- From: Louis Suárez-Potts [mailto:lui...@gmail.com] Sent: Tuesday, January 20, 2015 11:54 To: dev@openoffice.apache.org; Dennis E. Hamilton Subject: Re: [DISCUSS] Qt as a replacement for VCL [ ... ] orcmid I'm just using this to stay on the thread. /orcmid - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
Hi, Have you looked at this enough to be satisfied the VCL maps to QT well enough for what AOO does? no, but since QT is a complete SDK for writing apps, I suppose it does everything AOO needs. So my question may be useless, and certainly based on ignorance: Is there any sort of lifecycle management that has to be handled between VCL and QT and will this be resolvable (using UNO or whatever for that purpose)? sorry, my QT experience is very limited. PS: Thanks for bringing your expertise with OS/2 on behalf of AOO too. thank you :-)) -- Bye, Yuri Dario - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Yuri, On 20 Jan 2015, at 09:55, Yuri Dario mc6...@mclink.it wrote: Hi, Have you looked at this enough to be satisfied the VCL maps to QT well enough for what AOO does? no, but since QT is a complete SDK for writing apps, I suppose it does everything AOO needs. So my question may be useless, and certainly based on ignorance: Is there any sort of lifecycle management that has to be handled between VCL and QT and will this be resolvable (using UNO or whatever for that purpose)? sorry, my QT experience is very limited. PS: Thanks for bringing your expertise with OS/2 on behalf of AOO too. thank you :-)) 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.) thanks louis -- Bye, Yuri Dario - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Hi, On 20 Jan 2015, at 12:53, Kay Schenk kay.sch...@gmail.com wrote: On 01/20/2015 07:05 AM, Louis Suárez-Potts wrote: Yuri, On 20 Jan 2015, at 09:55, Yuri Dario mc6...@mclink.it wrote: Hi, Have you looked at this enough to be satisfied the VCL maps to QT well enough for what AOO does? no, but since QT is a complete SDK for writing apps, I suppose it does everything AOO needs. So my question may be useless, and certainly based on ignorance: Is there any sort of lifecycle management that has to be handled between VCL and QT and will this be resolvable (using UNO or whatever for that purpose)? sorry, my QT experience is very limited. PS: Thanks for bringing your expertise with OS/2 on behalf of AOO too. thank you :-)) 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.) thanks louis The QT license info is here: http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt Quite a collection! Of these, for the QT core, I believe the BSD-style are acceptable to the ASF but, the MIT -- not! :( So...depending on what we used, we'd need to discuss with Apache Legal. Yes. I had gone over that page, too…. and it seemed inconclusive, ie, I'm not a lawyer. What we want to do… up to what developers want, no? Personally, I think if it makes sense to pursue this avenue, and it's also kind of interesting, and a challenge, and could also bring in other developers and contributors, then why not? This would especially be so if a Qt application (whatever that would mean in this context) could also then allow for a smooth transition between mobiles and desktops. (Corinthia is of course working on related technology, but from a different angle.) I think to move ahead on this we just… do it? And ask Apache legal for guidance? louis -- Bye, Yuri Dario - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On 01/20/2015 07:05 AM, Louis Suárez-Potts wrote: Yuri, On 20 Jan 2015, at 09:55, Yuri Dario mc6...@mclink.it wrote: Hi, Have you looked at this enough to be satisfied the VCL maps to QT well enough for what AOO does? no, but since QT is a complete SDK for writing apps, I suppose it does everything AOO needs. So my question may be useless, and certainly based on ignorance: Is there any sort of lifecycle management that has to be handled between VCL and QT and will this be resolvable (using UNO or whatever for that purpose)? sorry, my QT experience is very limited. PS: Thanks for bringing your expertise with OS/2 on behalf of AOO too. thank you :-)) 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.) thanks louis The QT license info is here: http://doc.qt.io/qt-5/licensing.html#licenses-used-in-qt Quite a collection! Of these, for the QT core, I believe the BSD-style are acceptable to the ASF but, the MIT -- not! :( So...depending on what we used, we'd need to discuss with Apache Legal. -- Bye, Yuri Dario - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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. 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On 20 Jan 2015, at 14:28, Dennis E. Hamilton dennis.hamil...@acm.org 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. 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. Yes. That was what I had in mind regarding Qt for extensions. Ie, for add on applications that essentially operated after AOO compiled. 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. That was my impression. I think there is an open question about sliding Qt under VCL as simply a platform adaptation. Exactly. 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. Okay. 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. I for one would suggest that those of us wanting to use WebKit for building interesting apps consider Corinthia ;-) Squirrel !;). /orcmid Thanks, Dennis Louis PS nothing stops one from building AOO on Qt *outside* of Apache, of course, but then why? (Besides driving the LO crowd crazy with confusion.) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On 01/18/2015 01:46 PM, Fernando Cassia wrote: On Sun, Jan 18, 2015 at 12:43 PM, Yuri Dario mc6...@mclink.it wrote: This will have the positive side effect of removing all platform code from VCL since OS/2, Windows, *unix have QT ports. This will add one more layer inside operations, since QT will map to underlyng native API, but I don't think this will hurt performances for modern computers. This would still not solve the issue of portability to mobile platforms, which JavaFX / OpenJFX with its CSS-based approach does. https://blogs.oracle.com/jfxprg/entry/ipack_the_ios_application_packager http://www.slideshare.net/steveonjava/openjfx-on-android-and-devices ...Just saying. In any case, the more approaches the better. I´d say all possible technical solutions should be explored and encouraged... and then see how far it´s possible to get with each. FC At supports mobile platforms. http://doc.qt.io/qt-5/supported-platforms.html No comment on feasibility. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Sun, Jan 18, 2015 at 12:43 PM, Yuri Dario mc6...@mclink.it wrote: having written or updated most of the OS/2 code in VCL project, I have some experience with it. I'm not enterint the debate QT-yes/QT-no, I will only offer a developer point of view. We can simply use QT like an existing operanting system API, like OS/2 PM or windows GDI/windowing. As we create a window using the os native api, we can also create a window using QT API. Same for drawing, printing, etc... So, what you suggest is actually a VCL-to-QT bridge. If that is actually doable, technically speaking, that sounds like a good FOSS project to start on its own. Don´t restrict it to the realm of AOO, make it a separate endeavour then it can be used in AOO. Just saying... don´t restrict the mindshare and reach of the project to AOO, make it as wide and far-reaching as possible. FC
RE: [DISCUSS] Qt as a replacement for VCL
Yuri, That is an useful perspective. Have you looked at this enough to be satisfied the VCL maps to QT well enough for what AOO does? I have shied away from QT (and VCL which I suppose I can't avoid eventually) because I would not adopt it myself. So my question may be useless, and certainly based on ignorance: Is there any sort of lifecycle management that has to be handled between VCL and QT and will this be resolvable (using UNO or whatever for that purpose)? - Dennis PS: Thanks for bringing your expertise with OS/2 on behalf of AOO too. -Original Message- From: Yuri Dario [mailto:mc6...@mclink.it] Sent: Sunday, January 18, 2015 07:43 To: dev@openoffice.apache.org Subject: Re: [DISCUSS] Qt as a replacement for VCL Hi, having written or updated most of the OS/2 code in VCL project, I have some experience with it. I'm not enterint the debate QT-yes/QT-no, I will only offer a developer point of view. We can simply use QT like an existing operanting system API, like OS/2 PM or windows GDI/windowing. As we create a window using the os native api, we can also create a window using QT API. Same for drawing, printing, etc... This way will not expose QT API to upper levels, they will still use VCL approach, so you don't need to touch UNO or other components. This will have the positive side effect of removing all platform code from VCL since OS/2, Windows, *unix have QT ports. This will add one more layer inside operations, since QT will map to underlyng native API, but I don't think this will hurt performances for modern computers. But will give AOO a single approach to windowing for all platforms, making it easier to update and maintain on all platforms. It will be still possible to retain current native-VCL approach if platforms developers wants. just my 2 cents. -- Bye, Yuri Dario - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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
Re: [OT] RE: [DISCUSS] Qt as a replacement for VCL
On Thu, Jan 15, 2015 at 2:05 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The sales success of Microsoft Office and Office 365 suggest that (almost) everyone is inaccurate IMHO for me this is not (and has never been) an valid argument. People Buy MS Office because: 1. they have tons of documents written in Microsoft's file formats, 2. because only Microsoft Office guarantees file read/write compatibility with MS Office documents 3. because they were trained in MS Office and 90% of the tutorials you find on the web are about how to do [x] in MS Office, not LO, and not AOO 4. Because it's the standard and the business/organization has been buying MS Office since the beginning of (IT) times... So, basically, it's all about leverage and vendor lock-in. I haven't met a single MS Office user who rushed to the store to buy MS Office licenses because of the lovely Ribbon UI... Of course, 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
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. 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
[OT] RE: [DISCUSS] Qt as a replacement for VCL
The sales success of Microsoft Office and Office 365 suggest that (almost) everyone is inaccurate. It may be that those who don't like anything about Office since 2003 or 2007 switch to an OpenOffice version, or the switch is for other reasons entirely (such as expense). As usual when changes like this occur, just as for Windows 10 versus Windows 8, there is tuning and tweaking but the main idea survives. I find that I have adjusted just fine to the ribbon in all its form on current Windows systems. I have found the Windows 8.1 Start Page (and my ability to manage and organize what is on it) so appealing that I set Windows 10 to use it instead of the W10 Start Button, really not a return to the Windows 7 one (although I am certain Microsoft is not done perfecting the new Start Button). So I happily train myself to the OpenOffice GUI and the Microsoft Office GUI and have no problem with either of them. There are hard-to-find items either way and everyone's Help system is frustrating [;). - Dennis -Original Message- From: Fernando Cassia [mailto:fcas...@gmail.com] Sent: Thursday, January 15, 2015 08:30 To: dev@openoffice.apache.org; Dennis Hamilton Subject: Re: [DISCUSS] Qt as a replacement for VCL On Wed, Jan 14, 2015 at 5:42 PM, Dennis E. Hamilton dennis.hamil...@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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Wed, Jan 14, 2015 at 5:42 PM, Dennis E. Hamilton dennis.hamil...@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: [OT] RE: [DISCUSS] Qt as a replacement for VCL
So everyone hates Microsoft Office, but they use it anyhow. How about something a bit more evidence based? There are now many users who have never seen a version of Office without the ribbon. The availability of training and of lots of information on the Internet matters. It is true that Microsoft has a network effect working for it. That's a reality that is unlikely to disappear any time soon and it has to figure into whatever AOO wants to achieve in those areas that are important for take-up, especially in civil administration and other institutional areas apart from enterprise applications. For me, that means interoperability at the format interchange level is crucial. UI familiarity is a factor, but UI preferences are meaningless if the documents don't work and workers don't have the resources to have the documents work. And by now, the ribbon is established as part of the ready-to-hand familiarity that workers have in operating with Microsoft Office. I don't see any meaningful way for AOO to overtake that in terms of worker mind share. People didn't rush to the store to by Microsoft Word 6.0 because of the UI layout either. And I don't think anyone is rushing to use even a free Word 6.0 (or Word 2000) work-alike because of the UI either. - Dennis -Original Message- From: Fernando Cassia [mailto:fcas...@gmail.com] Sent: Thursday, January 15, 2015 09:24 To: dev@openoffice.apache.org; Dennis Hamilton Subject: Re: [OT] RE: [DISCUSS] Qt as a replacement for VCL On Thu, Jan 15, 2015 at 2:05 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The sales success of Microsoft Office and Office 365 suggest that (almost) everyone is inaccurate IMHO for me this is not (and has never been) an valid argument. People Buy MS Office because: 1. they have tons of documents written in Microsoft's file formats, 2. because only Microsoft Office guarantees file read/write compatibility with MS Office documents 3. because they were trained in MS Office and 90% of the tutorials you find on the web are about how to do [x] in MS Office, not LO, and not AOO 4. Because it's the standard and the business/organization has been buying MS Office since the beginning of (IT) times... So, basically, it's all about leverage and vendor lock-in. I haven't met a single MS Office user who rushed to the store to buy MS Office licenses because of the lovely Ribbon UI... Of course, 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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 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.) 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.sch...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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.sch...@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:lui...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
Hi; Replacing VCL with Qt (or GTK or enlightenment or anything) is a very complex project. There is a KDE CWS which may be somewhat of a starting point but it dowsn't really touch the surface of what you want to do. This said, it is the type of revolutionary projects I would certainly encourage. Feel free to start a branch for it :). Pedro. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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:lui...@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 dennis.hamil...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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.sch...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On 14 Jan 2015, at 12:27, Dennis E. Hamilton dennis.hamil...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Wed, 14 Jan 2015 09:27:53 -0800 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.) 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.sch...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On 01/14/2015 09:46 AM, Rory O'Farrell wrote: On Wed, 14 Jan 2015 09:27:53 -0800 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.) 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.sch...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On 14 Jan 2015, at 12:46, Rory O'Farrell ofarr...@iol.ie wrote: On Wed, 14 Jan 2015 09:27:53 -0800 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.) 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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Wed, 14 Jan 2015 13:21:24 -0500 Louis Suárez-Potts lui...@gmail.com wrote: On 14 Jan 2015, at 12:46, Rory O'Farrell ofarr...@iol.ie wrote: On Wed, 14 Jan 2015 09:27:53 -0800 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.) 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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Wed, Jan 14, 2015 at 1:45 AM, Fernando Cassia fcas...@gmail.com wrote: oweted I intended to write ported FC
Re: [DISCUSS] Qt as a replacement for VCL
On Tue, Jan 13, 2015 at 8:57 PM, jan i j...@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
On 13 Jan 2015, at 23:04, Dennis E. Hamilton dennis.hamil...@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.sch...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [DISCUSS] Qt as a replacement for VCL
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.sch...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS] Qt as a replacement for VCL
On Wednesday, January 14, 2015, Kay Schenk kay.sch...@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-unsubscr...@openoffice.apache.org javascript:; For additional commands, e-mail: dev-h...@openoffice.apache.org javascript:; -- Sent from My iPad, sorry for any misspellings.
