On 28 Aug 2014, at 8:06 AM, Lorn Potter wrote:
> On 27/08/2014 9:56 pm, Bo Thorsen wrote:
>> Den 27-08-2014 10:40, Knoll Lars skrev:
>>> I agree that there are many complex corner cases where we can’t exactly
>>> know. But let’s not forget about the common case, where we actually can
>>> determin
On 27/08/2014 9:56 pm, Bo Thorsen wrote:
> Den 27-08-2014 10:40, Knoll Lars skrev:
>> On 26/08/14 21:00, "Thiago Macieira" wrote:
>>
>>> On Tuesday 26 August 2014 12:58:41 Kuba Ober wrote:
> Unless we want to make this a tri-state: definitely local, definitely
> remote, could be either.
>>
On 26 Aug 2014, at 10:45 AM, Blasche Alexander wrote:
> This leaves me with only one option. We have to deploy Bluez 4.101 headers to
> 11.10 machines. It doesn't even have to be a full backport as the dependency
> is a compile time dependency. My tests have shown that calling ::connect()
> w
On Wednesday 27 August 2014 18:25:44 Oswald Buddenhagen wrote:
> > Well, there are still very good reasons to use LGPLv2.1,
>
> which are (within the scope of qt-project)?
When we want a library to be used despite the "freeloader" issue. The whole
reason why the LGPL exists in the first place is
On 27 August 2014 14:55, Oswald Buddenhagen
wrote:
> On Fri, Aug 22, 2014 at 07:21:38AM +, Knoll Lars wrote:of course lgpl2
> still makes sense for add-ons hosted outside qt-project,
> and ones where the author explicitly doesn't want digia to make money
> from selling this module (though in
On Wednesday 27 August 2014 19:42:02 Sorvig Morten wrote:
> > On 27 Aug 2014, at 16:51, Milian Wolff wrote:
> >
> > On Wednesday 27 August 2014 14:49:08 Hausmann Simon wrote:
> >
> >> I'm pretty sure that all the "native" webview APIs allow for at least
> >> runJavascript(string), so injection m
> On 27 Aug 2014, at 16:51, Milian Wolff wrote:
>
> On Wednesday 27 August 2014 14:49:08 Hausmann Simon wrote:
>> I'm pretty sure that all the "native" webview APIs allow for at least
>> runJavascript(string), so injection may also be an easier option.
>
> Oh nice, I assumed without testing nor
Hi all,
I'm looking for guidance to get started with writing a camera backend for
Point Grey machine vision cameras. It's a popular series of cameras with a
custom API. I've seen a number of people asking how it can be used through
the Multimedia framework.
My day job involves producing an applic
On Wed, Aug 27, 2014 at 08:26:15AM -0700, Thiago Macieira wrote:
> On Wednesday 27 August 2014 15:55:37 Oswald Buddenhagen wrote:
> > On Fri, Aug 22, 2014 at 07:21:38AM +, Knoll Lars wrote:
> > > 2. New modules that get added to Qt Project from now on can be licensed
> > > either under
> >
> >
On Wednesday 27 August 2014 15:55:37 Oswald Buddenhagen wrote:
> On Fri, Aug 22, 2014 at 07:21:38AM +, Knoll Lars wrote:
> > 2. New modules that get added to Qt Project from now on can be licensed
> > either under
>
> for simplicity, i would suggest qt-project states preferences for
>
> speci
On Wed, Aug 27, 2014 at 04:27:35PM +0200, Milian Wolff wrote:
> Hey all,
>
> for Qt 5.4, the new WebChannel module will only be "easily" usable for WebKit
> users. For 5.5 I plan to add WebEngine integration, if Pierre is not beating
> me to it. We will simply copy the QML API, and no changes on
On Wednesday 27 August 2014 14:49:08 Hausmann Simon wrote:
> I'm pretty sure that all the "native" webview APIs allow for at least
> runJavascript(string), so injection may also be an easier option.
Oh nice, I assumed without testing nor reading code that the QtWebView API
would be very minimal a
On Wednesday 27 August 2014 16:45:29 Jocelyn Turcotte wrote:
> On Wed, Aug 27, 2014 at 04:27:35PM +0200, Milian Wolff wrote:
> > Hey all,
> >
> > for Qt 5.4, the new WebChannel module will only be "easily" usable for
> > WebKit users. For 5.5 I plan to add WebEngine integration, if Pierre is
> > n
I'm pretty sure that all the "native" webview APIs allow for at least
runJavascript(string), so injection may also be an easier option.
Simon
Opprinnelig melding
Fra: Jocelyn Turcotte
Sendt: 16:45 onsdag 27. august 2014
Til: Milian Wolff
Kopi: Development
Emne: Re: [Development] Qt WebChannel
Hey all,
for Qt 5.4, the new WebChannel module will only be "easily" usable for WebKit
users. For 5.5 I plan to add WebEngine integration, if Pierre is not beating
me to it. We will simply copy the QML API, and no changes on the client-side
HTML should be required, I think.
Then, recently, QtW
On Fri, Aug 22, 2014 at 07:21:38AM +, Knoll Lars wrote:
> 2. New modules that get added to Qt Project from now on can be licensed
> either under
>
for simplicity, i would suggest qt-project states preferences for
specific options:
> * LGPLv2.1, LGPLv3 and commercial or
>
of course lgpl2 st
On Mon, Aug 18, 2014 at 08:32:19AM -0700, Thiago Macieira wrote:
> On Monday 18 August 2014 15:23:25 Marc Mutz wrote:
>
> > I have several times come across the problem that I hack away and end up
> > with a chain of 20 or so commits, most of which are completely independent
> > of each other. If
Den 27-08-2014 10:40, Knoll Lars skrev:
> On 26/08/14 21:00, "Thiago Macieira" wrote:
>
>> On Tuesday 26 August 2014 12:58:41 Kuba Ober wrote:
Unless we want to make this a tri-state: definitely local, definitely
remote, could be either.
>>>
>>> Absolutely. It’s not even an option not to
On 26/08/14 21:00, "Thiago Macieira" wrote:
>On Tuesday 26 August 2014 12:58:41 Kuba Ober wrote:
>> > Unless we want to make this a tri-state: definitely local, definitely
>> > remote, could be either.
>>
>> Absolutely. It’s not even an option not to distinguish those three
>>states.
>> The cons
19 matches
Mail list logo
