Re: [Development] Proposal: Qt 4.9 release

[Sven Anderson]

On 15.08.2012 21:35, Romain Pokrzywka wrote:
> On Wednesday, August 15, 2012 08:36:35 PM Thiago Macieira wrote:
>> On quarta-feira, 15 de agosto de 2012 22.05.02, Konstantin Tokarev wrote:
>>>  From wiki:
>>>
>>> "QPA on Qt4.8 only makes sense on OpenGL Hardware! If you don�t have
>>> OpenGL
>>> HW there is absolutely no point in choosing Qt4.8-QPA over Qt4.8-QWS"
>>
>> The wiki is wrong.
>>
>> There's a lot of reason for choosing QPA, regardless of OpenGL support or
>> lack thereof. There are also reasons for choosing QWS instead of QPA, even
>> with OpenGL hardware, if those reasons are stronger than the best
>> adaptation to OpenGL (example: the QWS display server).
>
> Seconded, that wiki line is BS.
>
> Using QPA with the linuxfb plugin on 4.8 for single-process applications is
> way more efficient than QWS, both memory- and FPS-wise. QWS enables
> composition and server-side rendering by default, which has a huge impact for
> the performance of the transfer-to-framebuffer phase. QPA with linuxfb doesn't
> have any of that.
>
> You can disable it when configuring Qt, but there's no documented option, you
> have to pass -D flags manually. If you're doing it, then yes you get similar
> display performance between QWS and QPA. But by default QPA wins.
>
> The only thing QWS buys you is built-in (and ugly) window decorations, as well
> as multi-process support. For everything else it's just a legacy framework
> with lots of overhead and a constant source of performance problems imho.

Is this theory or experience?

My experience is completely different with QPA on 4.8 and the linuxfb 
platform. I tried it a couple of months ago and framerate was clearly 
lower than with QWS. At that time people told me, that the linuxfb QPA 
platform is in worse shape than the linuxfb plugin used by QWS. But 
maybe something changed since 4.8.0?

Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setting up time-based releases for the project

[Sven Anderson]

On 07.08.2012 13:09, joao.abeca...@nokia.com wrote:

> While the two setups are very similar, almost isomorphs, they're not exactly 
> so. There are important practical consequences that distinguish the two.
>
>  - Releases happen on a fixed schedule
>  - Minor versions have a defined lifetime
>  - The number of patch releases is limited by default.
>
> These give predictability and focus to everyone participating on the project. 
> It gives everyone something to align to.

I understand the advantages of these points and fully support them. I 
just wonder, why you need the parallel rolling branches for it. Can't we 
just establish the fixed scheduling in the classical branches? Instead 
of fixed merge-down-days we would have fixed branch-days.

> There are other practical consequences. As a developer, you don't have to 
> worry about *when* to do or merge a specific change. You get it up to snuff 
> and decide *where* to apply it (i.e., on which branch).
>
> The fact that the branches roll from release to release means anyone tracking 
> development branches decides how much pain they are willing to take and stay 
> the course. You don't have to wait for the next branch to come along so you 
> can jump to it.

Ok, here I see the point. Tracking a certain level of code quality is 
easier with rolling branches. OTOH it's probably easy to install 
automatic commit-aliases that track which ever branch currently has a 
specific quality status, like "beta" or "rc".

> "Quality" in a way jumps up and down with the merges, but I don't think we 
> can eliminate these jumps at the moment and in reality they are not 
> introduced by the proposed model.

Of course we can't eliminate the quality changes. That's why I asked if 
we shouldn't better use a model, that makes that fact explicit 
(transition focused rather than level focused) by branches that (more or 
less monotonically) increase in quality until end of life 
(alpha->beta->release->security-fixes). That would at least eliminate 
the jumps.


Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setting up time-based releases for the project

[Sven Anderson]

Hi,

On 07.08.2012 01:12, Thiago Macieira wrote:
> On terça-feira, 7 de agosto de 2012 01.00.54, Olivier Goffart wrote:
>>   ---+--+-- fire-hose
>> / \  /   /   /  /  /  /  / / \  /  /  /  /  /  /
>>   --+  +-+++  +-++ leaky-faucet
>>/ \  / / / \  / / / \ / /  / \  / / / \ /  / / \
>>   -+  +-+  +-+  +-+  +-+  +-+  +- dripping-bucket
>> \\\\\\
>>  5.0.15.0.25.1.05.1.15.1.25.2.0
>
> I think you're missing the dashes between 5.0.1 and 5.0.2.
>
> dripping-bucket is a rolling branch. To make it fast-forward from one release
> to the next, it needs to merge them.

What exactly is the advantage of having "rolling branches" for the
different stability levels compared to the "specialized" branches for
each level of version number. Wouldn't it have the same effect but
clearer semantics if you have a single rolling branch which maintains
something like alpha level quality, and from that you create a 5.X
branch that _targets_ beta quality, and after it reached it you start
creating 5.X.Y branches that target release quality. 5.X+1 is created,
when the last 5.X.Y has been created and 5.X therefore is dead. This way
you also have exactly 3 active branches at each time and should be
isomorph to the solution with three continuously rolling branches, but
easier to understand in my eyes.

This might sound more complicated on the first view, but note that also
leaky-faucet and dripping-bucket would have different quality states
right after the down-merges until it stabilizes to the targeted quality
level. This change in quality of the branches is not very transparent
from the model, which incorrectly suggests that each rolling branch has
a constant quality level. That's why I would go for specialized branches
which more obviously traverse different levels of quality. Or more
generalized: I would prefer a model, that focuses on quality
_transitions_ rather than quality _levels_, because that's what it's all
about, right? But maybe I'm missing an important aspect.

Sven



  *   Join our Partner program: 
http://www.snom.com/partner
  *   Subscribe to our snom support RSS 
Feed and 
get first-hand technical news about snom products, e.g. Firmware updates, FAQ 
updates, troubleshooting hints, etc.

Follow us on Facebook, 
Twitter, 
YouTube, 
Linkedin


Sitz/Domicile: Charlottenstr. 68-71, 10117 Berlin, Germany
Handelsregistereintrag/Register of Corporations entry: Berlin-Charlottenburg 
HRB 61842 B
Vorstand/Executive Board: Dr. Michael Knieling, Usman Tahir, Alexander Khan
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Stefan Friese

snom technology AG
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Behaviour change of opacity property in QtQuick 2.0

[Sven Anderson]

On 19.07.2012 03:29, Alan Alpert wrote:
> On Wed, 18 Jul 2012 19:00:01 ext Rafael Brandao wrote:
>
> There's a new enabled property which also prevents mouse input. It also 
> affects
> keyboard focus, but if you aren't using keyboard focus you can bind enabled:
> opacity > 0 and get effectively the same results as before.

BTW: I always assumed that binding a bool to a float which is expected 
to be animated, that is, will have a lot of small changes, is very 
inefficent, since a lot of notifies are sent out during the animation, 
and everytime the bool has to be evaluated. So I always set the bool at 
the end of the animation accordingly without binding, or at least I 
created only one bool->float binding, and bound everything else to that 
bool. Is this assumption correct, or don't I have to care about this, 
since it is somehow optimized by the engine?

Sven

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Suggestion on QML portability

[Sven Anderson]

On 17.07.2012 07:47, Alan Alpert wrote:
> But our Qt4Support library exists and is called QtQuick1. All the old symbols
> should be there, if you want to take the easy road to saying "done, ported to
> Qt 5!".

Well, there is no other choice if you have a platform without hardware 
graphics acceleration. ;-)


Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server

[Sven Anderson]

On 16.07.2012 16:06, Laszlo Papp wrote:
>> No, going through 443 is _not_ an option of the firewall, it's like
>> lock-picking a useless lock.
>
> No, the firewall and the whole establishment have the option to go out
> over the port 443.

So, you are saying, the implementer of such a firewall thinks, it's a 
good idea and a valid option, to tunnel all kinds of traffic through 
port 443? I would like to talk to that person. Well, maybe better not... ;-)


>> It's not a fix at all. It's a workaround. Important difference!
>
> My whole point is that, let us leave the decision to the companies, if
> it is a workaround for them or fix. It is *them* deciding about
> *their* policies and approvals. The Qt Project should get as much
> support as possible from outside, especially now. Company policies and
> decisions are not the target of the Qt Project after all. It can just
> aid them as much as possible.
>
> Some companies will open ports up, some will not. The latter might
> give up the contribution to the Qt Project, and will implement their
> own internal solution on top of Qt (not in) without contributing back.
> That would be a pity...

That's why we all agreed, that the workaround should be established. 
What confuses us is (well, me at least), that you seem to support these 
broken policies.


Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server

[Sven Anderson]

On 16.07.2012 15:26, Laszlo Papp wrote:
>> Sorry, but bike locks have keys to disable them. The sanity bot have an 
>> option
>> to override it. Where is that option in your firewall?
>
> Going through 443.

No, going through 443 is _not_ an option of the firewall, it's like 
lock-picking a useless lock.

>> You have no excuse. If you are supposed to work on Qt, your company should
>> give you the infrasctructure to do your work.
>
> Unless it is fixable upstream which seems to be the case anyway. KDE
> was able to fix this. Github was able to fix this. People so far
> agreed upon to fix this for the Qt Project, so nothing really needed
> afterwards to change at other places, just once.

It's not a fix at all. It's a workaround. Important difference!


Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server

[Sven Anderson]

On 13.07.2012 17:10, Laszlo Papp wrote:
>> He also says that you should at the same time have a discussion with
>> Corporate Security to make them understand that the current situation is
>> hurting the organization, and try to get it changed so you _don't_ have
>> to circumvent Corporate Security. (Normally it's grounds for getting the
>> "pink slip" immediately.)
>
> Why open the port up globally with its own drawbacks just because of
> one project? If this can get fixed, and the "circumventing"
> (communicating with patches good for a company over 443) is accepted
> in a network (let it corporate or personal), I do not see the problem
> and the reason to change the existing practicies.

Closing down ports for security reasons can only be a short term 
emergency measure. Doing it in general does not increase security in the 
medium term, since the Bad Guys are now using 443 anyway (like everybody 
else). This whole blocking of ports caused a "port-80-fication" of net 
services which almost killed for what ports where invented in the first 
place: service discrimination. Now we have to use whole IPs for that 
discrimination (like the workaround proposed in this case) or put 
another addressing-layer into the HTTP content. Complete waste of time 
and energy in my opinion, because in the end security has not been 
increased.

So, although I fully understand the need for a workaround to keep work 
going, I fully support Thiagos recommendation to put pressure on the IT 
departments and managers in parallel.

Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Policy for creating new mailing lists

[Sven Anderson]

On 02.07.2012 12:24, marius.storm-ol...@nokia.com wrote:
> Can the one responsible for this list please provide the development
> list a short description of the new ML and why it was needed?

I would assume that it's just a preparation to move the list 
qt-compone...@qt.nokia.com to the qt-project.org site, which exists 
quite some time already...

The same should also happen with the list qt-...@qt.nokia.com in my 
opinion, or even remove it completely, as I proposed before already, 
since it splits the audience. But nobody seems to be responsible for it?


Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Make qdoc an officially supported tool for generating QML API documentation

[Sven Anderson]

Hi Casper,

On 11.06.2012 10:32, casper.vandonde...@nokia.com wrote:
> We have been very busy to get qdoc running outside of Qt (I am starting to
> use qdoc as LaTeX-lite now if I just need an HTML page). I do agree that
> the qdoc manual should be improved with examples that do not necessarily
> reflect how we use qdoc with Qt.

thanks for your reply. That's good news! So, this sounds like "Yes, qdoc 
will probably be an official tool for external usage". Is this 
interpretation correct?

> All changes that we are doing to qdoc are only added to the Qt5 version of
> qdoc (which is qdoc instead of qdoc3). The Qt5 version should also support
> the \inherits you mentioned in the QTBUG (be aware that you cannot use
> \inherits when documenting .qml files, since we automatically use the top
> level element in the .qml file.

That's great! In the the docs for qdoc (Qt 5) it's not yet mentioned how 
\inherits behaves on "external" QML items. So, how does it work? Does it 
have a hardcoded list of Qt Quick items and its elements and links it to 
the official Qt Quick docs? Or will it even work with third-party QML 
items? But then, where does qdoc get the information about inherited 
members and the location of their documentation?


Thanks, and best regards,

Sven

> On 6/8/12 5:16 PM, "ext Sven Anderson"  wrote:
>
>> Hi all,
>>
>> since qdoc is the only tool that can create documentation for QML APIs,
>> but it's (AFAIK) not supported as an external tool - although that is
>> very much needed especially for QML - I suggest to make qdoc the offical
>> tool for generation of external QML API documentation (and fix it
>> accordingly).
>>
>> I filed a suggestion here:
>> https://bugreports.qt-project.org/browse/QTBUG-26096
>>
>>
>> Best regards,
>>
>> Sven
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Make qdoc an officially supported tool for generating QML API documentation

[Sven Anderson]

Hi all,

since qdoc is the only tool that can create documentation for QML APIs, 
but it's (AFAIK) not supported as an external tool - although that is 
very much needed especially for QML - I suggest to make qdoc the offical 
tool for generation of external QML API documentation (and fix it 
accordingly).

I filed a suggestion here: 
https://bugreports.qt-project.org/browse/QTBUG-26096


Best regards,

Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Approver status

[Sven Anderson]

On 25.05.2012 12:29, andre.poen...@nokia.com wrote:
>
> Sven Anderson:
>> I also don't think fixed numbers in rules are very wise. What about
>> offering some moving average stats of various metrics somewhere (maybe
>> they already exist?) and just referring to them in the rules as a guide
>> line? That's more dynamic and adapts to the different activity levels
>> over modules and time.
>
> Wow. No!
>
> The idea was not to have an over-engineered system of random rules, and also
> not to introduce a _scale_,

That was not my intention. I was rather talking about some stats, that 
are anyway interesting and maybe even exist already, and just to give a 
hint that these exist as _one_ possible source among others to build an 
opinion about a potential approver.

>but an extemely low and obviously reasonable cut-off
> point as a minimal barrier of entrance, serving as a guideline for the people
> doing the nomination, saving the hassle of discussing unreasonable 
> nominations,
> and prevent the embarassement of being declined for the nominee.

Ok, this sounds more like a "noise gate", but is there noise? Maybe you 
should make a clear problem statement for your proposed solution then, 
because I have the feeling everybody is proposing solutions for his own 
interpretation what the problem is. ;-)


BR,

Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Approver status

[Sven Anderson]

Hi,

On 25.05.2012 09:34, André Somers wrote:
> Bottom line: let's not introduce rules that are supposed to solve
> problems that have not occured, and that are likely to cause more
> problems than they might ever prevent occuring in the first place. I
> would like to stimulate people to make the most of the current set of
> rules: if you have a doubt about an approver nomination, just voice it.

I also don't think fixed numbers in rules are very wise. What about 
offering some moving average stats of various metrics somewhere (maybe 
they already exist?) and just referring to them in the rules as a guide 
line? That's more dynamic and adapts to the different activity levels 
over modules and time.

BR,

Sven

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] proposing Richard Moore as approver

[Sven Anderson]

Am 02.11.2011 11:14, schrieb Olivier Goffart:
> But am I alone to think that 3 weeks of waiting time is a lot?
> 15 work day is a lot,  how about reducing it to something between 7 and 10
> work days?

OTOH, is this really a time-critical process? In doubt I would choose 
the longer option, not the shorter.


Sven
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development