Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <98470C9F-1595-496F-9357-0AC4E58292E9@apache.org>
References: 
 <CAK2iWdQnb2FhD57Sa-obwRPoyuDtEL80R2CurDh0M9tJFNp9Pw@mail.gmail.com>
	<6EEC7B71-0F51-4E9C-91B2-07277A15BD19@apache.org>
	<CAK2iWdRfA0mAmJeHRx4ZWFsbCOU-yeBX7V2YkKQDGrZN6ZymtA@mail.gmail.com>
	<004701d0c883$c2b64320$4822c960$@acm.org>
	<CAK2iWdReiQG6=RsANg9ySLqM867zRuNtZNRTy2t5aWZ_zPtihQ@mail.gmail.com>
	<55B6A29E.8090501@apache.org>
	<CAK2iWdQLQM=oirqaHsyuq188npMG-rvVv6R2SFj6ypQVrJ5R=A@mail.gmail.com>
	<018a01d0c8bf$e8cecc80$ba6c6580$@acm.org>
	<A3B300DA-B337-4865-8167-5E69A54EEEC7@apache.org>
	<004701d0ca17$31b15c30$95141490$@acm.org>
	<CAK2iWdRDW0DM6xEj-PxYtvsPnoDGT2JYJY2mRC2zUx+Cw13XVA@mail.gmail.com>
	<00c401d0ca3e$9c6b5f90$d5421eb0$@acm.org>
	<005c01d0ced5$20582d70$61088850$@acm.org>
	<79AFA605-6747-4EB5-AEB2-06EE61C78B28@apache.org>
	<CAK2iWdRUbZ=+HxhNi8NjZb-k6CrtRwRHd9+LAybe390bXfkqHA@mail.gmail.com>
	<98470C9F-1595-496F-9357-0AC4E58292E9@apache.org>
Date: Wed, 5 Aug 2015 08:53:24 +0200
Message-ID: 
 <CAK2iWdQOibSVWVC13cXNXd4EYhhuOuknsu84pS0Oi19rSEsTKg@mail.gmail.com>
Subject: Re: Is Qt the right choice ??
From: jan i <jani@apache.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>
Content-Type: multipart/alternative; boundary=f46d0402abefefe3ea051c8adbdf

--f46d0402abefefe3ea051c8adbdf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, August 5, 2015, Peter Kelly <pmkelly@apache.org> wrote:

> Fair point - to be honest I really don=E2=80=99t want to do the GUI work,=
 and
> think that the resistance against Qt is extremely =E2=80=A6. 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. Th=
e
> =E2=80=9Cfine, i=E2=80=99ll write my own damn cross-platform UI toolkit=
=E2=80=9D response is what=E2=80=99s
> 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

>
> =E2=80=94
> 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 fo=
r
> > 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 t=
o
> me
> > to be the most critical part for the project. I have a good understandi=
ng
> > of what you are developing, but I am pretty sure the others don=C2=B4t.
> >
> > 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 wou=
ld
> > 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 ho=
w
> we
> > get others
> > to be main developers alongside you.
> >
> > We do not get new main developers, by developing pieces to interfaces y=
ou
> > 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 thing=
s
> > (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 availab=
le
> >> 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 a=
nd
> >> 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 full=
y
> >> 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 i=
n
> >> 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=E2=80=99s API for building native OS X apps), a=
s 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 n=
ot
> >> 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 witho=
ut
> >> Qt will be very welcome.
> >>
> >> =E2=80=94
> >> 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)
> >>
> >>
>
>

--=20
Sent from My iPad, sorry for any misspellings.

--f46d0402abefefe3ea051c8adbdf--