Re: [Development] Abandoning the container changes

Op 16-7-2012 23:52, Thiago Macieira schreef: > On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: >> On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: >>> Hello all >>> >>> I think that, despite the potential benefits of the changes, we >>> should not apply them at t

[Development] Can I compile QtWayland module alone?

I can’t compile after git pull. I checked the followings. Actually, I don’t know about qt_parts, so I wonder if it is possible to compile only QtWayland without SUBDIRS. Would you give me any advice? Thanks. --

Re: [Development] Suggestion on QML portability

On Mon, 16 Jul 2012 09:38:53 ext Andreas Aardal Hanssen wrote: > 2012/7/16 Alan Alpert > > > Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which > > provided this overlap? It would have the old method marked as deprecated > > and > > the new form syntax available and would prov

Re: [Development] Suggestion on QML portability

On Mon, 16 Jul 2012 21:19:41 ext André Pönitz wrote: > I am afraid I am in "Can't resist" mode today... I'm afraid that plight is communicable over email... > On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote: > > [...] > It's a major version change, what did you expect? It's a pain to

[Development] Build QtCreator failed use MSVC2010

> > qmakeevaluator.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) public: static > class QString __cdecl QString::fromWCharArray(unsigned short const > *,int)" (__imp_?fromWCharArray@Q > String@@SA?AV1@PBGH@Z) referenced in function "public: void __thiscall > QMakeEvaluat

[Development] 4.8.2 / QPA / custom window surfaces

I was told this was the right place to get input to this question. We have the following setup: We don't run x11 and this is on embedded Linux. Our compositing process provides ipc buffers to draw into when an app is in windowed mode. In full screen mode, the app acquires a window surface to a

Re: [Development] Abandoning the container changes

On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: > On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: > > Hello all > > > > I think that, despite the potential benefits of the changes, we > > should not apply them at this time. There are far too many chances > > for

Re: [Development] OpenGL Support in Qt5

On Monday 16 July 2012, Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 07.47.10, gunnar.sle...@nokia.com wrote: > > I both like and dislike the idea. Like because it resolves all the functions > > and that way save a lot of pain and dislike because it adds a lot of > > symbols, and

Re: [Development] Abandoning the container changes

On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: > Hello all > > I think that, despite the potential benefits of the changes, we > should not apply them at this time. There are far too many chances > for breakage and it's a blatant disrespect for the feature freeze. I assume this

Re: [Development] OpenGL Support in Qt5

On segunda-feira, 16 de julho de 2012 18.54.17, gunnar.sle...@nokia.com wrote: > The reason we didn't go for this in the past is that end-user applications > always link directly against the OpenGL library, so it doesn't matter what > libraries Qt resolves at runtime. The app will resolve a differe

Re: [Development] OpenGL Support in Qt5

On 16/07/2012 19:54, gunnar.sle...@nokia.com wrote: > On Jul 16, 2012, at 4:54 PM, ext Sean Harmer wrote: > >> On Monday 16 July 2012 07:21:23 Thiago Macieira wrote: >>> On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: >>

Re: [Development] Suggestion on QML portability

I am afraid I am in "Can't resist" mode today... On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote: > [...] > QML has a different model for allowing normal feature development > and maintenance to be interleaved with porting the GUI, perhaps it > hasn't been explained well enough. It's

Re: [Development] Color Profile support on Qt

On Monday 16 July 2012 Jul, Olivier Goffart wrote: > All QPainter operations (at least in the raster engine) assume a linear color > space. That means that the color conversion need to hapen last, right before > being shown to the screen. After all kind of blending operations or anything > done

Re: [Development] OpenGL Support in Qt5

On Jul 16, 2012, at 4:54 PM, ext Sean Harmer wrote: > On Monday 16 July 2012 07:21:23 Thiago Macieira wrote: >> On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: >>> On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: I'm asking for Qt 5.0: what should we tell Linux distr

Re: [Development] Color Profile support on Qt

On Mon, Jul 16, 2012 at 7:07 PM, Olivier Goffart wrote: > All QPainter operations (at least in the raster engine) assume a linear color > space. That means that the color conversion need to hapen last, right before > being shown to the screen. After all kind of blending operations or anything > do

Re: [Development] Suggestion on QML portability

On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote: > On Mon, 16 Jul 2012 03:18:02 ext André Pönitz wrote: > > On Mon, Jul 16, 2012 at 10:02:33AM +1000, Alan Alpert wrote: > > > The theory is that you're not trying to maintain a single codebase > > > for both QML1 and QML2. > > > > [Maybe

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

On Jul 16, 2012, at 19:16 , ext marius.storm-ol...@nokia.com wrote: On 13/07/2012 10:04, ext marius.storm-ol...@nokia.com wrote: So, I think we'll go ahead and get a port forward setup. It has been done. You can now poin

Re: [Development] Suggestion on QML portability

2012/7/16 Thiago Macieira > On segunda-feira, 16 de julho de 2012 09.38.53, Andreas Aardal Hanssen > wrote: > > In Qt 4 we added obsolete symbols for Qt 3, and this never caused any > pain > > for anybody. Qt3Support was a well intended effort to either port classes > > Qt3Support did enable so

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

On 13/07/2012 10:04, ext marius.storm-ol...@nokia.com wrote: > So, I think we'll go ahead and get a port forward setup. It has been done. You can now point your git to git clone ssh://@ssh.qt-project.org:443/qt/qt5 instead, if needed. -- .marius ___

Re: [Development] Color Profile support on Qt

On Monday 16 July 2012 18:25:20 Christoph Feck wrote: > On Monday 16 July 2012 17:42:45 alessandro.port...@nokia.com wrote: > > (Sorry for top-posting, as-well) > > > > Great to see Qt soon supporting color profiles! I agree with Johan > > that color profile handling and conversion should be an op

Re: [Development] Color Profile support on Qt

On Monday 16 July 2012 17:42:45 alessandro.port...@nokia.com wrote: > (Sorry for top-posting, as-well) > > Great to see Qt soon supporting color profiles! I agree with Johan > that color profile handling and conversion should be an opt-in > feature. > I agree with the previous posters that any c

Re: [Development] OpenGL Support in Qt5

On Monday 16 July 2012 08:09:29 BRM wrote: > > From: Sean Harmer > > I don't like how even building the wayland QPA plugin means that we limit > > Qt > > > > and the apps built with it to OpenGL ES. I really don't want to get into a > > situation where we can build modern OpenGL apps for the desk

Re: [Development] Color Profile support on Qt

(Sorry for top-posting, as-well) Great to see Qt soon supporting color profiles! I agree with Johan that color profile handling and conversion should be an opt-in feature. Just a few questions: 1) Would Qt use (and ship) a color conversion library, or would the system library be used where avai

Re: [Development] OpenGL Support in Qt5

On Monday, July 16, 2012 07:21:23 Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: > > On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: > > > I'm asking for Qt 5.0: what should we tell Linux distributors to > > > configure qtbase with? Considering wh

Re: [Development] OpenGL Support in Qt5

> From: Sean Harmer > On Monday 16 July 2012 07:21:23 Thiago Macieira wrote: >> On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: >> > On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: >> > > I'm asking for Qt 5.0: what should we tell Linux distributors > to >> > > conf

Re: [Development] Color Profile support on Qt

Sorry for top posting. Be aware that all usages of QImage goes not target the local screen. I.e. explicitly requesting a conversion seems to be the best option to me. Regards, Johan On 2012-07-16 16:31 alexandros.dermena...@nokia.com wrote: Hi, I am working on adding support for color profiles

Re: [Development] OpenGL Support in Qt5

On Monday 16 July 2012 07:21:23 Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: > > On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: > > > I'm asking for Qt 5.0: what should we tell Linux distributors to > > > configure > > > qtbase with? Considerin

Re: [Development] OpenGL Support in Qt5

It gets worse :) For the Linux Desktop we also want Qt to not only work with Mesa (which provides us with a GLES 2 api), we also want it to function with say the proprietary nvidia drivers, which do not provide GLES (on ia32/x64) or the wayland egl extensions. Simon -- Sendt fra min Nokia N91

[Development] Color Profile support on Qt

Hi, I am working on adding support for color profiles on Qt 5. It is under discussion if the default behavior of QImage shall be: 1) converting from an embedded color profile to the screen color profile when loading an image OR 2) keep the loaded image in the source color space, until the progr

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

> 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... ;-) Yes, we have had such solutions already in the past. Just because you have n

Re: [Development] OpenGL Support in Qt5

On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: > On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: > > I'm asking for Qt 5.0: what should we tell Linux distributors to configure > > qtbase with? Considering what requirements qtwayland has, I think it needs > > to be -opengl

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

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 th

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

Hi, Cutting things short: We are working on a solution, which will probably result in a work around. I will announce once it's done. There is no point in further discussion. We all agree it sucks. But stupid firewall rules are a reality, like it or not. Let's get back to coding. Regards, Dan

Re: [Development] OpenGL Support in Qt5

On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 13.30.31, Sean Harmer wrote: > > IMHO, no. If Desktop GL capabilities are present on the system then Qt > > should enable their use. In time Wayland maybe adopted by Desktop OpenGL > > vendors without the

Re: [Development] OpenGL Support in Qt5

On segunda-feira, 16 de julho de 2012 13.30.31, Sean Harmer wrote: > IMHO, no. If Desktop GL capabilities are present on the system then Qt > should enable their use. In time Wayland maybe adopted by Desktop OpenGL > vendors without the need of pulling in X and GLX but for now it is ES2 > only. "I

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

> 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. > It's not a fix at all. It's a workaround. Important difference! My whole point is that, let us leave th

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

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 usele

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

> 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. > 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 f

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

On Monday 16 July 2012 10:50:20 Laszlo Papp wrote: > > 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). > > Yeah, the

Re: [Development] OpenGL Support in Qt5

On Monday 16 July 2012 05:10:25 Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 07.47.10, gunnar.sle...@nokia.com wrote: > > I both like and dislike the idea. Like because it resolves all the > > functions and that way save a lot of pain and dislike because it adds a > > lot of symb

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

> Who is going to pay for the extra IP dedicated for this? Maybe we should put a > price tag on uses for port 443: if you want to use it, pay $10 per month to > the Qt Project Hosting Foundation and we'll enable your account to use it > (IPv6-only should be free or cheaper). > > Then you can take i

Re: [Development] OpenGL Support in Qt5

On Monday wk29 2012 July 16 05:10:25 AM ext Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 07.47.10, gunnar.sle...@nokia.com wrote: > > I both like and dislike the idea. Like because it resolves all the > > functions and that way save a lot of pain and dislike because it adds a > >

[Development] Breaking binary compatibility in Qt 5.0

Hello Everyone; I just added a reserved pointer in QPaintDevice. This will break binary compatibility. This is just to inform you about possible run-time failures. Just re-compile anything that links with QtGui. Best, Alexandros Dermenakis ___ Develop

Re: [Development] Suggestion on QML portability

On segunda-feira, 16 de julho de 2012 09.38.53, Andreas Aardal Hanssen wrote: > In Qt 4 we added obsolete symbols for Qt 3, and this never caused any pain > for anybody. Qt3Support was a well intended effort to either port classes > that were dropped from Qt 3, or to wrap those around Qt 4 classes

Re: [Development] OpenGL Support in Qt5

On segunda-feira, 16 de julho de 2012 07.47.10, gunnar.sle...@nokia.com wrote: > I both like and dislike the idea. Like because it resolves all the functions > and that way save a lot of pain and dislike because it adds a lot of > symbols, and I'm a little bit uncertain on the usecase. > > Because

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

On segunda-feira, 16 de julho de 2012 10.50.20, Laszlo Papp wrote: > There is no any waste of time, if a company does not wanna change > things upside down, just accept that the contribution will be pushed > against the Qt Project through 443. It is actually way more time waste > and energy at time

Re: [Development] Moving QWindowSystemInterface out of QPA

On Sunday, July 15, 2012 14:24:18 Holger Hans Peter Freyther wrote: > On Tue, Jul 10, 2012 at 11:53:33AM +0200, Thiago Macieira wrote: > > We have only two choices: > > > > 1) make QWindowSystemInterface a proper, public API class > > I think QWindowSystemInterface in its current form would be >

Re: [Development] OpenGL Support in Qt5

Hi Gunnar, On Monday 16 July 2012 10:00:03 gunnar.sle...@nokia.com wrote: > Compatibility between ES and desktop needs to be handled for these classes > to be used in Qt. For the core set that Qt/QML currently uses, this is > already handled by QOpenGLFunctions. ES does not support geometry shade

Re: [Development] OpenGL Support in Qt5

On Jul 16, 2012, at 10:46 AM, ext Sean Harmer wrote: > Hi, > > On Monday 16 July 2012 07:47:10 gunnar.sle...@nokia.com wrote: >> I both like and dislike the idea. Like because it resolves all the functions >> and that way save a lot of pain and dislike because it adds a lot of >> symbols, and I'

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

> 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). Yeah, the desperate ones who have not lost their sake yet... You are pro

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

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 Securit

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

> Like I said, the proxy is http only. and there is a filtered (port 80, > 443 only) internet connection. You are saying socat or corkscrew can > help when you do not have a SOCKS proxy? That is new to me. If one had a system to port forward via, then it would be a deal done, but it is not the cas

Re: [Development] Suggestion on QML portability

On Monday 16 July 2012 13:50:42 Alan Alpert wrote: > It's a major version change, what did you expect? It's a pain to maintain > even a QWidget application for a single Qt 4 and Qt 5 code-base, all the > assistance I'm aware of is for porting Qt4 -> Qt5 in one go. No it is not. Maintaining the sam

Re: [Development] OpenGL Support in Qt5

Hi, On Monday 16 July 2012 07:47:10 gunnar.sle...@nokia.com wrote: > I both like and dislike the idea. Like because it resolves all the functions > and that way save a lot of pain and dislike because it adds a lot of > symbols, and I'm a little bit uncertain on the usecase. The use case is for an

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

On Mon, Jul 16, 2012 at 7:47 AM, wrote: > Is the use of corkscrew and or socat something that should be made more > widely known? Like I said, the proxy is http only. and there is a filtered (port 80, 443 only) internet connection. You are saying socat or corkscrew can help when you do not have

Re: [Development] OpenGL Support in Qt5

I both like and dislike the idea. Like because it resolves all the functions and that way save a lot of pain and dislike because it adds a lot of symbols, and I'm a little bit uncertain on the usecase. Because the functions are not a well defined subclass hierarchy (and nor can they be), the u

Re: [Development] Suggestion on QML portability

2012/7/16 Alan Alpert > Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which > provided this overlap? It would have the old method marked as deprecated > and > the new form syntax available and would provide some form of interim > overlap, > without adding functions to QtQuick 2

Re: [Development] Suggestion on QML portability

While I continue the discussion to my usual level of verbosity inline, I'm bringing the important point up top - read it last to understand the thought process that led me to this: Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which provided this overlap? It would have the ol