You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/07/26 12:16:56 UTC
Is Qt the right choice ??
Hi
I am currently updating the cmake files to cover e.g. the editor and see
some problems.
I know we decided to use Qt, but I would like to take the discussion again.
If we use Qt the editor will never be a released product, it will remain an
optional product, and
I think we will want to position the editor as a main feature of corinthia.
There is an alternative to Qt, which is a little more work but not much. If
we look at how peter
currently uses Qtwebkit it is pretty simple and static.
Webkit is builtin on OS-X, therefore we can use it, without thinking too
long about the licenses
(we do not ask people to download extra libraries, so it is at the same
level that we also depend on windows sdk-api).
We cannot use webkit on windows because it is LGPL (same as Qt), but we can
use mshtml or IWebBrowser2. My idea is to make a simple set of wrapper
functions, so that
the editor as such does not see the difference. That would allow us
to have the editor as a main feature.
thoughts ?
rgds
jan i.
Re: Is Qt the right choice ??
Posted by Dave Fisher <da...@comcast.net>.
Sure. My point is that we can continue with your plan from the other thread as long as we have options for the users of the project.
Sent from my iPhone
> On Jul 30, 2015, at 12:34 AM, jan i <ja...@apache.org> wrote:
>
>> On Thursday, July 30, 2015, Dave Fisher <da...@comcast.net> wrote:
>>
>> One already went through incubation after being donated by Adobe. It is
>> now called Apache Flex.
>>
>> Could be an option...
>
> Flex is a flash application, and I cannot see any C bindings nor the
> possibility to run our JS code.
>
> I will ask one I know from the project and come back because it could be a
> option.
>
>
> Thanks
> rgds
> jan i
>
>>
>> Sent from my iPhone
>>
>> On Jul 27, 2015, at 8:09 PM, Peter Kelly <pmkelly@apache.org
>> <javascript:;>> wrote:
>>
>>>> On 28 Jul 2015, at 2:00 am, jan i <jani@apache.org <javascript:;>>
>> wrote:
>>>>
>>>>> On 27 July 2015 at 20:33, Peter Kelly <pmkelly@apache.org
>> <javascript:;>> wrote:
>>>>>
>>>>> 1. Which UI toolkit is best for Apache project, and that other projects
>>>>> are already using? I had a brief look around at lists of potential
>>>>> candidate UI toolkits but didn’t find anything that was both good
>>>>> quality/mature and with a friendly license. But I’ve quite possibly
>> missed
>>>>> something. Are there other ASF project that provide a desktop app (and
>>>>> aren’t in Java) that we can learn from and take a similar path to them?
>>>> I have searched for quite sometime also because AOO thought about
>> changing,
>>>> and did not find a better multiplatform library.
>>>
>>> Would such a cross-platform UI toolkit, Apache licensed, be a good
>> candidate for an incubator project?
>>>
>>> It seems to me that this would be useful for a number of Apache projects
>> (such as OO), and thus it should be possible to attract enough interest
>> from potential contributors.
>>>
>>> —
>>> Dr Peter M. Kelly
>>> pmkelly@apache.org <javascript:;>
>>>
>>> PGP key: http://www.kellypmk.net/pgp-key <
>> http://www.kellypmk.net/pgp-key>
>>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
> --
> Sent from My iPad, sorry for any misspellings.
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On Thursday, July 30, 2015, Dave Fisher <da...@comcast.net> wrote:
> One already went through incubation after being donated by Adobe. It is
> now called Apache Flex.
>
> Could be an option...
Flex is a flash application, and I cannot see any C bindings nor the
possibility to run our JS code.
I will ask one I know from the project and come back because it could be a
option.
Thanks
rgds
jan i
>
> Sent from my iPhone
>
> On Jul 27, 2015, at 8:09 PM, Peter Kelly <pmkelly@apache.org
> <javascript:;>> wrote:
>
> >> On 28 Jul 2015, at 2:00 am, jan i <jani@apache.org <javascript:;>>
> wrote:
> >>
> >>> On 27 July 2015 at 20:33, Peter Kelly <pmkelly@apache.org
> <javascript:;>> wrote:
> >>>
> >>> 1. Which UI toolkit is best for Apache project, and that other projects
> >>> are already using? I had a brief look around at lists of potential
> >>> candidate UI toolkits but didn’t find anything that was both good
> >>> quality/mature and with a friendly license. But I’ve quite possibly
> missed
> >>> something. Are there other ASF project that provide a desktop app (and
> >>> aren’t in Java) that we can learn from and take a similar path to them?
> >> I have searched for quite sometime also because AOO thought about
> changing,
> >> and did not find a better multiplatform library.
> >
> > Would such a cross-platform UI toolkit, Apache licensed, be a good
> candidate for an incubator project?
> >
> > It seems to me that this would be useful for a number of Apache projects
> (such as OO), and thus it should be possible to attract enough interest
> from potential contributors.
> >
> > —
> > Dr Peter M. Kelly
> > pmkelly@apache.org <javascript:;>
> >
> > PGP key: http://www.kellypmk.net/pgp-key <
> http://www.kellypmk.net/pgp-key>
> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> >
>
--
Sent from My iPad, sorry for any misspellings.
Re: Is Qt the right choice ??
Posted by Dave Fisher <da...@comcast.net>.
One already went through incubation after being donated by Adobe. It is now called Apache Flex.
Could be an option...
Sent from my iPhone
On Jul 27, 2015, at 8:09 PM, Peter Kelly <pm...@apache.org> wrote:
>> On 28 Jul 2015, at 2:00 am, jan i <ja...@apache.org> wrote:
>>
>>> On 27 July 2015 at 20:33, Peter Kelly <pm...@apache.org> wrote:
>>>
>>> 1. Which UI toolkit is best for Apache project, and that other projects
>>> are already using? I had a brief look around at lists of potential
>>> candidate UI toolkits but didn’t find anything that was both good
>>> quality/mature and with a friendly license. But I’ve quite possibly missed
>>> something. Are there other ASF project that provide a desktop app (and
>>> aren’t in Java) that we can learn from and take a similar path to them?
>> I have searched for quite sometime also because AOO thought about changing,
>> and did not find a better multiplatform library.
>
> Would such a cross-platform UI toolkit, Apache licensed, be a good candidate for an incubator project?
>
> It seems to me that this would be useful for a number of Apache projects (such as OO), and thus it should be possible to attract enough interest from potential contributors.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 28 Jul 2015, at 2:00 am, jan i <ja...@apache.org> wrote:
>
> On 27 July 2015 at 20:33, Peter Kelly <pm...@apache.org> wrote:
>
>> 1. Which UI toolkit is best for Apache project, and that other projects
>> are already using? I had a brief look around at lists of potential
>> candidate UI toolkits but didn’t find anything that was both good
>> quality/mature and with a friendly license. But I’ve quite possibly missed
>> something. Are there other ASF project that provide a desktop app (and
>> aren’t in Java) that we can learn from and take a similar path to them?
>>
> I have searched for quite sometime also because AOO thought about changing,
> and did not find a better multiplatform library.
Would such a cross-platform UI toolkit, Apache licensed, be a good candidate for an incubator project?
It seems to me that this would be useful for a number of Apache projects (such as OO), and thus it should be possible to attract enough interest from potential contributors.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 27 July 2015 at 20:33, Peter Kelly <pm...@apache.org> wrote:
> > On 27 Jul 2015, at 5:20 pm, jan i <ja...@apache.org> wrote:
> >
> > Hi Peter
> >
> > sorry for top posting, but I try to answer both of your mails in one.
> >
> > The licensing problem is a bit more complicated.
> >
> > Apache source is not allowed to depend on third party libraries that uses
> > e.g. LGPL if you
> > want to read details you can find it here:
> > http://www.apache.org/legal/resolved.html
> > disc
> > In general there are a number of loopholes:
> > - if the library is part of the OS we don´t care (think of Microsoft
> > SDK/MFC, OS-X core libraries and glibc), so webkit on OS-X is not a
> problem
> > - if the component is optional we don´t care in case of LGPL
>
> So much for open source/free software as an antidote to the “walled
> gardens” that Apple and the like are often criticised for. In FOSS we have
> walls of a different form dividing those who favour the GPL/LPL and similar
> licenses, and those who favour more liberal licenses like MIT/BSD/Apache,
> with the licenses limiting what would otherwise be beneficial code sharing
> :(
>
> I understand there are perfectly valid and well-considered reasons for the
> rules you’ve mentioned that have been reached as a result of consensus at
> Apache, and there’s little point in trying to argue against that. And we
> can certainly ship a Qt-based editor as an optional component. So really
> I’m interested in the practical steps we can take to come up with something
> that’s as useful as possible within these limitations.
>
> 1. Which UI toolkit is best for Apache project, and that other projects
> are already using? I had a brief look around at lists of potential
> candidate UI toolkits but didn’t find anything that was both good
> quality/mature and with a friendly license. But I’ve quite possibly missed
> something. Are there other ASF project that provide a desktop app (and
> aren’t in Java) that we can learn from and take a similar path to them?
>
I have searched for quite sometime also because AOO thought about changing,
and did not find a better multiplatform library.
>
> 2. Perhaps we should consider implementing as much as possible of the
> desktop editing app in a way that is independent of Qt. Parts of the code
> do not involve UI code at all (e.g. logic for loading/saving files, doing
> calculations regarding stylesheet properties, building a data structure
> representing the document outline). These are “model” classes, and could
> use some basic utility classes for strings, dictionaries, expandable arrays
> etc that we currently use in Qt (in fact we already have some of these in
> DocFormats, e.g. DFHashTable). Then the UI part of the (main) editor app
> could be implemented in Qt, but others could use Objective C/Swift on Mac,
> C# on Windows etc. to implement a platform-specific UI layer.
>
+1, We should be able to isolate the Qt part to a single source of ours.
>
> 3. I just realised after I sent my last mail that I don’t think I’ve fully
> articulated the nature of what is required on the “native” side to
> supplement the JS editing library to produce a fully-working application.
> Some of the things the native app needs to provide are:
>
> - Loading/saving of documents, including selection of files (using the
> system’s open/save dialog)
> - Menus and toolbars for providing access to commands
> - Dialogs for things like inserting a table, adding a picture, changing
> all formatting properties (colour wheels, line width selectors, font lists,
> control over paragraph borders etc.)
> - Spell checking
> - Find & replace
> - Word count
> - A style editor, including all major CSS properties (using the formatting
> controls above)
> - Interacting with the API calls in the JS library for mouse and keyboard
> events for cursor placement & movement, selection, text insertion/deletion,
> and copy/paste
> - Error reporting dialogs
> - Splash screen, about box, help etc.
>
> As you can see from this list, there’s a *lot* more than simply bringing
> up a web view and displaying a HTML-based UI - the design all along (which
> comes from the goals of UX Write) was to provide a native UI for the best
> user experience, and only use the web view as a place to render documents.
>
I had most of this in mind, but it still boils down to a pretty simple
interface between
Our application code -> UI (ex. QT) -> Web/JS integration.
Risking being told otherwise, I would say the lines of code would be 80% -
15% - 5%
>
> This breakdown could be revisited, however - many of the above things
> could be implemented as a web UI and displayed through a web view (assuming
> a suitable one is present, e.g. WebKit on OS X and IWebBrowser2 on
> Windows). In fact we really need to do this anyway for the browser-based
> version of the editor. It wouldn’t feel as “native”, but would at least
> give a large portion of the above functionality.
>
That is an alternative I have been playing with, it might be a good
compromise.
I suggest we suggest we continue as you have started with Qt, try to
isolate the Qt in a single file, and then we take the discussion as we go
along.
rgds
jan i.
>
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 27 Jul 2015, at 5:20 pm, jan i <ja...@apache.org> wrote:
>
> Hi Peter
>
> sorry for top posting, but I try to answer both of your mails in one.
>
> The licensing problem is a bit more complicated.
>
> Apache source is not allowed to depend on third party libraries that uses
> e.g. LGPL if you
> want to read details you can find it here:
> http://www.apache.org/legal/resolved.html
> disc
> In general there are a number of loopholes:
> - if the library is part of the OS we don´t care (think of Microsoft
> SDK/MFC, OS-X core libraries and glibc), so webkit on OS-X is not a problem
> - if the component is optional we don´t care in case of LGPL
So much for open source/free software as an antidote to the “walled gardens” that Apple and the like are often criticised for. In FOSS we have walls of a different form dividing those who favour the GPL/LPL and similar licenses, and those who favour more liberal licenses like MIT/BSD/Apache, with the licenses limiting what would otherwise be beneficial code sharing :(
I understand there are perfectly valid and well-considered reasons for the rules you’ve mentioned that have been reached as a result of consensus at Apache, and there’s little point in trying to argue against that. And we can certainly ship a Qt-based editor as an optional component. So really I’m interested in the practical steps we can take to come up with something that’s as useful as possible within these limitations.
1. Which UI toolkit is best for Apache project, and that other projects are already using? I had a brief look around at lists of potential candidate UI toolkits but didn’t find anything that was both good quality/mature and with a friendly license. But I’ve quite possibly missed something. Are there other ASF project that provide a desktop app (and aren’t in Java) that we can learn from and take a similar path to them?
2. Perhaps we should consider implementing as much as possible of the desktop editing app in a way that is independent of Qt. Parts of the code do not involve UI code at all (e.g. logic for loading/saving files, doing calculations regarding stylesheet properties, building a data structure representing the document outline). These are “model” classes, and could use some basic utility classes for strings, dictionaries, expandable arrays etc that we currently use in Qt (in fact we already have some of these in DocFormats, e.g. DFHashTable). Then the UI part of the (main) editor app could be implemented in Qt, but others could use Objective C/Swift on Mac, C# on Windows etc. to implement a platform-specific UI layer.
3. I just realised after I sent my last mail that I don’t think I’ve fully articulated the nature of what is required on the “native” side to supplement the JS editing library to produce a fully-working application. Some of the things the native app needs to provide are:
- Loading/saving of documents, including selection of files (using the system’s open/save dialog)
- Menus and toolbars for providing access to commands
- Dialogs for things like inserting a table, adding a picture, changing all formatting properties (colour wheels, line width selectors, font lists, control over paragraph borders etc.)
- Spell checking
- Find & replace
- Word count
- A style editor, including all major CSS properties (using the formatting controls above)
- Interacting with the API calls in the JS library for mouse and keyboard events for cursor placement & movement, selection, text insertion/deletion, and copy/paste
- Error reporting dialogs
- Splash screen, about box, help etc.
As you can see from this list, there’s a *lot* more than simply bringing up a web view and displaying a HTML-based UI - the design all along (which comes from the goals of UX Write) was to provide a native UI for the best user experience, and only use the web view as a place to render documents.
This breakdown could be revisited, however - many of the above things could be implemented as a web UI and displayed through a web view (assuming a suitable one is present, e.g. WebKit on OS X and IWebBrowser2 on Windows). In fact we really need to do this anyway for the browser-based version of the editor. It wouldn’t feel as “native”, but would at least give a large portion of the above functionality.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <de...@acm.org> wrote:
>
> It would certainly be possible to do an editor outside of the project, whether LibreCorinthia or some other. That would still allow use of components from Apache Corinthia that are provided under ALv2. Anyone can do that. (And PayMeCorinthia could be done using the Commercial Qt license.)
>
> If an editor is to be a release from Corinthia, the challenge is to not have a requirement for Qt, however that is accomplished. I have not suggested that having an editor be abandoned. I have suggested that having Qt be essential as the UI framework is a deal breaker.
I see the editor app primarily as a reference implementation. Certainly my main motivation coming into this was for Corinthia to be a library/toolkit upon which people can build a wide variety of applications. I agree that having the editor seen as “the” product can be detrimental to the project in that our goals are more general than just producing a particular application.
Having said that, I still see value in having an app tailored at end-users as being a worthwhile goal. In addition to providing benefit to many people, it will also help increase the profile of the project and the notion of moving away from a single/proprietary file formats, allowing people to use whatever they want. For example, I’m not aware of any good WYSIWYG (or more specifically, visual) editors for Markdown - it’s a great format but the text-based nature of it can be a turn-off for some people. So I’m strongly in favour of having a desktop app as one of our outputs, though not the only output.
Regarding Qt, I personally feel it’s an extremely unfortunate situation with the licensing situation. The unfortunate reality is that there are no good UI toolkits (that I’m aware of) which meet the requirements of Apache, and I think that puts Apache at a significant disadvantage when it comes to desktop apps. However, with Jan’s proposal, I think we can come up with a suitable solution which allows us to abstract over specific UI toolkits, so that another could be substituted.
This is actually an issue which is not specific to our project, but has implications for Apache more generally. The most important question that’s come to my mind from this discussion is: What should an Apache project that wishes to produce a desktop app do? There’s no easy solutions which fit the licensing criteria, and writing a new UI toolkit from scratch is *hard*. I understand OpenOffice uses its own, largely since it did so for more than a decade prior to entering apache. But how do other projects handle this challenge?
>
> - Dennis
>
> RELATED THOUGHTS
>
> (This probably should be on a separate thread, but I think it figures into the thinking about editors and whatever frameworks are used.)
>
> Experience on another user-facing project suggests that producing a branded editor is a bad idea, because of versions that will be produced using the same code but (1) loaded with adware and other unpleasant artifacts and (2) used to charge fees while being passed off as the authentic project-supported version. This creates an intolerable support situation. We know this happens in App stores for mobile devices and tablets and the culprits will pay for favorable ad placement.
This is indeed a challenge. I assume you’re referring to OO here - I too have seen the requests on the mailing lists from people who don’t understand what Apache is about, sending legal threats to have their message to a public mailing list removed from multiple archives, and other unpleasant situations. But I don’t think the problem is bad enough to warrant avoidance of open source applications for end users - to me, it’s a question of how support issues are managed.
When I think of what is the most well-known open source desktop app, I’d say it’s probably Firefox. I’m not sure how they handle support issues, but as an outside observer it seems to be an extremely successful product. So it’s certainly doable - perhaps we can look to Firefox and other projects to see how to best handle (or rather deflect) support requests. Part of it I think is managing expectations; we certainly want to avoid putting a major support burden on our team. As I said above though, I don’t think it’s reason enough to avoid end-user apps, but we do have to keep support issues in mind once we get closer to a 1.0 release.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I've said my piece about what I consider the hazards of a Qt-first approach, even as an example.
However, I was pointed to an important policy document as part of a separate discussion. I recommend that folks look at <http://www.apache.org/legal/resolved.html#prohibited> and the statement "Can Apache Projects Rely on Components whose Licensing Affects the Apache Project?"
I recommend that passage because it provides the yardstick for acceptable Optional dependencies and how they are handled. This certainly applies to Category X (such as [L]GPL) dependencies.
Please keep that in mind.
I will now shut up about that.
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Tuesday, August 4, 2015 23:53
To: dev@corinthia.incubator.apache.org
Subject: Re: Is Qt the right choice ??
On Wednesday, August 5, 2015, Peter Kelly <pm...@apache.org> wrote:
> Fair point - to be honest I really don’t want to do the GUI work, and
> think that the resistance against Qt is extremely …. how should I say,
> unfortunate.
please remember the resistance is pretty isolated, and please believe I had
not made my suggestion about an editor framework had I not had a qualified
idea that it is acceptable.
[ ... ]
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On Wednesday, August 5, 2015, Peter Kelly <pm...@apache.org> wrote:
> Fair point - to be honest I really don’t want to do the GUI work, and
> think that the resistance against Qt is extremely …. how should I say,
> unfortunate.
please remember the resistance is pretty isolated, and please believe I had
not made my suggestion about an editor framework had I not had a qualified
idea that it is acceptable.
>
> Sometimes the most effective way of motivating me is to make me angry. The
> “fine, i’ll write my own damn cross-platform UI toolkit” response is what’s
> been driving me the fast few days :)
>
> But I agree this is work other equally-capable members of the project
> could do, my time is best devoted to Flat (which I enjoy working on much
> more).
once you have verfied zip on the other platforms I will make the release
branch. This will not take much of my time. so I could start making a
design proposal which we all can discuss.
>
> Dennis, is the UI abstraction layer something you would be willing to
> contribute to?
good idea, Dennis has experience from AOO and other places, that would be
nice to integrate.
rgds
jan i
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org <javascript:;>
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
> > On 5 Aug 2015, at 1:29 pm, jan i <jani@apache.org <javascript:;>> wrote:
> >
> > With all due respect I am a bit concerned.
> >
> > I think the interface to Qt and e.g. Cocoa, is a important interface for
> > the project, so we should discuss the general design before you start
> just
> > programming. I have
> > no doubt that you are capable of doing it, but I am also sure there are
> > other people (like myself) who also have experience can attribute
> > positively to make the
> > interface more flexible and a community effort.
> >
> > My second concern is that you are also working on "flat", which seems to
> me
> > to be the most critical part for the project. I have a good understanding
> > of what you are developing, but I am pretty sure the others don´t.
> >
> > You do not want to be the main programmer, but by taking all the
> > interesting pieces and leaving bread crumbs, you will continue to stay
> the
> > main developer. I
> > am not the one to block you from doing things, but I would wish you would
> > concentrate on getting flat to a condition where we can release it. The
> > editor framework is
> > surely a lower priority and can be done by others (e.g. me) of course
> with
> > the input from the rest of the team.
> >
> > I know you have a fantastic energy and burn for the project, so please do
> > not read this as I am criticizing, please read it as a concern as to how
> we
> > get others
> > to be main developers alongside you.
> >
> > We do not get new main developers, by developing pieces to interfaces you
> > have defined. Taking me as the example, I have Qt experience (did core
> work
> > on Qt years ago) but have 0% interest in developing code to a given
> > interface for a platform I do not care about, so I would do other things
> > (like I just did 32/64bit and zip), but
> > it means I would not be a main developer.
> >
> > rgds
> > jan i.
> >
> >
> >
> > On 5 August 2015 at 05:53, Peter Kelly <pmkelly@apache.org
> <javascript:;>> wrote:
> >
> >>> On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <
> dennis.hamilton@acm.org <javascript:;>>
> >> wrote:
> >>>
> >>> The actual construction of a functioning editor that might be available
> >> in a source release and also a convenience binary for one or more
> platforms
> >> is a bit down the road. I understand that.
> >>>
> >>> Nevertheless, I am concerned that this podling is playing with fire and
> >> tempting unfortunate consequences.
> >>>
> >>> I just want to give fair warning that even an "example" having only
> >> unapproved dependencies may be frowned upon if one cannot build a fully
> >> functioning version from the release without such a dependency.
> Satisfying
> >> that condition would be a great example and also in the spirit and
> letter
> >> of ASF requirements for software provided by its projects.
> >>>
> >>> The NULL case that I have seen described does not qualify as
> >> fully-functioning, in my opinion. I look forward to further details in
> >> that approach so one can explore providing a reference version having
> full
> >> functionality the substitutability of dependencies, including optional
> use
> >> of Qt.
> >>
> >> As part of the abstraction layer I am developing, my intention is to
> make
> >> a Cocoa backend (Apple’s API for building native OS X apps), as well as
> a
> >> Qt backend. Thus we will have at least one platform on which it is
> possible
> >> to build a fully-functioning version of the editor, and thus we can
> include
> >> it as a core component of a Corinthia distribution.
> >>
> >> The Qt backend will be optional in the sense that someone can choose not
> >> to use it, if they prefer to instead write their own abstraction layer
> for
> >> whatever platform they are targeting.
> >>
> >> Contributions in the form of code to help support more platforms without
> >> Qt will be very welcome.
> >>
> >> —
> >> Dr Peter M. Kelly
> >> pmkelly@apache.org <javascript:;>
> >>
> >> PGP key: http://www.kellypmk.net/pgp-key <
> http://www.kellypmk.net/pgp-key>
> >> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> >>
> >>
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
Fair point - to be honest I really don’t want to do the GUI work, and think that the resistance against Qt is extremely …. how should I say, unfortunate.
Sometimes the most effective way of motivating me is to make me angry. The “fine, i’ll write my own damn cross-platform UI toolkit” response is what’s been driving me the fast few days :)
But I agree this is work other equally-capable members of the project could do, my time is best devoted to Flat (which I enjoy working on much more).
Dennis, is the UI abstraction layer something you would be willing to contribute to?
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 5 Aug 2015, at 1:29 pm, jan i <ja...@apache.org> wrote:
>
> With all due respect I am a bit concerned.
>
> I think the interface to Qt and e.g. Cocoa, is a important interface for
> the project, so we should discuss the general design before you start just
> programming. I have
> no doubt that you are capable of doing it, but I am also sure there are
> other people (like myself) who also have experience can attribute
> positively to make the
> interface more flexible and a community effort.
>
> My second concern is that you are also working on "flat", which seems to me
> to be the most critical part for the project. I have a good understanding
> of what you are developing, but I am pretty sure the others don´t.
>
> You do not want to be the main programmer, but by taking all the
> interesting pieces and leaving bread crumbs, you will continue to stay the
> main developer. I
> am not the one to block you from doing things, but I would wish you would
> concentrate on getting flat to a condition where we can release it. The
> editor framework is
> surely a lower priority and can be done by others (e.g. me) of course with
> the input from the rest of the team.
>
> I know you have a fantastic energy and burn for the project, so please do
> not read this as I am criticizing, please read it as a concern as to how we
> get others
> to be main developers alongside you.
>
> We do not get new main developers, by developing pieces to interfaces you
> have defined. Taking me as the example, I have Qt experience (did core work
> on Qt years ago) but have 0% interest in developing code to a given
> interface for a platform I do not care about, so I would do other things
> (like I just did 32/64bit and zip), but
> it means I would not be a main developer.
>
> rgds
> jan i.
>
>
>
> On 5 August 2015 at 05:53, Peter Kelly <pm...@apache.org> wrote:
>
>>> On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <de...@acm.org>
>> wrote:
>>>
>>> The actual construction of a functioning editor that might be available
>> in a source release and also a convenience binary for one or more platforms
>> is a bit down the road. I understand that.
>>>
>>> Nevertheless, I am concerned that this podling is playing with fire and
>> tempting unfortunate consequences.
>>>
>>> I just want to give fair warning that even an "example" having only
>> unapproved dependencies may be frowned upon if one cannot build a fully
>> functioning version from the release without such a dependency. Satisfying
>> that condition would be a great example and also in the spirit and letter
>> of ASF requirements for software provided by its projects.
>>>
>>> The NULL case that I have seen described does not qualify as
>> fully-functioning, in my opinion. I look forward to further details in
>> that approach so one can explore providing a reference version having full
>> functionality the substitutability of dependencies, including optional use
>> of Qt.
>>
>> As part of the abstraction layer I am developing, my intention is to make
>> a Cocoa backend (Apple’s API for building native OS X apps), as well as a
>> Qt backend. Thus we will have at least one platform on which it is possible
>> to build a fully-functioning version of the editor, and thus we can include
>> it as a core component of a Corinthia distribution.
>>
>> The Qt backend will be optional in the sense that someone can choose not
>> to use it, if they prefer to instead write their own abstraction layer for
>> whatever platform they are targeting.
>>
>> Contributions in the form of code to help support more platforms without
>> Qt will be very welcome.
>>
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org
>>
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>>
>>
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
With all due respect I am a bit concerned.
I think the interface to Qt and e.g. Cocoa, is a important interface for
the project, so we should discuss the general design before you start just
programming. I have
no doubt that you are capable of doing it, but I am also sure there are
other people (like myself) who also have experience can attribute
positively to make the
interface more flexible and a community effort.
My second concern is that you are also working on "flat", which seems to me
to be the most critical part for the project. I have a good understanding
of what you are developing, but I am pretty sure the others don´t.
You do not want to be the main programmer, but by taking all the
interesting pieces and leaving bread crumbs, you will continue to stay the
main developer. I
am not the one to block you from doing things, but I would wish you would
concentrate on getting flat to a condition where we can release it. The
editor framework is
surely a lower priority and can be done by others (e.g. me) of course with
the input from the rest of the team.
I know you have a fantastic energy and burn for the project, so please do
not read this as I am criticizing, please read it as a concern as to how we
get others
to be main developers alongside you.
We do not get new main developers, by developing pieces to interfaces you
have defined. Taking me as the example, I have Qt experience (did core work
on Qt years ago) but have 0% interest in developing code to a given
interface for a platform I do not care about, so I would do other things
(like I just did 32/64bit and zip), but
it means I would not be a main developer.
rgds
jan i.
On 5 August 2015 at 05:53, Peter Kelly <pm...@apache.org> wrote:
> > On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <de...@acm.org>
> wrote:
> >
> > The actual construction of a functioning editor that might be available
> in a source release and also a convenience binary for one or more platforms
> is a bit down the road. I understand that.
> >
> > Nevertheless, I am concerned that this podling is playing with fire and
> tempting unfortunate consequences.
> >
> > I just want to give fair warning that even an "example" having only
> unapproved dependencies may be frowned upon if one cannot build a fully
> functioning version from the release without such a dependency. Satisfying
> that condition would be a great example and also in the spirit and letter
> of ASF requirements for software provided by its projects.
> >
> > The NULL case that I have seen described does not qualify as
> fully-functioning, in my opinion. I look forward to further details in
> that approach so one can explore providing a reference version having full
> functionality the substitutability of dependencies, including optional use
> of Qt.
>
> As part of the abstraction layer I am developing, my intention is to make
> a Cocoa backend (Apple’s API for building native OS X apps), as well as a
> Qt backend. Thus we will have at least one platform on which it is possible
> to build a fully-functioning version of the editor, and thus we can include
> it as a core component of a Corinthia distribution.
>
> The Qt backend will be optional in the sense that someone can choose not
> to use it, if they prefer to instead write their own abstraction layer for
> whatever platform they are targeting.
>
> Contributions in the form of code to help support more platforms without
> Qt will be very welcome.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <de...@acm.org> wrote:
>
> The actual construction of a functioning editor that might be available in a source release and also a convenience binary for one or more platforms is a bit down the road. I understand that.
>
> Nevertheless, I am concerned that this podling is playing with fire and tempting unfortunate consequences.
>
> I just want to give fair warning that even an "example" having only unapproved dependencies may be frowned upon if one cannot build a fully functioning version from the release without such a dependency. Satisfying that condition would be a great example and also in the spirit and letter of ASF requirements for software provided by its projects.
>
> The NULL case that I have seen described does not qualify as fully-functioning, in my opinion. I look forward to further details in that approach so one can explore providing a reference version having full functionality the substitutability of dependencies, including optional use of Qt.
As part of the abstraction layer I am developing, my intention is to make a Cocoa backend (Apple’s API for building native OS X apps), as well as a Qt backend. Thus we will have at least one platform on which it is possible to build a fully-functioning version of the editor, and thus we can include it as a core component of a Corinthia distribution.
The Qt backend will be optional in the sense that someone can choose not to use it, if they prefer to instead write their own abstraction layer for whatever platform they are targeting.
Contributions in the form of code to help support more platforms without Qt will be very welcome.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 29 July 2015 at 22:39, Dennis E. Hamilton <de...@acm.org>
wrote:
> I don't want to dive into this. I do want to correct some misconceptions
> of my views.
>
> Key Point: When an LGPL dependence is made optional, I believe it is not
> that it is optionally removable/replaceable. My understanding is that it
> is optionally introduceable. Not optionally removed/replaced.
>
I get your point, and actually that is exactly how I described it....we
(the project) do NOT supply a layer 1 implementation, we supply a editor
framework WITHOUT layer 1 and layer 0. To make a proof of concept we supply
an EXAMPLE implementation of layer 1 using Qt as well as a NULL
implementation to be able to test the rest.
We do NOT introduce Qt or any other UI kit, we have an API that is neutral
and derived product can implement whatever they want.
>
> I am concerned that this view of "optional" will be seen as gaming the
> policy on Category X software when it is time to have a Corinthia release
> approved by the Incubator PMC.
>
Your concern is duly noted, but do you mind that we pass that road blocker
when we come it, and in the meantime develop corinthia !!
Should it really turn out to be a road blocker, we remove that source(s)
and only have the NULL implementation. I volunteer to keep the removed code
in my Git account as a derived product.
Please look at it from the projects POW and not from some might happen
theoretical view (which btw other people say is ok). We need to move as a
project, and if
it really turns out we made a mistake we move some source code, what is
your problem ?
>
> I don't understand the inference that I don't see an editor as part of
> Corinthia. There is no basis for that inference. I thought having an
> editor was the whole point of the Corinthia model and the architectural
> approach. I have never said anything to the contrary. I have opinions
> about the building of an editor and I would be very disappointed if
> Corinthia did not provide at least one portably-compilable/-deployable
> editor.
>
Well it seems you missed something fundamental in Corinthia. DocFormats the
library is the primary part. ALL consumers are nice to have addons.
But having said that, I also want corinthia to have an editor...and would
for sure like your positive input, instead of just hearing what cannot be
done.
Peter already asked you, what is your suggestion ? I ask the same question.
I respect you have opinions, that is perfectly valid, but please try to
offer solutions instead of just telling what cannot be done.
rgds
jan i.
>
> - Dennis
>
> PS: I am usually very careful to speak of source-code *releases* and
> binary *distributions.* If I have not made that clear in speaking of
> binaries, it is a mistake on my part. For example, when I say "Any
> project-provided binary distribution ..." I am not speaking of an Apache
> Project release, even when those are often produced in company with Apache
> releases. I thought I had cleared that up in previous conversations
> somewhere.
>
> PPS: Jar files, a form of binaries, are often provided for Java-based
> Apache Projects. These days, I would not be surprised to see signed
> libraries also be provided (i.e., DLLs and the ilk).
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Wednesday, July 29, 2015 10:53
> To: dev@corinthia.incubator.apache.org; Dennis Hamilton <
> dennis.hamilton@acm.org>
> Subject: Re: Is Qt the right choice ??
>
> On 29 July 2015 at 17:56, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
> [ ... ]
>
>
> > If an editor is to be a release from Corinthia, the challenge is to not
> > have a requirement for Qt, however that is accomplished. I have not
> > suggested that having an editor be abandoned. I have suggested that
> having
> > Qt be essential as the UI framework is a deal breaker.
> >
> You did not use the word "abandoned" but there were no doubt that you did
> not see an editor being part of corinthia
>
> Nobody have ever talked about making Qt essential, the word "optional" has
> always been used, because the implementation will of course be in a way
> that it
> can be replaced. It is however a misunderstand to assume that we have to
> provide multiple implementation for an optional component of the project.
>
>
>
>
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 4 August 2015 at 18:46, Dennis E. Hamilton <de...@acm.org>
wrote:
> The actual construction of a functioning editor that might be available in
> a source release and also a convenience binary for one or more platforms is
> a bit down the road. I understand that.
>
> Nevertheless, I am concerned that this podling is playing with fire and
> tempting unfortunate consequences.
>
> I just want to give fair warning that even an "example" having only
> unapproved dependencies may be frowned upon if one cannot build a fully
> functioning version from the release without such a dependency. Satisfying
> that condition would be a great example and also in the spirit and letter
> of ASF requirements for software provided by its projects.
>
> The NULL case that I have seen described does not qualify as
> fully-functioning, in my opinion. I look forward to further details in
> that approach so one can explore providing a reference version having full
> functionality the substitutability of dependencies, including optional use
> of Qt.
>
It is a fair opinion, which we have to disagree on...providing a framework
is not the same as providing an editor.
>
> I have nothing more to add beyond this cautionary warning concerning the
> attraction of a Qt-first approach.
>
Thanks for the warning, it is always nice to have a sanity check.
>
> - Dennis
>
> MORE BACKGROUND
>
> There are periodically long and contentious discussions about
> non-category-A dependencies from Apache Project source code. One is going
> on at the moment. These tend to come from one vocal advocate. The
> Foundation, so far, has not accepted those arguments and sticks to its
> official policy, regardless of what the specifics of various non-category-A
> licenses might or might not allow.
>
It sure is ongoing, but it actually targeting something quite different.
This discussion is more about why we cannot distribute 3rd party as part of
our code.
>
> The abridged message, below, is representative of a recent response about
> comingling of dependencies on category-B and category-X (i.e., [L]GPL) in
> any manner. You can see the complete message, and the related thread, at
> <
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201508.mbox/%3CCACsi251pLmV8qKf5NFuJ-oK02KWLLwdTwBXn6JQVc7J0%2BUvqXQ%40mail.gmail.com%3E
> >.
>
> I chose this message, posted today, because the author summarizes what I
> have seen to be where all of these debates end up. Rowe has provided a
> perfect capsule summary with a warning case.
>
he sure does. I still do not see the relevance to a framework, that does
not include 3rd party code.
Again should we actually have trouble down the road (which you warn about,
and I do not believe), then we only release the framework, end of story.
Any PPMC or a group of PPMC can then publish (mark the difference, not
release) the rest.
rgds
jan i.
>
> - Dennis
>
> ----- Forwarded Message (abridged) -----
> From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
> Sent: Monday, August 3, 2015 23:46
> To: legal-discuss@apache.org; Lawrence Rosen <lr...@rosenlaw.com>
> Subject: RE: Third Party FOSS licenses
>
> On Aug 3, 2015 16:48, "Lawrence Rosen" <lr...@rosenlaw.com> wrote:
> [ ... ]
> > I admit that "copyleft" includes MPLv2, EPL, GPL, and lots of other
> licenses, although DRM for binaries is irrelevant for FOSS software. And
> true enough, as long as those components are and remain FOSS, you are free
> to create derivative works but you must reciprocate with your license.
>
> Which is why they are category X, yes. Where they are optionally part of
> a larger combination of ASF and external works, whether X or B, that
> provides the benefit of a larger FOSS ecosystem, but its long been codified
> in policy that ASF works cannot require such components to be functional.
>
> [ ... ]
> The APR project has a set of interfaces for a number of key value data
> stores. The license terms vary widely. In creating binaries, the user may
> combine with whichever are both acceptably licensed and offer acceptable
> performance. A downstream licensor such as some BSDs might never include
> the [L]GPL providers, but has other effective options to combine with BSD
> licensed clients.
>
> If projects seek to build something that only functions with [L]GPL
> solutions, it is a issue and that project has better homes elsewhere in the
> sphere of FOSS foundations.
> Indeed, dependencies can be resolved, but here the onus is on the PMC to
> find those alternatives. One incubating project already demonstrated they
> could not remove a key ffmpeg dependent, and that project, warned early on,
> was eventually retired without graduating.
>
> > And anyway, such decisions are not yours and mine to make, but for each
> PMC and each customer to decide for itself. That's the policy change.
> No, the PMC doesn't have that authority until the policy is changed. [ ...
> ]
>
> [end of abridged extract]
>
>
>
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The actual construction of a functioning editor that might be available in a source release and also a convenience binary for one or more platforms is a bit down the road. I understand that.
Nevertheless, I am concerned that this podling is playing with fire and tempting unfortunate consequences.
I just want to give fair warning that even an "example" having only unapproved dependencies may be frowned upon if one cannot build a fully functioning version from the release without such a dependency. Satisfying that condition would be a great example and also in the spirit and letter of ASF requirements for software provided by its projects.
The NULL case that I have seen described does not qualify as fully-functioning, in my opinion. I look forward to further details in that approach so one can explore providing a reference version having full functionality the substitutability of dependencies, including optional use of Qt.
I have nothing more to add beyond this cautionary warning concerning the attraction of a Qt-first approach.
- Dennis
MORE BACKGROUND
There are periodically long and contentious discussions about non-category-A dependencies from Apache Project source code. One is going on at the moment. These tend to come from one vocal advocate. The Foundation, so far, has not accepted those arguments and sticks to its official policy, regardless of what the specifics of various non-category-A licenses might or might not allow.
The abridged message, below, is representative of a recent response about comingling of dependencies on category-B and category-X (i.e., [L]GPL) in any manner. You can see the complete message, and the related thread, at
< http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201508.mbox/%3CCACsi251pLmV8qKf5NFuJ-oK02KWLLwdTwBXn6JQVc7J0%2BUvqXQ%40mail.gmail.com%3E>.
I chose this message, posted today, because the author summarizes what I have seen to be where all of these debates end up. Rowe has provided a perfect capsule summary with a warning case.
- Dennis
----- Forwarded Message (abridged) -----
From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
Sent: Monday, August 3, 2015 23:46
To: legal-discuss@apache.org; Lawrence Rosen <lr...@rosenlaw.com>
Subject: RE: Third Party FOSS licenses
On Aug 3, 2015 16:48, "Lawrence Rosen" <lr...@rosenlaw.com> wrote:
[ ... ]
> I admit that "copyleft" includes MPLv2, EPL, GPL, and lots of other licenses, although DRM for binaries is irrelevant for FOSS software. And true enough, as long as those components are and remain FOSS, you are free to create derivative works but you must reciprocate with your license.
Which is why they are category X, yes. Where they are optionally part of a larger combination of ASF and external works, whether X or B, that provides the benefit of a larger FOSS ecosystem, but its long been codified in policy that ASF works cannot require such components to be functional.
[ ... ]
The APR project has a set of interfaces for a number of key value data stores. The license terms vary widely. In creating binaries, the user may combine with whichever are both acceptably licensed and offer acceptable performance. A downstream licensor such as some BSDs might never include the [L]GPL providers, but has other effective options to combine with BSD licensed clients.
If projects seek to build something that only functions with [L]GPL solutions, it is a issue and that project has better homes elsewhere in the sphere of FOSS foundations.
Indeed, dependencies can be resolved, but here the onus is on the PMC to find those alternatives. One incubating project already demonstrated they could not remove a key ffmpeg dependent, and that project, warned early on, was eventually retired without graduating.
> And anyway, such decisions are not yours and mine to make, but for each PMC and each customer to decide for itself. That's the policy change.
No, the PMC doesn't have that authority until the policy is changed. [ ... ]
[end of abridged extract]
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I don't want to dive into this. I do want to correct some misconceptions of my views.
Key Point: When an LGPL dependence is made optional, I believe it is not that it is optionally removable/replaceable. My understanding is that it is optionally introduceable. Not optionally removed/replaced.
I am concerned that this view of "optional" will be seen as gaming the policy on Category X software when it is time to have a Corinthia release approved by the Incubator PMC.
I don't understand the inference that I don't see an editor as part of Corinthia. There is no basis for that inference. I thought having an editor was the whole point of the Corinthia model and the architectural approach. I have never said anything to the contrary. I have opinions about the building of an editor and I would be very disappointed if Corinthia did not provide at least one portably-compilable/-deployable editor.
- Dennis
PS: I am usually very careful to speak of source-code *releases* and binary *distributions.* If I have not made that clear in speaking of binaries, it is a mistake on my part. For example, when I say "Any project-provided binary distribution ..." I am not speaking of an Apache Project release, even when those are often produced in company with Apache releases. I thought I had cleared that up in previous conversations somewhere.
PPS: Jar files, a form of binaries, are often provided for Java-based Apache Projects. These days, I would not be surprised to see signed libraries also be provided (i.e., DLLs and the ilk).
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Wednesday, July 29, 2015 10:53
To: dev@corinthia.incubator.apache.org; Dennis Hamilton <de...@acm.org>
Subject: Re: Is Qt the right choice ??
On 29 July 2015 at 17:56, Dennis E. Hamilton <de...@acm.org>
wrote:
[ ... ]
> If an editor is to be a release from Corinthia, the challenge is to not
> have a requirement for Qt, however that is accomplished. I have not
> suggested that having an editor be abandoned. I have suggested that having
> Qt be essential as the UI framework is a deal breaker.
>
You did not use the word "abandoned" but there were no doubt that you did
not see an editor being part of corinthia
Nobody have ever talked about making Qt essential, the word "optional" has
always been used, because the implementation will of course be in a way
that it
can be replaced. It is however a misunderstand to assume that we have to
provide multiple implementation for an optional component of the project.
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 29 July 2015 at 17:56, Dennis E. Hamilton <de...@acm.org>
wrote:
> It would certainly be possible to do an editor outside of the project,
> whether LibreCorinthia or some other. That would still allow use of
> components from Apache Corinthia that are provided under ALv2. Anyone can
> do that. (And PayMeCorinthia could be done using the Commercial Qt
> license.)
It would most certainly also be possible for Corinthia to do an editor, see
my other thread.
I will not start making projects outside apache, just for sake of a
discussion. Many projects in apache face similar problems, and some of the
have solved the problems
in a similar way as I suggest.
Could we please focus on getting corinthia working, and then later maybe
somebody else does something else !
> If an editor is to be a release from Corinthia, the challenge is to not
> have a requirement for Qt, however that is accomplished. I have not
> suggested that having an editor be abandoned. I have suggested that having
> Qt be essential as the UI framework is a deal breaker.
>
You did not use the word "abandoned" but there were no doubt that you did
not see an editor being part of corinthia
Nobody have ever talked about making Qt essential, the word "optional" has
always been used, because the implementation will of course be in a way
that it
can be replaced. It is however a misunderstand to assume that we have to
provide multiple implementation for an optional component of the project.
>
> - Dennis
>
> RELATED THOUGHTS
>
> (This probably should be on a separate thread, but I think it figures into
> the thinking about editors and whatever frameworks are used.)
>
> Experience on another user-facing project suggests that producing a
> branded editor is a bad idea, because of versions that will be produced
> using the same code but (1) loaded with adware and other unpleasant
> artifacts and (2) used to charge fees while being passed off as the
> authentic project-supported version. This creates an intolerable support
> situation. We know this happens in App stores for mobile devices and
> tablets and the culprits will pay for favorable ad placement.
>
yes and no, it only creates that situation if we as project delivers
binaries. AOO is to my knowledge the only project that declares the
binaries for official.
>
> I had not been thinking of this as part of this conversation, but I think
> that end-user-intended editors released in source code from Corinthia
> itself should be white-label reference developer/testing implementations
> that identify themselves as such. Although fully functional for end-user
> employment, they don't produce store-acceptable binaries without additional
> effort. That's what buildbots should make. There should be no support for
> those builds, although one wants to see developer use and feedback, and
> well as QA against them. But they are not intended as end-user supported
> products (sort of perpetual beta instead).
>
> Any project-provided binary distribution should instead be branded in the
> build process with custom information that is not released. This includes
> any distinctive images, links to help and support, and digital signatures
> provided by the Apache Corinthia project along with other measures that
> qualify the result for inclusion in an app store. Where/how that has to be
> done is accounted for in the source and in the build process, so someone
> can build their own branded version -- just not easily
> free-load/impersonate any authentic end-user binary from the project. This
> also includes code-signing and other actions to satisfy requirements of
> various product stores. This will protect the Apache Corinthia trademark
> and branding and also make it difficult both technically and legally for
> opportunistic folks to pass off a look-alike built on the same code or as a
> wrapper on a white-label build. What we don't want is anything about
> support and sources of information to be bolted into anything but these
> branded distributions.
>
First sentence is wrong !! Apache never provides binary releases, an apache
release is a source release. The project can produce convenience binaries
but they
are not release objects. I am aware that AOO is a special case, but we
(corinthia) should not try to go down that road.
rgds
jan i.
>
>
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Wednesday, July 29, 2015 01:01
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Is Qt the right choice ??
>
> > On 28 Jul 2015, at 5:59 am, Dennis E. Hamilton <de...@acm.org>
> wrote:
> >
> > I think the question is, "Can the editor be built and used without
> including anything from Qt in order to compile, distribute, and run it?"
> >
> > If not, the editor should not be in Corinthia.
>
> So what is your proposal for how we should proceed with the desktop
> editor, other than not doing it?
>
> LibreCorinthia?
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
>
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
It would certainly be possible to do an editor outside of the project, whether LibreCorinthia or some other. That would still allow use of components from Apache Corinthia that are provided under ALv2. Anyone can do that. (And PayMeCorinthia could be done using the Commercial Qt license.)
If an editor is to be a release from Corinthia, the challenge is to not have a requirement for Qt, however that is accomplished. I have not suggested that having an editor be abandoned. I have suggested that having Qt be essential as the UI framework is a deal breaker.
- Dennis
RELATED THOUGHTS
(This probably should be on a separate thread, but I think it figures into the thinking about editors and whatever frameworks are used.)
Experience on another user-facing project suggests that producing a branded editor is a bad idea, because of versions that will be produced using the same code but (1) loaded with adware and other unpleasant artifacts and (2) used to charge fees while being passed off as the authentic project-supported version. This creates an intolerable support situation. We know this happens in App stores for mobile devices and tablets and the culprits will pay for favorable ad placement.
I had not been thinking of this as part of this conversation, but I think that end-user-intended editors released in source code from Corinthia itself should be white-label reference developer/testing implementations that identify themselves as such. Although fully functional for end-user employment, they don't produce store-acceptable binaries without additional effort. That's what buildbots should make. There should be no support for those builds, although one wants to see developer use and feedback, and well as QA against them. But they are not intended as end-user supported products (sort of perpetual beta instead).
Any project-provided binary distribution should instead be branded in the build process with custom information that is not released. This includes any distinctive images, links to help and support, and digital signatures provided by the Apache Corinthia project along with other measures that qualify the result for inclusion in an app store. Where/how that has to be done is accounted for in the source and in the build process, so someone can build their own branded version -- just not easily free-load/impersonate any authentic end-user binary from the project. This also includes code-signing and other actions to satisfy requirements of various product stores. This will protect the Apache Corinthia trademark and branding and also make it difficult both technically and legally for opportunistic folks to pass off a look-alike built on the same code or as a wrapper on a white-label build. What we don't want is anything about support and sources of information to be bolted into anything but these branded distributions.
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Wednesday, July 29, 2015 01:01
To: dev@corinthia.incubator.apache.org
Subject: Re: Is Qt the right choice ??
> On 28 Jul 2015, at 5:59 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> I think the question is, "Can the editor be built and used without including anything from Qt in order to compile, distribute, and run it?"
>
> If not, the editor should not be in Corinthia.
So what is your proposal for how we should proceed with the desktop editor, other than not doing it?
LibreCorinthia?
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 28 Jul 2015, at 5:59 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> I think the question is, "Can the editor be built and used without including anything from Qt in order to compile, distribute, and run it?"
>
> If not, the editor should not be in Corinthia.
So what is your proposal for how we should proceed with the desktop editor, other than not doing it?
LibreCorinthia?
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think the question is, "Can the editor be built and used without including anything from Qt in order to compile, distribute, and run it?"
If not, the editor should not be in Corinthia.
Simple.
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Monday, July 27, 2015 14:35
To: dev@corinthia.incubator.apache.org
Subject: Re: Is Qt the right choice ??
On 27 July 2015 at 23:29, Andrea Pescetti <pe...@apache.org> wrote:
> On 27/07/2015 jan i wrote:
>
>> I totally agree that we cannot include a single bit of Qt code in our
>> source release, but it is legal to reference e.g. include files in the
>> optional source code.
>>
>
> Correct. And of course if you want to bind to a specific version of QT you
> can add a download link for it and hard-code a MD5 (or similar) hash check.
> In general you don't want to host the QT tarball on ASF infrastructure for
> license clarity, but you can use Apache Extras (now in the process of being
> moved from Google Code to SourceForge) to that aim.
>
real good idea, had totally forgotten about apache-extras. THANKS.
rgds
jan i.
>
> Regards,
> Andrea.
>
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 27 July 2015 at 23:29, Andrea Pescetti <pe...@apache.org> wrote:
> On 27/07/2015 jan i wrote:
>
>> I totally agree that we cannot include a single bit of Qt code in our
>> source release, but it is legal to reference e.g. include files in the
>> optional source code.
>>
>
> Correct. And of course if you want to bind to a specific version of QT you
> can add a download link for it and hard-code a MD5 (or similar) hash check.
> In general you don't want to host the QT tarball on ASF infrastructure for
> license clarity, but you can use Apache Extras (now in the process of being
> moved from Google Code to SourceForge) to that aim.
>
real good idea, had totally forgotten about apache-extras. THANKS.
rgds
jan i.
>
> Regards,
> Andrea.
>
Re: Is Qt the right choice ??
Posted by Andrea Pescetti <pe...@apache.org>.
On 27/07/2015 jan i wrote:
> I totally agree that we cannot include a single bit of Qt code in our
> source release, but it is legal to reference e.g. include files in the
> optional source code.
Correct. And of course if you want to bind to a specific version of QT
you can add a download link for it and hard-code a MD5 (or similar) hash
check. In general you don't want to host the QT tarball on ASF
infrastructure for license clarity, but you can use Apache Extras (now
in the process of being moved from Google Code to SourceForge) to that aim.
Regards,
Andrea.
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 27 July 2015 at 17:49, Dennis E. Hamilton <de...@acm.org>
wrote:
> Jan is correct, although "optional" needs to be clarified.
>
> Supplementing Jan's observation:
>
> In addition to <http://www.apache.org/legal/resolved.html> the Qt project
> provides an useful FAQ on what is involved at <http://www.qt.io/faq/>.
> See the section "Developing with the LGPL," subsection "What are my
> obligations when using Qt under the LGPL." Note that the download page, <
> http://www.qt.io/download/>, assumes that an open-source application of
> Qt will itself be under LGPL or GPL.
>
yes but I read it is not a demand.
>
> Making the editor "optional" doesn't help. It is the editor dependency on
> Qt that would have to be optional, with no Qt source code (including
> headers) provided in the editor release and in the Corinthia code base.
> Building with the Qt "option" would involve additional license
> notifications and other provisions concerning substitutability of the Qt
> libraries that would be installed with such a version.
>
I do not quite follow you here. By making the editor optional, we exclude
that code part if you the "pure" apache product.
Don´t forget our main delivery is the docformat library, the consumers are
just nice addons.
I totally agree that we cannot include a single bit of Qt code in our
source release, but it is legal to reference e.g. include files in the
optional source code.
If you look at e.g. AOO (which you know), you find exact the same behaviour
(the --enable-category-b switch), the source code referencing the libraries
are
part of the source release, but not any third party header files or
libraries.
>
> I assume that going to the trouble to make that work is not solving the
> problem for which Qt is desired [;<).
>
Should it finally turn out to be a real problem (I dont think so, but you
might be right), then we simply remove the editor from the apache source
repo,
and put it on github, as a derived product.
rgds
jan i.
>
> - Dennis
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Monday, July 27, 2015 03:21
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Is Qt the right choice ??
>
> Hi Peter
>
> sorry for top posting, but I try to answer both of your mails in one.
>
> The licensing problem is a bit more complicated.
>
> Apache source is not allowed to depend on third party libraries that uses
> e.g. LGPL if you
> want to read details you can find it here:
> http://www.apache.org/legal/resolved.html
> disc
> In general there are a number of loopholes:
> - if the library is part of the OS we don´t care (think of Microsoft
> SDK/MFC, OS-X core libraries and glibc), so webkit on OS-X is not a problem
> - if the component is optional we don´t care in case of LGPL
>
> I am not a lawyer so please don´t ask me about the legal difference, in us
> asking for a library to be installed, or it being preinstalled.
>
> We can surely use the "optional", because the editor is only one of many
> consumers. To avoid discussions with the IPMC, I would prefer to rename
> it "editor" that is more neutral.
>
> [ ... ]
> >
> >
>
>
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Jan is correct, although "optional" needs to be clarified.
Supplementing Jan's observation:
In addition to <http://www.apache.org/legal/resolved.html> the Qt project provides an useful FAQ on what is involved at <http://www.qt.io/faq/>. See the section "Developing with the LGPL," subsection "What are my obligations when using Qt under the LGPL." Note that the download page, <http://www.qt.io/download/>, assumes that an open-source application of Qt will itself be under LGPL or GPL.
Making the editor "optional" doesn't help. It is the editor dependency on Qt that would have to be optional, with no Qt source code (including headers) provided in the editor release and in the Corinthia code base. Building with the Qt "option" would involve additional license notifications and other provisions concerning substitutability of the Qt libraries that would be installed with such a version.
I assume that going to the trouble to make that work is not solving the problem for which Qt is desired [;<).
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Monday, July 27, 2015 03:21
To: dev@corinthia.incubator.apache.org
Subject: Re: Is Qt the right choice ??
Hi Peter
sorry for top posting, but I try to answer both of your mails in one.
The licensing problem is a bit more complicated.
Apache source is not allowed to depend on third party libraries that uses
e.g. LGPL if you
want to read details you can find it here:
http://www.apache.org/legal/resolved.html
disc
In general there are a number of loopholes:
- if the library is part of the OS we don´t care (think of Microsoft
SDK/MFC, OS-X core libraries and glibc), so webkit on OS-X is not a problem
- if the component is optional we don´t care in case of LGPL
I am not a lawyer so please don´t ask me about the legal difference, in us
asking for a library to be installed, or it being preinstalled.
We can surely use the "optional", because the editor is only one of many
consumers. To avoid discussions with the IPMC, I would prefer to rename
it "editor" that is more neutral.
[ ... ]
>
>
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
Hi Peter
sorry for top posting, but I try to answer both of your mails in one.
The licensing problem is a bit more complicated.
Apache source is not allowed to depend on third party libraries that uses
e.g. LGPL if you
want to read details you can find it here:
http://www.apache.org/legal/resolved.html
disc
In general there are a number of loopholes:
- if the library is part of the OS we don´t care (think of Microsoft
SDK/MFC, OS-X core libraries and glibc), so webkit on OS-X is not a problem
- if the component is optional we don´t care in case of LGPL
I am not a lawyer so please don´t ask me about the legal difference, in us
asking for a library to be installed, or it being preinstalled.
We can surely use the "optional", because the editor is only one of many
consumers. To avoid discussions with the IPMC, I would prefer to rename
it "editor" that is more neutral.
And yes, we (the project) release only source (including optional source),
and e.g. I do derived work and publish binaries on my homepage.
All in all you have convinced me (again), and I will update the cmake
files so editor becomes optional and in case it is activated expected Qt to
be installed.
I just wanted to raise the question again, since I now start putting hours
into that part, since win64 works nicely.
rgds
jan i.
.
On 27 July 2015 at 02:41, Peter Kelly <pm...@apache.org> wrote:
> > On 26 Jul 2015, at 5:16 pm, jan i <ja...@apache.org> wrote:
> >
> > Hi
> >
> > I am currently updating the cmake files to cover e.g. the editor and see
> > some problems.
> >
> > I know we decided to use Qt, but I would like to take the discussion
> again.
> >
> > If we use Qt the editor will never be a released product, it will remain
> an
> > optional product, and
> > I think we will want to position the editor as a main feature of
> corinthia.
> >
> > There is an alternative to Qt, which is a little more work but not much.
> If
> > we look at how peter
> > currently uses Qtwebkit it is pretty simple and static.
>
> I should add that in terms of the amount of code, there will ultimately be
> significantly more on the native side (using Qt or whatever other library)
> than the JS code that runs inside the web view. The editor code is 13,600
> lines of JavaScript. UX Write (excluding DocFormats and the JS Editor code)
> is 45,000.
>
> So we have two options:
>
> 1. Use Qt and write ~45,000 lines of code which works across platforms
> 2. Use native UI toolkits and write ~135,000 lines of code, to cover all
> three platform (Win/Linux/Mac)
>
> In practice, it wouldn’t be quite that bad, as some of that is non-UI code
> which could be written in plan C, albeit giving up some of the benefits of
> Qt e.g. string handling and common data structures. But it would be at
> least double the effort in both development and testing (unless we can find
> another suitable cross-platform UI toolkit).
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 26 Jul 2015, at 5:16 pm, jan i <ja...@apache.org> wrote:
>
> Hi
>
> I am currently updating the cmake files to cover e.g. the editor and see
> some problems.
>
> I know we decided to use Qt, but I would like to take the discussion again.
>
> If we use Qt the editor will never be a released product, it will remain an
> optional product, and
> I think we will want to position the editor as a main feature of corinthia.
>
> There is an alternative to Qt, which is a little more work but not much. If
> we look at how peter
> currently uses Qtwebkit it is pretty simple and static.
I should add that in terms of the amount of code, there will ultimately be significantly more on the native side (using Qt or whatever other library) than the JS code that runs inside the web view. The editor code is 13,600 lines of JavaScript. UX Write (excluding DocFormats and the JS Editor code) is 45,000.
So we have two options:
1. Use Qt and write ~45,000 lines of code which works across platforms
2. Use native UI toolkits and write ~135,000 lines of code, to cover all three platform (Win/Linux/Mac)
In practice, it wouldn’t be quite that bad, as some of that is non-UI code which could be written in plan C, albeit giving up some of the benefits of Qt e.g. string handling and common data structures. But it would be at least double the effort in both development and testing (unless we can find another suitable cross-platform UI toolkit).
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 26 July 2015 at 13:38, Ian C <ia...@amham.net> wrote:
> I've just been poking around for a few minutes to see what is out
> there for HTML editing.
>
> There seem to be quite a few. Instead of creating one maybe we just
> piggy back on one or more of the existing editors and maybe supply a
> plugin.
> Eg http://ckeditor.com/ ?
>
That is an idea, but we need to find one, that has a license we can use
(same goes for a library)
http://www.apache.org/legal/resolved.html
I am also not sure a standard editor would work well for us, we need e.g.
to present styles and render according to the styles. Most editors are
simple html editors.
>
> I'm not entirely clear how an editor would fit into our system.
> If for instance we want to edit an ODF document then behind the scenes
> it will call dfconvert to create html.
> The editor will then render the HTML and a user can add/edit/delete
> sections as required.
> Then we have a saveAs so they can write it back to ODF (which since it
> came from ODF I assume would be the default)
> or can save into another format?
>
> Then behind the scenes again it will call dfconvert put to update the
> original document? Or dfcreate if saving to a different format?
>
Yes that is about it.
- open a file in any supported format
- edit the file (remember it is a word processor, not a simple editor)
- Update the original document or save in another format.
>
> So what I am suggesting is if we can find one we can just make it use our
> tools?
>
If we can find a word processor (editor) then I am all for it.
>
> Are there any other Apache projects with HTML editors? I saw Lenya pop
> up but that doesn't look like a fit.
>
We do not want to edit the HTML as such, we want to have an editor which
format is based
on html but we edit as e.g. with word.
rgds
jan i.
>
>
> On Sun, Jul 26, 2015 at 6:16 PM, jan i <ja...@apache.org> wrote:
> > Hi
> >
> > I am currently updating the cmake files to cover e.g. the editor and see
> > some problems.
> >
> > I know we decided to use Qt, but I would like to take the discussion
> again.
> >
> > If we use Qt the editor will never be a released product, it will remain
> an
> > optional product, and
> > I think we will want to position the editor as a main feature of
> corinthia.
> >
> > There is an alternative to Qt, which is a little more work but not much.
> If
> > we look at how peter
> > currently uses Qtwebkit it is pretty simple and static.
> >
> > Webkit is builtin on OS-X, therefore we can use it, without thinking too
> > long about the licenses
> > (we do not ask people to download extra libraries, so it is at the same
> > level that we also depend on windows sdk-api).
> >
> > We cannot use webkit on windows because it is LGPL (same as Qt), but we
> can
> > use mshtml or IWebBrowser2. My idea is to make a simple set of wrapper
> > functions, so that
> > the editor as such does not see the difference. That would allow us
> > to have the editor as a main feature.
> >
> > thoughts ?
> >
> > rgds
> > jan i.
>
>
>
> --
> Cheers,
>
> Ian C
>
Re: Is Qt the right choice ??
Posted by Ian C <ia...@amham.net>.
I've just been poking around for a few minutes to see what is out
there for HTML editing.
There seem to be quite a few. Instead of creating one maybe we just
piggy back on one or more of the existing editors and maybe supply a
plugin.
Eg http://ckeditor.com/ ?
I'm not entirely clear how an editor would fit into our system.
If for instance we want to edit an ODF document then behind the scenes
it will call dfconvert to create html.
The editor will then render the HTML and a user can add/edit/delete
sections as required.
Then we have a saveAs so they can write it back to ODF (which since it
came from ODF I assume would be the default)
or can save into another format?
Then behind the scenes again it will call dfconvert put to update the
original document? Or dfcreate if saving to a different format?
So what I am suggesting is if we can find one we can just make it use our tools?
Are there any other Apache projects with HTML editors? I saw Lenya pop
up but that doesn't look like a fit.
On Sun, Jul 26, 2015 at 6:16 PM, jan i <ja...@apache.org> wrote:
> Hi
>
> I am currently updating the cmake files to cover e.g. the editor and see
> some problems.
>
> I know we decided to use Qt, but I would like to take the discussion again.
>
> If we use Qt the editor will never be a released product, it will remain an
> optional product, and
> I think we will want to position the editor as a main feature of corinthia.
>
> There is an alternative to Qt, which is a little more work but not much. If
> we look at how peter
> currently uses Qtwebkit it is pretty simple and static.
>
> Webkit is builtin on OS-X, therefore we can use it, without thinking too
> long about the licenses
> (we do not ask people to download extra libraries, so it is at the same
> level that we also depend on windows sdk-api).
>
> We cannot use webkit on windows because it is LGPL (same as Qt), but we can
> use mshtml or IWebBrowser2. My idea is to make a simple set of wrapper
> functions, so that
> the editor as such does not see the difference. That would allow us
> to have the editor as a main feature.
>
> thoughts ?
>
> rgds
> jan i.
--
Cheers,
Ian C
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
I think we should continue with Qt, for the following reasons:
1. I’m not aware of any other cross-platform GUI toolkits that are of the same level of quality as Qt. I consider Qt to be an excellent toolkit, and very easy to work with. An alternative may be GTK, but I’m not sure how well this works on Windows and OS X - last time I used it (many years ago) it had to run through an X-Windows app on both, but this may have changed. I’m happy to be advised if this is no longer the case, or if there are any other (good) toolkits with suitable licenses someone can suggests.
2. If we use the native UI toolkit for each platform, then given a fixed amount of developer resources, we’re going to end up with three separate applications that are each 1/3 of the quality/functionality that we’d have with Qt. Even if we can get three times as many people involved (and, in practice, it needs to be more than that anyway as there’s not even enough work going on for the one Qt version), keeping them in sync feature-wise and UI-wise is going to be a huge amount of work.
3. WebKit is LGPL regardless of the platform. On OS X, it’s distributed as part of the system. As far as I’m aware, it’s perfectly valid to link against an LGPL library in any application, regardless of license, including closed-source apps (Safari being an example). LGPL only imposes restrictions on modifications to the LPGL library itself, not code that links against it.
4. It’s my understanding that the only “official” Apache releases are in source form - is this correct? If so, then the source for the Qt app itself would still validly be under the Apache license. The distributed app which combines the open source edition of Qt plus the Corinthia code would necessarily be GPL. If someone wished to produce a closed-source, commercial product based on the desktop app part of Corinthia, they could purchase a Qt commercial license and do so, within the terms of the Apache license. Granted, this is less ideal than being able to do so without the requirements of purchasing a Qt license. In an extreme case, someone could produce a “wrapper” library which emulates the subset of Qt APIs that the Corinthia desktop uses, to allow it to run on a given target platform. In fact, this is exactly what Apple did in 2002 when they ported khtml to OS X, and renamed it to WebKit (the codebase started off as part of the KDE project).
I think the most pertinent issue is #2 - I really think moving away from Qt is going to create more problems that it solves in terms of the significant extra work it’ll require. In fact it puts the project at risk due to there not being enough people or people with enough time to complete a functioning GUI on all major desktop platforms. With Qt we have a decent chance, and I think it will be easier to attract new people (e.g. Capstone project) when we have one codebase instead of three.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 26 Jul 2015, at 5:16 pm, jan i <ja...@apache.org> wrote:
>
> Hi
>
> I am currently updating the cmake files to cover e.g. the editor and see
> some problems.
>
> I know we decided to use Qt, but I would like to take the discussion again.
>
> If we use Qt the editor will never be a released product, it will remain an
> optional product, and
> I think we will want to position the editor as a main feature of corinthia.
>
> There is an alternative to Qt, which is a little more work but not much. If
> we look at how peter
> currently uses Qtwebkit it is pretty simple and static.
>
> Webkit is builtin on OS-X, therefore we can use it, without thinking too
> long about the licenses
> (we do not ask people to download extra libraries, so it is at the same
> level that we also depend on windows sdk-api).
>
> We cannot use webkit on windows because it is LGPL (same as Qt), but we can
> use mshtml or IWebBrowser2. My idea is to make a simple set of wrapper
> functions, so that
> the editor as such does not see the difference. That would allow us
> to have the editor as a main feature.
>
> thoughts ?
>
> rgds
> jan i.