From dhaivatpandya at gmail.com Sat Oct 22 01:18:05 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Fri, 21 Oct 2011 18:18:05 -0500 Subject: [Development] Maintainer Message-ID: I can't really find a way to phrase this, so, I'll just put it pretty bluntly. I would like to be a maintainer for the currently maintainer-less QtXml or QtSvg. What would be the procedure I should follow to be granted maintainer-ship? -------------- next part -------------- An HTML attachment was scrubbed... URL: From san at sansano.inf.utfsm.cl Sat Oct 22 02:22:59 2011 From: san at sansano.inf.utfsm.cl (Sergio Ahumada Navea) Date: Sat, 22 Oct 2011 02:22:59 +0200 Subject: [Development] Maintainer In-Reply-To: References: Message-ID: <4EA20CE3.6020004@sansano.inf.utfsm.cl> On 10/22/2011 01:18 AM, Dhaivat Pandya wrote: > I can't really find a way to phrase this, so, I'll just put it pretty > bluntly. I would like to be a maintainer for the currently > maintainer-less QtXml or QtSvg. What would be the procedure I should > follow to be granted maintainer-ship? > First Approver: http://wiki.qt-project.org/index.php/The_Qt_Governance_Model#How_to_become_an_Approver Then Maintainer: http://wiki.qt-project.org/index.php/The_Qt_Governance_Model#How_to_become_a_Maintainer Cheers, -- Sergio Ahumada Navea san at sansano.inf.utfsm.cl From Craig.Scott at csiro.au Sat Oct 22 02:29:38 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Sat, 22 Oct 2011 11:29:38 +1100 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <3622471.a3Al887bxZ@doriath> References: <3622471.a3Al887bxZ@doriath> Message-ID: <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> On 22/10/2011, at 5:18 AM, Thiago Macieira wrote: > On Friday, 21 de October de 2011 16:29:36 Stefan Majewsky wrote: >> Moin moin, >> >> it would be nice to have a command line parser in QtCore, i.e. some >> class that parses stuff like >> >>> ./program -vh --long-option --value=5 foo.dat >> >> given some format definition. KCmdLineArgs and KCmdLineOptions from >> kdecore do exactly that for KDE programs. I don't have time right now, >> but perhaps someone wants to pick up this task? > > Hello Stefan > > Speaking as QtCore's maintainer, I'll reserve the decision until I see your > proposal. A while back, we also found ourselves in need of decent command line parsing. It kinda surprised me that Qt didn't offer anything already in this area, since it seemed like the sort of thing that Qt would normally provide. So we considered our options. Our apps are not KDE apps, so we were not able to look there for a solution. We also do not use boost (let's not debate that, it's not the point of this post), so we were not able to use their solution either. In the end, we decided we needed to write our own, which we did. At the time, I had the thought that if we do it right, maybe one day we could consider contributing it back to become part of Qt. Funny how things come around...... Let me state a couple of things before going further. The code in question is 100% our own, so no issues with copyright and contributors, etc. I'd just have to get formal approval from our legal people to release it (that would take time, but since this code isn't particularly novel, I think I can get that approval). Our solution currently supports the main needs for a command line parser, but it won't have every bell and whistle people might want. That said, I don't think it would be particularly difficult to add support for the main omissions. With that out of the way, I've put the class definition up on pastebin for comment. I've withheld the implementation until I've had a chance to clear it with our legal people. In the meantime, I think the interface of the class is probably enough to get some feedback on whether people think this has the potential to be a viable candidate for a command line parser for Qt: http://pastebin.com/45PiHzLA Note that the code currently does not adhere to the Qt coding guidelines (it follows ours instead), but if we do end up contributing it to Qt, then it should not be too difficult to bring it into line. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From dhaivatpandya at gmail.com Sat Oct 22 05:10:32 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Fri, 21 Oct 2011 22:10:32 -0500 Subject: [Development] Crazy Idea Message-ID: This seems like something that's way out there, and may have been suggested before and rejected, but, I'm bringing it up anyway. What would the Qt community think of a web framework devised around Qt? Qt has all the stuff one needs to build a legitimate web framework, connection to a scripting language (PySide, or any language with a C++ API, such as Lua), Sql libraries, async socket libraries, XML, everything. We just need some (okay, not some, a lot) of code to glue this all together into a well knit package. I'll await suggestions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markc at renta.net Sat Oct 22 07:09:22 2011 From: markc at renta.net (Mark Constable) Date: Sat, 22 Oct 2011 15:09:22 +1000 Subject: [Development] Crazy Idea In-Reply-To: References: Message-ID: <6983815.U6Lvx3ECs5@g2> On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: > This seems like something that's way out there, and may have been > suggested before and rejected, but, I'm bringing it up anyway. What > would the Qt community think of a web framework devised around Qt? Speaking personally I'd love to see... . a web server similar to lighttpd but 100% based on Qt . a Qt5/V8 Javascript "engine" similar to NodeJS . an optional but builtin C++ FastCGI interface for the above In other words the essential tools for a Qt Server Side JavaScript solution, with Websocket support, so it can be as both a traditional webserver or a local backend to a HTML5/QML desktop system. Why another webserver when lighttpd, nginx, even apache, already exist as stable codebases? Because none of them allow me to build, develop and deploy them, and any web based projects, within QtCreator using CMake and Git. There is currently a complete development disconnect when deploying a typical HTTP based remote server within a Qt project. > Qt has all the stuff one needs to build a legitimate web framework, > connection to a scripting language (PySide, or any language with a C++ > API, such as Lua), Sql libraries, async socket libraries, XML, > everything. We just need some (okay, not some, a lot) of code to glue > this all together into a well knit package. I'll await suggestions. Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt From lars.knoll at nokia.com Sat Oct 22 10:55:45 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Sat, 22 Oct 2011 08:55:45 +0000 Subject: [Development] Crazy Idea In-Reply-To: <6983815.U6Lvx3ECs5@g2> Message-ID: >From my point of view: Having something here would be great. I don't think it should be part of the essential Qt modules, but as an add-on it would be a very welcome addition :) Cheers, Lars On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >> This seems like something that's way out there, and may have been >> suggested before and rejected, but, I'm bringing it up anyway. What >> would the Qt community think of a web framework devised around Qt? > >Speaking personally I'd love to see... > >. a web server similar to lighttpd but 100% based on Qt > >. a Qt5/V8 Javascript "engine" similar to NodeJS > >. an optional but builtin C++ FastCGI interface for the above > >In other words the essential tools for a Qt Server Side JavaScript >solution, with Websocket support, so it can be as both a traditional >webserver or a local backend to a HTML5/QML desktop system. > >Why another webserver when lighttpd, nginx, even apache, already exist >as stable codebases? Because none of them allow me to build, develop >and deploy them, and any web based projects, within QtCreator using >CMake and Git. There is currently a complete development disconnect >when deploying a typical HTTP based remote server within a Qt project. > >> Qt has all the stuff one needs to build a legitimate web framework, >> connection to a scripting language (PySide, or any language with a C++ >> API, such as Lua), Sql libraries, async socket libraries, XML, >> everything. We just need some (okay, not some, a lot) of code to glue >> this all together into a well knit package. I'll await suggestions. > >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From thiago at kde.org Sat Oct 22 13:44:13 2011 From: thiago at kde.org (Thiago Macieira) Date: Sat, 22 Oct 2011 13:44:13 +0200 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> Message-ID: <2186814.CvKmP2Trg1@doriath> On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au wrote: > With that out of the way, I've put the class definition up on pastebin for > comment. I've withheld the implementation until I've had a chance to clear > it with our legal people. In the meantime, I think the interface of the > class is probably enough to get some feedback on whether people think this > has the potential to be a viable candidate for a command line parser for > Qt: > > http://pastebin.com/45PiHzLA > > Note that the code currently does not adhere to the Qt coding guidelines (it > follows ours instead), but if we do end up contributing it to Qt, then it > should not be too difficult to bring it into line. Hi Craig It's not just the coding guideline, it's the architecture. I'm not a fan of tool classes with virtuals... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From dhaivatpandya at gmail.com Sat Oct 22 15:52:31 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 08:52:31 -0500 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <2186814.CvKmP2Trg1@doriath> References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> <2186814.CvKmP2Trg1@doriath> Message-ID: Craig, Do have any part of this class implemented? If its, people can test it and see if it actually meets the users needs. 2011/10/22 Thiago Macieira > On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au wrote: > > With that out of the way, I've put the class definition up on pastebin > for > > comment. I've withheld the implementation until I've had a chance to > clear > > it with our legal people. In the meantime, I think the interface of the > > class is probably enough to get some feedback on whether people think > this > > has the potential to be a viable candidate for a command line parser for > > Qt: > > > > http://pastebin.com/45PiHzLA > > > > Note that the code currently does not adhere to the Qt coding guidelines > (it > > follows ours instead), but if we do end up contributing it to Qt, then it > > should not be too difficult to bring it into line. > > Hi Craig > > It's not just the coding guideline, it's the architecture. I'm not a fan of > tool classes with virtuals... > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Sat Oct 22 16:14:48 2011 From: andre at familiesomers.nl (Andre Somers) Date: Sat, 22 Oct 2011 16:14:48 +0200 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> <2186814.CvKmP2Trg1@doriath> Message-ID: <4EA2CFD8.4010002@familiesomers.nl> Op 22-10-2011 15:52, Dhaivat Pandya schreef: > > Craig, > Do have any part of this class implemented? If its, people can test it > and see if it actually meets the users needs. > 2011/10/22 Thiago Macieira > > > On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au > wrote: > > With that out of the way, I've put the class definition up on > pastebin for > > comment. I've withheld the implementation until I've had a > chance to clear > > it with our legal people. In the meantime, I think the interface > of the > > class is probably enough to get some feedback on whether people > think this > > has the potential to be a viable candidate for a command line > parser for > > Qt: > > > Seems to me Craigs message was clear: yes, there is an implementation, but no, it is not available to the public for the time being because such a release must go through the companies legal department. Sounds reasonable to me. I have my doubts on the API. I don't really like the fact that subclassing is needed to use it. I prefer a solution where basic validation is build in, and more extended validation is possible (subclassing is OK to me for that case, but you could also considder a pattern like how QValidator is used.) André -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Sat Oct 22 16:34:15 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Sat, 22 Oct 2011 16:34:15 +0200 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: Hi, IMHO a proper implementation needs to be a QPA platform. Widgets need to be "drawn" in this "web" target, like in X11, Wayland, Windows, etc. The only change would be the low level primitives are HTML + CSS + JavaScript + SVG (and maybe even images), like Wt does. Trivia: the first version of Wt used Qt instead as the backend. They moved to Boost because of licensing (Qt was not LGPL back then) and threading. On Sat, Oct 22, 2011 at 10:55 AM, wrote: > >From my point of view: > > Having something here would be great. I don't think it should be part of > the essential Qt modules, but as an add-on it would be a very welcome > addition :) > > Cheers, > Lars > > On 10/22/11 7:09 AM, "ext Mark Constable" wrote: > > >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: > >> This seems like something that's way out there, and may have been > >> suggested before and rejected, but, I'm bringing it up anyway. What > >> would the Qt community think of a web framework devised around Qt? > > > >Speaking personally I'd love to see... > > > >. a web server similar to lighttpd but 100% based on Qt > > > >. a Qt5/V8 Javascript "engine" similar to NodeJS > > > >. an optional but builtin C++ FastCGI interface for the above > > > >In other words the essential tools for a Qt Server Side JavaScript > >solution, with Websocket support, so it can be as both a traditional > >webserver or a local backend to a HTML5/QML desktop system. > > > >Why another webserver when lighttpd, nginx, even apache, already exist > >as stable codebases? Because none of them allow me to build, develop > >and deploy them, and any web based projects, within QtCreator using > >CMake and Git. There is currently a complete development disconnect > >when deploying a typical HTTP based remote server within a Qt project. > > > >> Qt has all the stuff one needs to build a legitimate web framework, > >> connection to a scripting language (PySide, or any language with a C++ > >> API, such as Lua), Sql libraries, async socket libraries, XML, > >> everything. We just need some (okay, not some, a lot) of code to glue > >> this all together into a well knit package. I'll await suggestions. > > > >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt > > > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhaivatpandya at gmail.com Sat Oct 22 18:05:48 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 11:05:48 -0500 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: Okay, so, people do want this to happen. So, the first things we should decide would be what features/ideas one would need. I say: Now, IMHO, if we do make it a QPA by just changing the backend, that would be exactly like Wt. Also, even though desktop apps have been written like this for a very long time, webapps (again, IMHO) are better arranged as MVC. 1) Templates 2) MVC properly done 3) Some type of scaffolding script 4) The core needs to be extremely fast and async 5) Database requests are shifted off to another thread, etc. This is not possible (well, it is, but, not very useful) in languages such as Python, PHP, Ruby since they all use green threading, which works, but, isn't quite as fast. 6) Crash support, if something crashes, don't give a crazy error to the user, figure out where it crashed, write to logs, and the web developer uses an error page. Figuring out where it crashed is mostly where the work is done. 7) Qt libraries are used as much as possible 8) (this one needs community support to happen) Relation to scripting languages, such as Javascript, Lua, etc. What do you think? 2011/10/22 Pau Garcia i Quiles > Hi, > > IMHO a proper implementation needs to be a QPA platform. > > Widgets need to be "drawn" in this "web" target, like in X11, Wayland, > Windows, etc. The only change would be the low level primitives are HTML + > CSS + JavaScript + SVG (and maybe even images), like Wt does. > > Trivia: the first version of Wt used Qt instead as the backend. They moved > to Boost because of licensing (Qt was not LGPL back then) and threading. > > > > On Sat, Oct 22, 2011 at 10:55 AM, wrote: > >> >From my point of view: >> >> Having something here would be great. I don't think it should be part of >> the essential Qt modules, but as an add-on it would be a very welcome >> addition :) >> >> Cheers, >> Lars >> >> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >> >> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >> >> This seems like something that's way out there, and may have been >> >> suggested before and rejected, but, I'm bringing it up anyway. What >> >> would the Qt community think of a web framework devised around Qt? >> > >> >Speaking personally I'd love to see... >> > >> >. a web server similar to lighttpd but 100% based on Qt >> > >> >. a Qt5/V8 Javascript "engine" similar to NodeJS >> > >> >. an optional but builtin C++ FastCGI interface for the above >> > >> >In other words the essential tools for a Qt Server Side JavaScript >> >solution, with Websocket support, so it can be as both a traditional >> >webserver or a local backend to a HTML5/QML desktop system. >> > >> >Why another webserver when lighttpd, nginx, even apache, already exist >> >as stable codebases? Because none of them allow me to build, develop >> >and deploy them, and any web based projects, within QtCreator using >> >CMake and Git. There is currently a complete development disconnect >> >when deploying a typical HTTP based remote server within a Qt project. >> > >> >> Qt has all the stuff one needs to build a legitimate web framework, >> >> connection to a scripting language (PySide, or any language with a C++ >> >> API, such as Lua), Sql libraries, async socket libraries, XML, >> >> everything. We just need some (okay, not some, a lot) of code to glue >> >> this all together into a well knit package. I'll await suggestions. >> > >> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >> > >> >_______________________________________________ >> >Development mailing list >> >Development at qt-project.org >> >http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhaivatpandya at gmail.com Sat Oct 22 18:06:29 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 11:06:29 -0500 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <4EA2CFD8.4010002@familiesomers.nl> References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> <2186814.CvKmP2Trg1@doriath> <4EA2CFD8.4010002@familiesomers.nl> Message-ID: Oops, sorry, didn't read that too well. 2011/10/22 Andre Somers > Op 22-10-2011 15:52, Dhaivat Pandya schreef: > > > Craig, > > Do have any part of this class implemented? If its, people can test it and > see if it actually meets the users needs. > 2011/10/22 Thiago Macieira > >> On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au wrote: >> > With that out of the way, I've put the class definition up on pastebin >> for >> > comment. I've withheld the implementation until I've had a chance to >> clear >> > it with our legal people. In the meantime, I think the interface of the >> > class is probably enough to get some feedback on whether people think >> this >> > has the potential to be a viable candidate for a command line parser for >> > Qt: >> > >> > Seems to me Craigs message was clear: yes, there is an implementation, > but no, it is not available to the public for the time being because such a > release must go through the companies legal department. Sounds reasonable to > me. > > I have my doubts on the API. I don't really like the fact that subclassing > is needed to use it. I prefer a solution where basic validation is build in, > and more extended validation is possible (subclassing is OK to me for that > case, but you could also considder a pattern like how QValidator is used.) > > André > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Sat Oct 22 18:16:11 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Sat, 22 Oct 2011 18:16:11 +0200 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya wrote: > Okay, so, people do want this to happen. So, the first things we should > decide would be what features/ideas one would need. I say: > > Now, IMHO, if we do make it a QPA by just changing the backend, that would > be exactly like Wt. > Which is exactly what I'd like to see. I'm not asking for a web framework/library based on Qt, but for a new target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I would choose "cross-compile for web". The end result would be a FastCGI module, or a single executable which embeds its own web server (exactly like in Qt). Emweb has put a lot of thought into Wt, really. Also, even though desktop apps have been written like this for a very long > time, webapps (again, IMHO) are better arranged as MVC. > > 1) Templates > 2) MVC properly done > 3) Some type of scaffolding script > 4) The core needs to be extremely fast and async > 5) Database requests are shifted off to another thread, etc. This is not > possible (well, it is, but, not very useful) in languages such as Python, > PHP, Ruby since they all use green threading, which works, but, isn't quite > as fast. > 6) Crash support, if something crashes, don't give a crazy error to the > user, figure out where it crashed, write to logs, and the web developer uses > an error page. Figuring out where it crashed is mostly where the work is > done. > 7) Qt libraries are used as much as possible > 8) (this one needs community support to happen) Relation to scripting > languages, such as Javascript, Lua, etc. > > What do you think? > > I think there have been several projects trying that: Creole ( http://blogs.kde.org/node/3707 ) QtWui ( http://qtwui.sourceforge.net/ ) ... I want write once, compile everywhere. Even if that means having three "different" UIs (desktop, mobile, web), it would be a wonderful feature. See Gtk+ HTML5 backend. 2011/10/22 Pau Garcia i Quiles > >> Hi, >> >> IMHO a proper implementation needs to be a QPA platform. >> >> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >> Windows, etc. The only change would be the low level primitives are HTML + >> CSS + JavaScript + SVG (and maybe even images), like Wt does. >> >> Trivia: the first version of Wt used Qt instead as the backend. They moved >> to Boost because of licensing (Qt was not LGPL back then) and threading. >> >> >> >> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >> >>> >From my point of view: >>> >>> Having something here would be great. I don't think it should be part of >>> the essential Qt modules, but as an add-on it would be a very welcome >>> addition :) >>> >>> Cheers, >>> Lars >>> >>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>> >>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>> >> This seems like something that's way out there, and may have been >>> >> suggested before and rejected, but, I'm bringing it up anyway. What >>> >> would the Qt community think of a web framework devised around Qt? >>> > >>> >Speaking personally I'd love to see... >>> > >>> >. a web server similar to lighttpd but 100% based on Qt >>> > >>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>> > >>> >. an optional but builtin C++ FastCGI interface for the above >>> > >>> >In other words the essential tools for a Qt Server Side JavaScript >>> >solution, with Websocket support, so it can be as both a traditional >>> >webserver or a local backend to a HTML5/QML desktop system. >>> > >>> >Why another webserver when lighttpd, nginx, even apache, already exist >>> >as stable codebases? Because none of them allow me to build, develop >>> >and deploy them, and any web based projects, within QtCreator using >>> >CMake and Git. There is currently a complete development disconnect >>> >when deploying a typical HTTP based remote server within a Qt project. >>> > >>> >> Qt has all the stuff one needs to build a legitimate web framework, >>> >> connection to a scripting language (PySide, or any language with a C++ >>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>> >> everything. We just need some (okay, not some, a lot) of code to glue >>> >> this all together into a well knit package. I'll await suggestions. >>> > >>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>> > >>> >_______________________________________________ >>> >Development mailing list >>> >Development at qt-project.org >>> >http://lists.qt-project.org/mailman/listinfo/development >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin+qt at viroteck.net Sat Oct 22 19:01:56 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Sat, 22 Oct 2011 19:01:56 +0200 Subject: [Development] QtPim concerns In-Reply-To: References: Message-ID: Sigh... hit send too early, and from the wrong account. Sorry for the spam, CC'd folks. On Sat, Oct 22, 2011 at 6:59 PM, Robin Burchell wrote: > Hi, > > [nb: CCing some of the people who are probably concerned with QtPim, > but let's try keep relevant discussions on the ML for the benefit of > having things on record] > > I was taking around one of my personal areas of experience with an eye > to improving a few things - QtPim. > > I noticed a few things that bother me: > - the lost development history from the Qt Mobility repo > - the apparent lack of sync with Qt Mobility master changes > - some unit tests in a seemingly bad state (a number of them are > disabled, see qtpim/tests/auto/auto.pro) > > While I can help fix/workaround the last with some effort, I really > don't understand why this repository is in this state. > > Since there doesn't appear to have been much development on it so far > since its import, is it out of the question to suggest starting > 'fresh' somehow, ideally by keeping the history from Mobility (and > keeping the tests intact!), and merging in the new stuff which seems > to be undergoing work there (like the json contacts plugin)? This > would have a few benefits, like better test coverage, easier to merge > future fixes, and so on. > > If not, how are things proceeding? Is QtPim the place to work on > contacts/organizer APIs for Qt 5? What will happen to the version in > Mobility's master? And how will fixes be merged back to QtPim? > > Thanks, > > Robin > From dhaivatpandya at gmail.com Sat Oct 22 19:04:43 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 12:04:43 -0500 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: Here's my stance on that. If it is possible to keep the ability to write Javascript for custom UI widgets (or, C++ that generates a custom Javascript widget), I am for this. If not, it would very difficult to produce web apps that have some special "pizazz". Web development interfaces are quite different from desktop interfaces because - There are a ton of different browsers, mobile, web, etc. - All kinds of technologies one has to fix up Also, if that is done, all the existing code for Javascript (such as jQuery and the likes) cannot be used, unless the cross compiled C++ can work with existing Javascript. If that is possible (as I mentioned), I'm totally in for this idea, but, IMO, that is a difficult thing to accomplish. On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles wrote: > > > On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya wrote: > >> Okay, so, people do want this to happen. So, the first things we should >> decide would be what features/ideas one would need. I say: >> >> Now, IMHO, if we do make it a QPA by just changing the backend, that would >> be exactly like Wt. >> > > Which is exactly what I'd like to see. > > I'm not asking for a web framework/library based on Qt, but for a new > target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I > would choose "cross-compile for web". The end result would be a FastCGI > module, or a single executable which embeds its own web server (exactly like > in Qt). > > Emweb has put a lot of thought into Wt, really. > > > Also, even though desktop apps have been written like this for a very long >> time, webapps (again, IMHO) are better arranged as MVC. >> >> 1) Templates >> 2) MVC properly done >> 3) Some type of scaffolding script >> 4) The core needs to be extremely fast and async >> 5) Database requests are shifted off to another thread, etc. This is not >> possible (well, it is, but, not very useful) in languages such as Python, >> PHP, Ruby since they all use green threading, which works, but, isn't quite >> as fast. >> 6) Crash support, if something crashes, don't give a crazy error to the >> user, figure out where it crashed, write to logs, and the web developer uses >> an error page. Figuring out where it crashed is mostly where the work is >> done. >> 7) Qt libraries are used as much as possible >> 8) (this one needs community support to happen) Relation to scripting >> languages, such as Javascript, Lua, etc. >> >> What do you think? >> >> > I think there have been several projects trying that: > > Creole ( http://blogs.kde.org/node/3707 ) > QtWui ( http://qtwui.sourceforge.net/ ) > ... > > I want write once, compile everywhere. Even if that means having three > "different" UIs (desktop, mobile, web), it would be a wonderful feature. See > Gtk+ HTML5 backend. > > > > 2011/10/22 Pau Garcia i Quiles >> >>> Hi, >>> >>> IMHO a proper implementation needs to be a QPA platform. >>> >>> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >>> Windows, etc. The only change would be the low level primitives are HTML + >>> CSS + JavaScript + SVG (and maybe even images), like Wt does. >>> >>> Trivia: the first version of Wt used Qt instead as the backend. They >>> moved to Boost because of licensing (Qt was not LGPL back then) and >>> threading. >>> >>> >>> >>> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >>> >>>> >From my point of view: >>>> >>>> Having something here would be great. I don't think it should be part of >>>> the essential Qt modules, but as an add-on it would be a very welcome >>>> addition :) >>>> >>>> Cheers, >>>> Lars >>>> >>>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>>> >>>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>>> >> This seems like something that's way out there, and may have been >>>> >> suggested before and rejected, but, I'm bringing it up anyway. What >>>> >> would the Qt community think of a web framework devised around Qt? >>>> > >>>> >Speaking personally I'd love to see... >>>> > >>>> >. a web server similar to lighttpd but 100% based on Qt >>>> > >>>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>>> > >>>> >. an optional but builtin C++ FastCGI interface for the above >>>> > >>>> >In other words the essential tools for a Qt Server Side JavaScript >>>> >solution, with Websocket support, so it can be as both a traditional >>>> >webserver or a local backend to a HTML5/QML desktop system. >>>> > >>>> >Why another webserver when lighttpd, nginx, even apache, already exist >>>> >as stable codebases? Because none of them allow me to build, develop >>>> >and deploy them, and any web based projects, within QtCreator using >>>> >CMake and Git. There is currently a complete development disconnect >>>> >when deploying a typical HTTP based remote server within a Qt project. >>>> > >>>> >> Qt has all the stuff one needs to build a legitimate web framework, >>>> >> connection to a scripting language (PySide, or any language with a >>>> C++ >>>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>>> >> everything. We just need some (okay, not some, a lot) of code to glue >>>> >> this all together into a well knit package. I'll await suggestions. >>>> > >>>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>>> > >>>> >_______________________________________________ >>>> >Development mailing list >>>> >Development at qt-project.org >>>> >http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhaivatpandya at gmail.com Sat Oct 22 19:10:05 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 12:10:05 -0500 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: Another possibility is that (sorry for the multiple emails, I forgot to add some stuff) we can make the actual framework good enough and thorough enough that it basically kills the need for existing javascript frameworks. On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles wrote: > > > On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya wrote: > >> Okay, so, people do want this to happen. So, the first things we should >> decide would be what features/ideas one would need. I say: >> >> Now, IMHO, if we do make it a QPA by just changing the backend, that would >> be exactly like Wt. >> > > Which is exactly what I'd like to see. > > I'm not asking for a web framework/library based on Qt, but for a new > target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I > would choose "cross-compile for web". The end result would be a FastCGI > module, or a single executable which embeds its own web server (exactly like > in Qt). > > Emweb has put a lot of thought into Wt, really. > > > Also, even though desktop apps have been written like this for a very long >> time, webapps (again, IMHO) are better arranged as MVC. >> >> 1) Templates >> 2) MVC properly done >> 3) Some type of scaffolding script >> 4) The core needs to be extremely fast and async >> 5) Database requests are shifted off to another thread, etc. This is not >> possible (well, it is, but, not very useful) in languages such as Python, >> PHP, Ruby since they all use green threading, which works, but, isn't quite >> as fast. >> 6) Crash support, if something crashes, don't give a crazy error to the >> user, figure out where it crashed, write to logs, and the web developer uses >> an error page. Figuring out where it crashed is mostly where the work is >> done. >> 7) Qt libraries are used as much as possible >> 8) (this one needs community support to happen) Relation to scripting >> languages, such as Javascript, Lua, etc. >> >> What do you think? >> >> > I think there have been several projects trying that: > > Creole ( http://blogs.kde.org/node/3707 ) > QtWui ( http://qtwui.sourceforge.net/ ) > ... > > I want write once, compile everywhere. Even if that means having three > "different" UIs (desktop, mobile, web), it would be a wonderful feature. See > Gtk+ HTML5 backend. > > > > 2011/10/22 Pau Garcia i Quiles >> >>> Hi, >>> >>> IMHO a proper implementation needs to be a QPA platform. >>> >>> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >>> Windows, etc. The only change would be the low level primitives are HTML + >>> CSS + JavaScript + SVG (and maybe even images), like Wt does. >>> >>> Trivia: the first version of Wt used Qt instead as the backend. They >>> moved to Boost because of licensing (Qt was not LGPL back then) and >>> threading. >>> >>> >>> >>> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >>> >>>> >From my point of view: >>>> >>>> Having something here would be great. I don't think it should be part of >>>> the essential Qt modules, but as an add-on it would be a very welcome >>>> addition :) >>>> >>>> Cheers, >>>> Lars >>>> >>>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>>> >>>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>>> >> This seems like something that's way out there, and may have been >>>> >> suggested before and rejected, but, I'm bringing it up anyway. What >>>> >> would the Qt community think of a web framework devised around Qt? >>>> > >>>> >Speaking personally I'd love to see... >>>> > >>>> >. a web server similar to lighttpd but 100% based on Qt >>>> > >>>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>>> > >>>> >. an optional but builtin C++ FastCGI interface for the above >>>> > >>>> >In other words the essential tools for a Qt Server Side JavaScript >>>> >solution, with Websocket support, so it can be as both a traditional >>>> >webserver or a local backend to a HTML5/QML desktop system. >>>> > >>>> >Why another webserver when lighttpd, nginx, even apache, already exist >>>> >as stable codebases? Because none of them allow me to build, develop >>>> >and deploy them, and any web based projects, within QtCreator using >>>> >CMake and Git. There is currently a complete development disconnect >>>> >when deploying a typical HTTP based remote server within a Qt project. >>>> > >>>> >> Qt has all the stuff one needs to build a legitimate web framework, >>>> >> connection to a scripting language (PySide, or any language with a >>>> C++ >>>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>>> >> everything. We just need some (okay, not some, a lot) of code to glue >>>> >> this all together into a well knit package. I'll await suggestions. >>>> > >>>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>>> > >>>> >_______________________________________________ >>>> >Development mailing list >>>> >Development at qt-project.org >>>> >http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Sat Oct 22 19:11:25 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Sat, 22 Oct 2011 19:11:25 +0200 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: Hi, Have you ever used Wt? It does everything you say it's difficult. On Sat, Oct 22, 2011 at 7:04 PM, Dhaivat Pandya wrote: > Here's my stance on that. > If it is possible to keep the ability to write Javascript for custom UI > widgets (or, C++ that generates a custom Javascript widget), I am for this. > If not, it would very difficult to produce web apps that have some special > "pizazz". > > Web development interfaces are quite different from desktop interfaces > because > > - There are a ton of different browsers, mobile, web, etc. > - All kinds of technologies one has to fix up > > Also, if that is done, all the existing code for Javascript (such as jQuery > and the likes) cannot be used, unless the cross compiled C++ can work with > existing Javascript. If that is possible (as I mentioned), I'm totally in > for this idea, but, IMO, that is a difficult thing to accomplish. > > On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles < > pgquiles at elpauer.org> wrote: > >> >> >> On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya wrote: >> >>> Okay, so, people do want this to happen. So, the first things we should >>> decide would be what features/ideas one would need. I say: >>> >>> Now, IMHO, if we do make it a QPA by just changing the backend, that >>> would be exactly like Wt. >>> >> >> Which is exactly what I'd like to see. >> >> I'm not asking for a web framework/library based on Qt, but for a new >> target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I >> would choose "cross-compile for web". The end result would be a FastCGI >> module, or a single executable which embeds its own web server (exactly like >> in Qt). >> >> Emweb has put a lot of thought into Wt, really. >> >> >> Also, even though desktop apps have been written like this for a very long >>> time, webapps (again, IMHO) are better arranged as MVC. >>> >>> 1) Templates >>> 2) MVC properly done >>> 3) Some type of scaffolding script >>> 4) The core needs to be extremely fast and async >>> 5) Database requests are shifted off to another thread, etc. This is not >>> possible (well, it is, but, not very useful) in languages such as Python, >>> PHP, Ruby since they all use green threading, which works, but, isn't quite >>> as fast. >>> 6) Crash support, if something crashes, don't give a crazy error to the >>> user, figure out where it crashed, write to logs, and the web developer uses >>> an error page. Figuring out where it crashed is mostly where the work is >>> done. >>> 7) Qt libraries are used as much as possible >>> 8) (this one needs community support to happen) Relation to scripting >>> languages, such as Javascript, Lua, etc. >>> >>> What do you think? >>> >>> >> I think there have been several projects trying that: >> >> Creole ( http://blogs.kde.org/node/3707 ) >> QtWui ( http://qtwui.sourceforge.net/ ) >> ... >> >> I want write once, compile everywhere. Even if that means having three >> "different" UIs (desktop, mobile, web), it would be a wonderful feature. See >> Gtk+ HTML5 backend. >> >> >> >> 2011/10/22 Pau Garcia i Quiles >>> >>>> Hi, >>>> >>>> IMHO a proper implementation needs to be a QPA platform. >>>> >>>> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >>>> Windows, etc. The only change would be the low level primitives are HTML + >>>> CSS + JavaScript + SVG (and maybe even images), like Wt does. >>>> >>>> Trivia: the first version of Wt used Qt instead as the backend. They >>>> moved to Boost because of licensing (Qt was not LGPL back then) and >>>> threading. >>>> >>>> >>>> >>>> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >>>> >>>>> >From my point of view: >>>>> >>>>> Having something here would be great. I don't think it should be part >>>>> of >>>>> the essential Qt modules, but as an add-on it would be a very welcome >>>>> addition :) >>>>> >>>>> Cheers, >>>>> Lars >>>>> >>>>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>>>> >>>>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>>>> >> This seems like something that's way out there, and may have been >>>>> >> suggested before and rejected, but, I'm bringing it up anyway. What >>>>> >> would the Qt community think of a web framework devised around Qt? >>>>> > >>>>> >Speaking personally I'd love to see... >>>>> > >>>>> >. a web server similar to lighttpd but 100% based on Qt >>>>> > >>>>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>>>> > >>>>> >. an optional but builtin C++ FastCGI interface for the above >>>>> > >>>>> >In other words the essential tools for a Qt Server Side JavaScript >>>>> >solution, with Websocket support, so it can be as both a traditional >>>>> >webserver or a local backend to a HTML5/QML desktop system. >>>>> > >>>>> >Why another webserver when lighttpd, nginx, even apache, already exist >>>>> >as stable codebases? Because none of them allow me to build, develop >>>>> >and deploy them, and any web based projects, within QtCreator using >>>>> >CMake and Git. There is currently a complete development disconnect >>>>> >when deploying a typical HTTP based remote server within a Qt project. >>>>> > >>>>> >> Qt has all the stuff one needs to build a legitimate web framework, >>>>> >> connection to a scripting language (PySide, or any language with a >>>>> C++ >>>>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>>>> >> everything. We just need some (okay, not some, a lot) of code to >>>>> glue >>>>> >> this all together into a well knit package. I'll await suggestions. >>>>> > >>>>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>>>> > >>>>> >_______________________________________________ >>>>> >Development mailing list >>>>> >Development at qt-project.org >>>>> >http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>> >>>> >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>>> >>> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From qtnext at gmail.com Sat Oct 22 19:49:31 2011 From: qtnext at gmail.com (qtnext) Date: Sat, 22 Oct 2011 19:49:31 +0200 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: <4EA3022B.4090108@gmail.com> Hi, I think there is to side : - Server Side : - light web server with easy bridge with Qt - Websocket and Qt : there is an existing websocket lib for Qt : http://gitorious.org/qtwebsocket - and the dream : the client side : - for me a QML translator to javascript : perhaps in the same GWT (google) do There is a lot of related thread in qt list, forum and there is a lot of library around server or client web side. for example : http://developer.qt.nokia.com/forums/viewthread/4347 Perhaps the start is to have a list of all available lib around Qt + web, contact all the people around these libs, and start to have a coherent package ? Le 22/10/2011 19:11, Pau Garcia i Quiles a écrit : > Hi, > > Have you ever used Wt? > > It does everything you say it's difficult. > > > On Sat, Oct 22, 2011 at 7:04 PM, Dhaivat Pandya > > wrote: > > Here's my stance on that. > If it is possible to keep the ability to write Javascript for > custom UI widgets (or, C++ that generates a custom Javascript > widget), I am for this. If not, it would very difficult to produce > web apps that have some special "pizazz". > > Web development interfaces are quite different from desktop > interfaces because > > * There are a ton of different browsers, mobile, web, etc. > * All kinds of technologies one has to fix up > > Also, if that is done, all the existing code for Javascript (such > as jQuery and the likes) cannot be used, unless the cross compiled > C++ can work with existing Javascript. If that is possible (as I > mentioned), I'm totally in for this idea, but, IMO, that is a > difficult thing to accomplish. > > On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles > > wrote: > > > > On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya > > wrote: > > Okay, so, people do want this to happen. So, the first > things we should decide would be what features/ideas one > would need. I say: > > Now, IMHO, if we do make it a QPA by just changing the > backend, that would be exactly like Wt. > > > Which is exactly what I'd like to see. > > I'm not asking for a web framework/library based on Qt, but > for a new target for Qt: instead of compiling for Windows, > Linux, Symbian or MeeGo, I would choose "cross-compile for > web". The end result would be a FastCGI module, or a single > executable which embeds its own web server (exactly like in Qt). > > Emweb has put a lot of thought into Wt, really. > > > Also, even though desktop apps have been written like this > for a very long time, webapps (again, IMHO) are better > arranged as MVC. > > 1) Templates > 2) MVC properly done > 3) Some type of scaffolding script > 4) The core needs to be extremely fast and async > 5) Database requests are shifted off to another thread, > etc. This is not possible (well, it is, but, not very > useful) in languages such as Python, PHP, Ruby since they > all use green threading, which works, but, isn't quite as > fast. > 6) Crash support, if something crashes, don't give a crazy > error to the user, figure out where it crashed, write to > logs, and the web developer uses an error page. Figuring > out where it crashed is mostly where the work is done. > 7) Qt libraries are used as much as possible > 8) (this one needs community support to happen) Relation > to scripting languages, such as Javascript, Lua, etc. > > What do you think? > > > I think there have been several projects trying that: > > Creole ( http://blogs.kde.org/node/3707 ) > QtWui ( http://qtwui.sourceforge.net/ ) > ... > > I want write once, compile everywhere. Even if that means > having three "different" UIs (desktop, mobile, web), it would > be a wonderful feature. See Gtk+ HTML5 backend. > > > > 2011/10/22 Pau Garcia i Quiles > > > Hi, > > IMHO a proper implementation needs to be a QPA platform. > > Widgets need to be "drawn" in this "web" target, like > in X11, Wayland, Windows, etc. The only change would > be the low level primitives are HTML + CSS + > JavaScript + SVG (and maybe even images), like Wt does. > > Trivia: the first version of Wt used Qt instead as the > backend. They moved to Boost because of licensing (Qt > was not LGPL back then) and threading. > > > > On Sat, Oct 22, 2011 at 10:55 AM, > > > wrote: > > >From my point of view: > > Having something here would be great. I don't > think it should be part of > the essential Qt modules, but as an add-on it > would be a very welcome > addition :) > > Cheers, > Lars > > On 10/22/11 7:09 AM, "ext Mark Constable" > > wrote: > > >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: > >> This seems like something that's way out there, > and may have been > >> suggested before and rejected, but, I'm > bringing it up anyway. What > >> would the Qt community think of a web framework > devised around Qt? > > > >Speaking personally I'd love to see... > > > >. a web server similar to lighttpd but 100% based > on Qt > > > >. a Qt5/V8 Javascript "engine" similar to NodeJS > > > >. an optional but builtin C++ FastCGI interface > for the above > > > >In other words the essential tools for a Qt > Server Side JavaScript > >solution, with Websocket support, so it can be as > both a traditional > >webserver or a local backend to a HTML5/QML > desktop system. > > > >Why another webserver when lighttpd, nginx, even > apache, already exist > >as stable codebases? Because none of them allow > me to build, develop > >and deploy them, and any web based projects, > within QtCreator using > >CMake and Git. There is currently a complete > development disconnect > >when deploying a typical HTTP based remote server > within a Qt project. > > > >> Qt has all the stuff one needs to build a > legitimate web framework, > >> connection to a scripting language (PySide, or > any language with a C++ > >> API, such as Lua), Sql libraries, async socket > libraries, XML, > >> everything. We just need some (okay, not some, > a lot) of code to glue > >> this all together into a well knit package. > I'll await suggestions. > > > >Wouldn't Wt provide a lot of that? > http://www.webtoolkit.eu/wt > > > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > > >http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > _______________________________________________ > Development mailing list > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhaivatpandya at gmail.com Sat Oct 22 20:20:07 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 13:20:07 -0500 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: To be honest, I've never used Wt (I have gone over the docs, and written a few small applications). If it is possible to do all of that, I would agree to it. However, I would still like to see (and probably so would others before we move forward), what more people think of this. Something like Wt (desktop development on the web, cross compilation) or a traditional web framework based on Qt and C++. So, feedback would be good. If someone can start a poll, that would be even better. On Sat, Oct 22, 2011 at 12:11 PM, Pau Garcia i Quiles wrote: > Hi, > > Have you ever used Wt? > > It does everything you say it's difficult. > > > > On Sat, Oct 22, 2011 at 7:04 PM, Dhaivat Pandya wrote: > >> Here's my stance on that. >> If it is possible to keep the ability to write Javascript for custom UI >> widgets (or, C++ that generates a custom Javascript widget), I am for this. >> If not, it would very difficult to produce web apps that have some special >> "pizazz". >> >> Web development interfaces are quite different from desktop interfaces >> because >> >> - There are a ton of different browsers, mobile, web, etc. >> - All kinds of technologies one has to fix up >> >> Also, if that is done, all the existing code for Javascript (such as >> jQuery and the likes) cannot be used, unless the cross compiled C++ can work >> with existing Javascript. If that is possible (as I mentioned), I'm totally >> in for this idea, but, IMO, that is a difficult thing to accomplish. >> >> On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles < >> pgquiles at elpauer.org> wrote: >> >>> >>> >>> On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya >> > wrote: >>> >>>> Okay, so, people do want this to happen. So, the first things we should >>>> decide would be what features/ideas one would need. I say: >>>> >>>> Now, IMHO, if we do make it a QPA by just changing the backend, that >>>> would be exactly like Wt. >>>> >>> >>> Which is exactly what I'd like to see. >>> >>> I'm not asking for a web framework/library based on Qt, but for a new >>> target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I >>> would choose "cross-compile for web". The end result would be a FastCGI >>> module, or a single executable which embeds its own web server (exactly like >>> in Qt). >>> >>> Emweb has put a lot of thought into Wt, really. >>> >>> >>> Also, even though desktop apps have been written like this for a very >>>> long time, webapps (again, IMHO) are better arranged as MVC. >>>> >>>> 1) Templates >>>> 2) MVC properly done >>>> 3) Some type of scaffolding script >>>> 4) The core needs to be extremely fast and async >>>> 5) Database requests are shifted off to another thread, etc. This is not >>>> possible (well, it is, but, not very useful) in languages such as Python, >>>> PHP, Ruby since they all use green threading, which works, but, isn't quite >>>> as fast. >>>> 6) Crash support, if something crashes, don't give a crazy error to the >>>> user, figure out where it crashed, write to logs, and the web developer uses >>>> an error page. Figuring out where it crashed is mostly where the work is >>>> done. >>>> 7) Qt libraries are used as much as possible >>>> 8) (this one needs community support to happen) Relation to scripting >>>> languages, such as Javascript, Lua, etc. >>>> >>>> What do you think? >>>> >>>> >>> I think there have been several projects trying that: >>> >>> Creole ( http://blogs.kde.org/node/3707 ) >>> QtWui ( http://qtwui.sourceforge.net/ ) >>> ... >>> >>> I want write once, compile everywhere. Even if that means having three >>> "different" UIs (desktop, mobile, web), it would be a wonderful feature. See >>> Gtk+ HTML5 backend. >>> >>> >>> >>> 2011/10/22 Pau Garcia i Quiles >>>> >>>>> Hi, >>>>> >>>>> IMHO a proper implementation needs to be a QPA platform. >>>>> >>>>> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >>>>> Windows, etc. The only change would be the low level primitives are HTML + >>>>> CSS + JavaScript + SVG (and maybe even images), like Wt does. >>>>> >>>>> Trivia: the first version of Wt used Qt instead as the backend. They >>>>> moved to Boost because of licensing (Qt was not LGPL back then) and >>>>> threading. >>>>> >>>>> >>>>> >>>>> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >>>>> >>>>>> >From my point of view: >>>>>> >>>>>> Having something here would be great. I don't think it should be part >>>>>> of >>>>>> the essential Qt modules, but as an add-on it would be a very welcome >>>>>> addition :) >>>>>> >>>>>> Cheers, >>>>>> Lars >>>>>> >>>>>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>>>>> >>>>>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>>>>> >> This seems like something that's way out there, and may have been >>>>>> >> suggested before and rejected, but, I'm bringing it up anyway. What >>>>>> >> would the Qt community think of a web framework devised around Qt? >>>>>> > >>>>>> >Speaking personally I'd love to see... >>>>>> > >>>>>> >. a web server similar to lighttpd but 100% based on Qt >>>>>> > >>>>>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>>>>> > >>>>>> >. an optional but builtin C++ FastCGI interface for the above >>>>>> > >>>>>> >In other words the essential tools for a Qt Server Side JavaScript >>>>>> >solution, with Websocket support, so it can be as both a traditional >>>>>> >webserver or a local backend to a HTML5/QML desktop system. >>>>>> > >>>>>> >Why another webserver when lighttpd, nginx, even apache, already >>>>>> exist >>>>>> >as stable codebases? Because none of them allow me to build, develop >>>>>> >and deploy them, and any web based projects, within QtCreator using >>>>>> >CMake and Git. There is currently a complete development disconnect >>>>>> >when deploying a typical HTTP based remote server within a Qt >>>>>> project. >>>>>> > >>>>>> >> Qt has all the stuff one needs to build a legitimate web framework, >>>>>> >> connection to a scripting language (PySide, or any language with a >>>>>> C++ >>>>>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>>>>> >> everything. We just need some (okay, not some, a lot) of code to >>>>>> glue >>>>>> >> this all together into a well knit package. I'll await suggestions. >>>>>> > >>>>>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>>>>> > >>>>>> >_______________________________________________ >>>>>> >Development mailing list >>>>>> >Development at qt-project.org >>>>>> >http://lists.qt-project.org/mailman/listinfo/development >>>>>> >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pau Garcia i Quiles >>>>> http://www.elpauer.org >>>>> (Due to my workload, I may need 10 days to answer) >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> >>>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >> >> > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xizhi.zhu at nokia.com Sat Oct 22 22:33:23 2011 From: xizhi.zhu at nokia.com (xizhi.zhu at nokia.com) Date: Sat, 22 Oct 2011 20:33:23 +0000 Subject: [Development] QtPim concerns In-Reply-To: References: Message-ID: <96E5B115E1BBE3468DCD10CE357A4C7E0871F6DA@008-AM1MPN1-021.mgdnok.nokia.com> Hi, Hope I can answer something here... As far as I understand, we lost the commit history of all modules when importing from QtMobility. As of now, QtPim includes contacts, organizer and versit from QtM, and future development should happen in QtPim, and only bug fixes are expected in QtM. Some tests are commented out just because they are failing, and we are working to fix them. For sure, it's our target to get a higher coverage and better quality. Currently, we are doing some refactoring / improvement for the APIs (mainly limiting some unnecessary flexibility and reducing some complexity), so probably it's further impacting our tests and merging from QtM. -- Sent from my Nokia N9 On 22.10.2011 20:02 ext Robin Burchell wrote: Sigh... hit send too early, and from the wrong account. Sorry for the spam, CC'd folks. On Sat, Oct 22, 2011 at 6:59 PM, Robin Burchell wrote: > Hi, > > [nb: CCing some of the people who are probably concerned with QtPim, > but let's try keep relevant discussions on the ML for the benefit of > having things on record] > > I was taking around one of my personal areas of experience with an eye > to improving a few things - QtPim. > > I noticed a few things that bother me: > - the lost development history from the Qt Mobility repo > - the apparent lack of sync with Qt Mobility master changes > - some unit tests in a seemingly bad state (a number of them are > disabled, see qtpim/tests/auto/auto.pro) > > While I can help fix/workaround the last with some effort, I really > don't understand why this repository is in this state. > > Since there doesn't appear to have been much development on it so far > since its import, is it out of the question to suggest starting > 'fresh' somehow, ideally by keeping the history from Mobility (and > keeping the tests intact!), and merging in the new stuff which seems > to be undergoing work there (like the json contacts plugin)? This > would have a few benefits, like better test coverage, easier to merge > future fixes, and so on. > > If not, how are things proceeding? Is QtPim the place to work on > contacts/organizer APIs for Qt 5? What will happen to the version in > Mobility's master? And how will fixes be merged back to QtPim? > > Thanks, > > Robin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin+qt at viroteck.net Sat Oct 22 23:53:13 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Sat, 22 Oct 2011 23:53:13 +0200 Subject: [Development] QtPim concerns In-Reply-To: <96E5B115E1BBE3468DCD10CE357A4C7E0871F6DA@008-AM1MPN1-021.mgdnok.nokia.com> References: <96E5B115E1BBE3468DCD10CE357A4C7E0871F6DA@008-AM1MPN1-021.mgdnok.nokia.com> Message-ID: Hi, (dropping 'mikko' from CC, since I got his address wrong, I'll forward him a link to the thread) First up, thanks for your reply! On Sat, Oct 22, 2011 at 10:33 PM, wrote: > As far as I understand, we lost the commit history of all modules when > importing from QtMobility. Yes, looks that way. But it shouldn't have been impossible to keep that, right? Is it early enough that we can invest some time to try go back and do that *now*, given the advantages in terms of being able to find the context of why changes were made? > As of now, QtPim includes contacts, organizer and versit from QtM, and > future development should happen in QtPim, and only bug fixes are expected > in QtM. OK, thanks for the clarification. > Some tests are commented out just because they are failing, and we are > working to fix them. For sure, it's our target to get a higher coverage and > better quality. OK, as I suspected. What's your feeling on patches implementing new tests, for e.g. QDeclarativeContactModel, which is one of my first 'victims' with a few patches? > Currently, we are doing some refactoring / improvement for the APIs (mainly > limiting some unnecessary flexibility and reducing some complexity), so > probably it's further impacting our tests and merging from QtM. At least for the tests part, it shouldn't be. I think in an ideal world, you should be doing your best to follow your refactoring with test updates, and using those test results to make sure that nothing is breaking. I understand that this isn't strictly *always* possible, but that should be the exception, not the norm as much as possible. That's why, for instance, I'm talking about *creating* unit tests for QDCM before I even touch it. Because I don't want to break it. It does complicate the QtM merge situation a bit more, yeah. I guess we'll just have to manage that, somehow. thanks, Robin From Craig.Scott at csiro.au Sun Oct 23 00:51:54 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Sun, 23 Oct 2011 09:51:54 +1100 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <2186814.CvKmP2Trg1@doriath> References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> <2186814.CvKmP2Trg1@doriath> Message-ID: On 22/10/2011, at 10:44 PM, Thiago Macieira wrote: > On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au wrote: >> With that out of the way, I've put the class definition up on pastebin for >> comment. I've withheld the implementation until I've had a chance to clear >> it with our legal people. In the meantime, I think the interface of the >> class is probably enough to get some feedback on whether people think this >> has the potential to be a viable candidate for a command line parser for >> Qt: >> >> http://pastebin.com/45PiHzLA >> >> Note that the code currently does not adhere to the Qt coding guidelines (it >> follows ours instead), but if we do end up contributing it to Qt, then it >> should not be too difficult to bring it into line. > > Hi Craig > > It's not just the coding guideline, it's the architecture. I'm not a fan of > tool classes with virtuals... > The usage() function should not have been virtual in the first place and could be easily made non-virtual without lose of functionality, so that just leaves validate(). One could potentially leave validate() as non-pure virtual if you want to allow subclasses to not bother validating, but I think that's sending the wrong message to developers. Seems like a poor compromise just to allow people to use the class without having to subclass it. If you want to validate your flags/arguments, you are either going to have to create a new class for it at some point (in which case why not use a virtual validate since you are creating a new class anyway), or you are going to have to inline your validation in the code where you make use of the flags. I guess that latter case seems justifiable, but I'd personally prefer to see all the argument handling code within the one (sub)class - one class, one responsibility and all that. But I do think there's value in making the class encourage devs towards thinking about validation. I've already seen that in our code, it has had the effect that devs think about and implement validation as they go rather than "getting around to it" later. That said, if you have suggestions for how to achieve the same goals without using a virtual function, I'm open to it. The cases I've seen so far though just seen unnecessarily complex compared to the simplicity of the approach we've gone with. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From Craig.Scott at csiro.au Sun Oct 23 00:58:25 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Sun, 23 Oct 2011 09:58:25 +1100 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <4EA2CFD8.4010002@familiesomers.nl> References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> <2186814.CvKmP2Trg1@doriath> <4EA2CFD8.4010002@familiesomers.nl> Message-ID: <0F787CA3-0551-47AD-9B5D-5698F7BA91F1@csiro.au> On 23/10/2011, at 1:14 AM, Andre Somers wrote: Op 22-10-2011 15:52, Dhaivat Pandya schreef: Craig, Do have any part of this class implemented? If its, people can test it and see if it actually meets the users needs. 2011/10/22 Thiago Macieira > On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au wrote: > With that out of the way, I've put the class definition up on pastebin for > comment. I've withheld the implementation until I've had a chance to clear > it with our legal people. In the meantime, I think the interface of the > class is probably enough to get some feedback on whether people think this > has the potential to be a viable candidate for a command line parser for > Qt: > Seems to me Craigs message was clear: yes, there is an implementation, but no, it is not available to the public for the time being because such a release must go through the companies legal department. Sounds reasonable to me. I have my doubts on the API. I don't really like the fact that subclassing is needed to use it. I prefer a solution where basic validation is build in, and more extended validation is possible (subclassing is OK to me for that case, but you could also considder a pattern like how QValidator is used.) What do you mean by basic validation? The code you include in Qt cannot know what each of your flags mean, so only you can implement validation on whether or not the flags and arguments form a sane combination. We started out thinking along a similar line, but it turns out there's not really anything that the base class can validate! Since arguments and flags can be intermingled, you can't even test whether a multi-parameter flag has all required parameters unless it is the last one on the command line (which is about the only thing I think the base class can actually validate for you). Not sure what your point is with the QValidator approach, since it uses the same approach as the class I proposed. QValidator has a pure virtual validate() function too! If you mean that there are a couple of standardish subclasses of QValidator provided, I come back to my above point that there isn't really much you can pre-build as far as flag/argument validation is concerned. Anything that isn't recognised as a flag is treated as an argument, so there's not much left to validate automatically. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From Craig.Scott at csiro.au Sun Oct 23 01:03:24 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Sun, 23 Oct 2011 10:03:24 +1100 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <0F787CA3-0551-47AD-9B5D-5698F7BA91F1@csiro.au> References: <3622471.a3Al887bxZ@doriath> <85C7EA58-C318-4C7F-BFE5-F9820D145245@csiro.au> <2186814.CvKmP2Trg1@doriath> <4EA2CFD8.4010002@familiesomers.nl> <0F787CA3-0551-47AD-9B5D-5698F7BA91F1@csiro.au> Message-ID: <1EE0155F-5193-4476-803C-DC2529C93C8E@csiro.au> Apologies for the dud quoting. Seems I'm still having some issues with working out my mail client. ;) On 23/10/2011, at 9:58 AM, wrote: > > On 23/10/2011, at 1:14 AM, Andre Somers wrote: > > Op 22-10-2011 15:52, Dhaivat Pandya schreef: > > Craig, > > Do have any part of this class implemented? If its, people can test it and see if it actually meets the users needs. > 2011/10/22 Thiago Macieira > > On Saturday, 22 de October de 2011 11:29:38 Craig.Scott at csiro.au wrote: >> With that out of the way, I've put the class definition up on pastebin for >> comment. I've withheld the implementation until I've had a chance to clear >> it with our legal people. In the meantime, I think the interface of the >> class is probably enough to get some feedback on whether people think this >> has the potential to be a viable candidate for a command line parser for >> Qt: >> > Seems to me Craigs message was clear: yes, there is an implementation, but no, it is not available to the public for the time being because such a release must go through the companies legal department. Sounds reasonable to me. > > I have my doubts on the API. I don't really like the fact that subclassing is needed to use it. I prefer a solution where basic validation is build in, and more extended validation is possible (subclassing is OK to me for that case, but you could also considder a pattern like how QValidator is used.) > > What do you mean by basic validation? The code you include in Qt cannot know what each of your flags mean, so only you can implement validation on whether or not the flags and arguments form a sane combination. We started out thinking along a similar line, but it turns out there's not really anything that the base class can validate! Since arguments and flags can be intermingled, you can't even test whether a multi-parameter flag has all required parameters unless it is the last one on the command line (which is about the only thing I think the base class can actually validate for you). > > Not sure what your point is with the QValidator approach, since it uses the same approach as the class I proposed. QValidator has a pure virtual validate() function too! If you mean that there are a couple of standardish subclasses of QValidator provided, I come back to my above point that there isn't really much you can pre-build as far as flag/argument validation is concerned. Anything that isn't recognised as a flag is treated as an argument, so there's not much left to validate automatically. > > > -- > Dr Craig Scott > Computational Software Engineering Team Leader, CSIRO (CMIS) > Melbourne, Australia > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From Craig.Scott at csiro.au Sun Oct 23 01:13:41 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Sun, 23 Oct 2011 10:13:41 +1100 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: References: Message-ID: <562977D1-27F5-4C9D-A41A-BC68910162B5@csiro.au> On 23/10/2011, at 1:43 AM, Pau Garcia i Quiles wrote: Hi, Have you tried QCommandLine? http://xf.iksaif.net/dev/qcommandline.html http://gitorious.org/qcommandline No, I hadn't seen that. Looking at the example usage though, I can see one immediate drawback. It uses signals and slots to tell you what flags, switches, etc. it finds during parsing. This means at the time you find out about a flag, you only know about the things that have been parsed up to that point on the command line. It doesn't give you a global view of all the flags/arguments that were provided (or not provided!) on the command line. That makes validation harder, so you would have to do your validation after your call to parse(). It also tends to fragment your flag/argument handling by requiring each one to have its own slot. Seems overly verbose to me. I also find that there isn't really a need to differentiate between switches, flags and options so explicitly. Much of this is implied by whether or not your flag has parameters associated with it. Maybe there's some useful cases where this isn't true, but we've found the simplicity of the approach we've taken makes it really easy to work with and understand. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From jlayt at kde.org Sun Oct 23 01:35:06 2011 From: jlayt at kde.org (John Layt) Date: Sun, 23 Oct 2011 00:35:06 +0100 Subject: [Development] QLocale changes Message-ID: <1483280.Ez32sQab0I@argo.layt.net> Hi, Following on from my QDateTime changes to QLocale, there's a few other areas I want to look into. 1) The following methods currently return QChar and as noted in the code need to change to QString: // ### Qt 5: We need to return QString from these function since // unicode data contains several characters for these fields. QChar decimalPoint() const; QChar groupSeparator() const; QChar percent() const; QChar zeroDigit() const; QChar negativeSign() const; QChar positiveSign() const; QChar exponential() const; I've started on this, but run into the problem that these methods are used in the number parsers which operate a QChar at a time. I would have to modify or rewrite the parsers which is no small task, but the api change needs to be done for 5.0. An interim step might be to change the api to QString now but still only return the current 1 char values until the parsers can be adapted. 2) While doing (1), I could also add support for the System/CLDR values for NAN, Infinity and Per Mille which are currently hard-coded. 2) Local Week Number systems, i.e US weeks 3) Numbering Systems (aka Digit Sets in KDE) 4) Change MeasurementSystem to use the supplemental CLDR data 5) Change default country for language to use the CLDR LanguageMatching data 6) Clean up QSystemLocale platform implementations to have more consistent style, more complete support Of these only 1) really needs to happen for 5.0. Now for the KDE wishlist. For KDE Frameworks 5 we want to switch to using QLocale, and QLocale now meets our requirements except for the key ability for our users to modify individual locale settings. While we can write a custom QSystemLocale to load the KDE settings, there is no way to query all the current settings to show them to the user in System Settings. At QtCS I briefly discussed this with Denis and also QSystemLocale which neither of us are too happy with. Denis indicated he was open to a different approach for QSystemLocale and KDE settings so long as QLocale itself was kept clean and simple for apps, i.e. no getters or setters for all the settings. Currently we have QLocale which is mostly formatters/parsers with a few methods to return certain settings, but many settings are not exposed. We then have QSystemLocale which returns what the current host system settings are where supported. QLocale first queries QSystemLocale for settings and if none is returned then falls back to the CLDR settings. If not using the default system locale, or support is disabled, then QSystemLocale is not queried and the CLDR values are always used The problem with QSystemLocale is it only tells you what the system locale setting for something is, and only if that setting is supported, but not what the CLDR fallback value is, which means KDE will be unable to query for the values it wants. I see two possible solutions: 1) Have QSystemLocale return the CLDR setting if it doesn't find or support the system setting, or have a QSystemLocale just for CLDR. 2) Have a new QLocaleSettings class that returns either the system or CLDR value as appopriate. The big problem with 1) is that QSystemLocale is an optional feature so moving all the CLDR look-up code there would break things, and I wouldn't want to duplicate code either. Also it's not a nice api. Option 2) would probably look like this: * QLocale is the app facing api providing just those methods an average app needs to use, i.e. mostly just formatters and parsers like toString() and toInt() and not the format settings like decimalPoint(). It also keeps the locale name/code parts, i.e. Language, Country, etc. * QLocaleSettings is the platform facing api for those few people who need it (i.e. KDE System Settings module, some specialised apps). This provides direct api access to each setting like decimalPoint(). All the CLDR lookup code gets moved here, and a method first looks up the QSystemLocale value if enabled before defaulting to the CLDR value if needed. QLocale calls these methods when it needs to find out what setting to use. QLocale also provides a method to access the current QLocaleSettings it is using. Effectively it's QLocale with the parser/fomatters removed and a new setitngs api added. * QSystemLocale remains the same, using the virtual query() method and enum to return the system setting, just extended over time with more settings. The down side here is it adds a slightly unnecessary layer to everything. Thoughts? Jhn. From dhaivatpandya at gmail.com Sun Oct 23 03:32:44 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Sat, 22 Oct 2011 20:32:44 -0500 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: Any more feedback from anyone? The current situation seems to support a more traditional web framework more. On Sat, Oct 22, 2011 at 1:20 PM, Dhaivat Pandya wrote: > To be honest, I've never used Wt (I have gone over the docs, and written a > few small applications). > > If it is possible to do all of that, I would agree to it. However, I would > still like to see (and probably so would others before we move forward), > what more people think of this. > > Something like Wt (desktop development on the web, cross compilation) or a > traditional web framework based on Qt and C++. > So, feedback would be good. > > If someone can start a poll, that would be even better. > > On Sat, Oct 22, 2011 at 12:11 PM, Pau Garcia i Quiles < > pgquiles at elpauer.org> wrote: > >> Hi, >> >> Have you ever used Wt? >> >> It does everything you say it's difficult. >> >> >> >> On Sat, Oct 22, 2011 at 7:04 PM, Dhaivat Pandya wrote: >> >>> Here's my stance on that. >>> If it is possible to keep the ability to write Javascript for custom UI >>> widgets (or, C++ that generates a custom Javascript widget), I am for this. >>> If not, it would very difficult to produce web apps that have some special >>> "pizazz". >>> >>> Web development interfaces are quite different from desktop interfaces >>> because >>> >>> - There are a ton of different browsers, mobile, web, etc. >>> - All kinds of technologies one has to fix up >>> >>> Also, if that is done, all the existing code for Javascript (such as >>> jQuery and the likes) cannot be used, unless the cross compiled C++ can work >>> with existing Javascript. If that is possible (as I mentioned), I'm totally >>> in for this idea, but, IMO, that is a difficult thing to accomplish. >>> >>> On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles < >>> pgquiles at elpauer.org> wrote: >>> >>>> >>>> >>>> On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya < >>>> dhaivatpandya at gmail.com> wrote: >>>> >>>>> Okay, so, people do want this to happen. So, the first things we should >>>>> decide would be what features/ideas one would need. I say: >>>>> >>>>> Now, IMHO, if we do make it a QPA by just changing the backend, that >>>>> would be exactly like Wt. >>>>> >>>> >>>> Which is exactly what I'd like to see. >>>> >>>> I'm not asking for a web framework/library based on Qt, but for a new >>>> target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I >>>> would choose "cross-compile for web". The end result would be a FastCGI >>>> module, or a single executable which embeds its own web server (exactly like >>>> in Qt). >>>> >>>> Emweb has put a lot of thought into Wt, really. >>>> >>>> >>>> Also, even though desktop apps have been written like this for a very >>>>> long time, webapps (again, IMHO) are better arranged as MVC. >>>>> >>>>> 1) Templates >>>>> 2) MVC properly done >>>>> 3) Some type of scaffolding script >>>>> 4) The core needs to be extremely fast and async >>>>> 5) Database requests are shifted off to another thread, etc. This is >>>>> not possible (well, it is, but, not very useful) in languages such as >>>>> Python, PHP, Ruby since they all use green threading, which works, but, >>>>> isn't quite as fast. >>>>> 6) Crash support, if something crashes, don't give a crazy error to the >>>>> user, figure out where it crashed, write to logs, and the web developer uses >>>>> an error page. Figuring out where it crashed is mostly where the work is >>>>> done. >>>>> 7) Qt libraries are used as much as possible >>>>> 8) (this one needs community support to happen) Relation to scripting >>>>> languages, such as Javascript, Lua, etc. >>>>> >>>>> What do you think? >>>>> >>>>> >>>> I think there have been several projects trying that: >>>> >>>> Creole ( http://blogs.kde.org/node/3707 ) >>>> QtWui ( http://qtwui.sourceforge.net/ ) >>>> ... >>>> >>>> I want write once, compile everywhere. Even if that means having three >>>> "different" UIs (desktop, mobile, web), it would be a wonderful feature. See >>>> Gtk+ HTML5 backend. >>>> >>>> >>>> >>>> 2011/10/22 Pau Garcia i Quiles >>>>> >>>>>> Hi, >>>>>> >>>>>> IMHO a proper implementation needs to be a QPA platform. >>>>>> >>>>>> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >>>>>> Windows, etc. The only change would be the low level primitives are HTML + >>>>>> CSS + JavaScript + SVG (and maybe even images), like Wt does. >>>>>> >>>>>> Trivia: the first version of Wt used Qt instead as the backend. They >>>>>> moved to Boost because of licensing (Qt was not LGPL back then) and >>>>>> threading. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >>>>>> >>>>>>> >From my point of view: >>>>>>> >>>>>>> Having something here would be great. I don't think it should be part >>>>>>> of >>>>>>> the essential Qt modules, but as an add-on it would be a very welcome >>>>>>> addition :) >>>>>>> >>>>>>> Cheers, >>>>>>> Lars >>>>>>> >>>>>>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>>>>>> >>>>>>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>>>>>> >> This seems like something that's way out there, and may have been >>>>>>> >> suggested before and rejected, but, I'm bringing it up anyway. >>>>>>> What >>>>>>> >> would the Qt community think of a web framework devised around Qt? >>>>>>> > >>>>>>> >Speaking personally I'd love to see... >>>>>>> > >>>>>>> >. a web server similar to lighttpd but 100% based on Qt >>>>>>> > >>>>>>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>>>>>> > >>>>>>> >. an optional but builtin C++ FastCGI interface for the above >>>>>>> > >>>>>>> >In other words the essential tools for a Qt Server Side JavaScript >>>>>>> >solution, with Websocket support, so it can be as both a traditional >>>>>>> >webserver or a local backend to a HTML5/QML desktop system. >>>>>>> > >>>>>>> >Why another webserver when lighttpd, nginx, even apache, already >>>>>>> exist >>>>>>> >as stable codebases? Because none of them allow me to build, develop >>>>>>> >and deploy them, and any web based projects, within QtCreator using >>>>>>> >CMake and Git. There is currently a complete development disconnect >>>>>>> >when deploying a typical HTTP based remote server within a Qt >>>>>>> project. >>>>>>> > >>>>>>> >> Qt has all the stuff one needs to build a legitimate web >>>>>>> framework, >>>>>>> >> connection to a scripting language (PySide, or any language with a >>>>>>> C++ >>>>>>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>>>>>> >> everything. We just need some (okay, not some, a lot) of code to >>>>>>> glue >>>>>>> >> this all together into a well knit package. I'll await >>>>>>> suggestions. >>>>>>> > >>>>>>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>>>>>> > >>>>>>> >_______________________________________________ >>>>>>> >Development mailing list >>>>>>> >Development at qt-project.org >>>>>>> >http://lists.qt-project.org/mailman/listinfo/development >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Development mailing list >>>>>>> Development at qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pau Garcia i Quiles >>>>>> http://www.elpauer.org >>>>>> (Due to my workload, I may need 10 days to answer) >>>>>> >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> >>> >>> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markc at renta.net Sun Oct 23 05:55:22 2011 From: markc at renta.net (Mark Constable) Date: Sun, 23 Oct 2011 13:55:22 +1000 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> Message-ID: <1589350.qHAiIrzv1E@g2> On 2011-10-22 08:32 PM, Dhaivat Pandya wrote: > Any more feedback from anyone? The current situation seems to support > a more traditional web framework more. Well to me the point of Qt based webserver and nodejs-like applications is they fulfill a foundational requirement that then could go off in other various framework tangents. I'm also thinking in the context of folks just getting involved with Qt for the first time and to provide them with semi-official examples of how to create a http/cgi/nodejs like system. Show me a Qt http webserver and a Qt nodejs-like fastcgi backend and you'll probably see a 100 different Qt web frameworks in a couple of years. From xizhi.zhu at nokia.com Sun Oct 23 07:56:39 2011 From: xizhi.zhu at nokia.com (xizhi.zhu at nokia.com) Date: Sun, 23 Oct 2011 05:56:39 +0000 Subject: [Development] QtPim concerns In-Reply-To: References: <96E5B115E1BBE3468DCD10CE357A4C7E0871F6DA@008-AM1MPN1-021.mgdnok.nokia.com>, Message-ID: <96E5B115E1BBE3468DCD10CE357A4C7E0871F7C8@008-AM1MPN1-021.mgdnok.nokia.com> Hi, From: robin at viroteck.net [robin at viroteck.net] on behalf of ext Robin Burchell [robin+qt at viroteck.net] > (dropping 'mikko' from CC, since I got his address wrong, I'll forward > him a link to the thread) Mika is added in CC ;) > First up, thanks for your reply! > On Sat, Oct 22, 2011 at 10:33 PM, wrote: >> As far as I understand, we lost the commit history of all modules when >> importing from QtMobility. > Yes, looks that way. But it shouldn't have been impossible to keep > that, right? Is it early enough that we can invest some time to try go > back and do that *now*, given the advantages in terms of being able to > find the context of why changes were made? I don't think it's good if QtPim is the only module containing all the history, while others don't. >> As of now, QtPim includes contacts, organizer and versit from QtM, and >> future development should happen in QtPim, and only bug fixes are expected >> in QtM. > OK, thanks for the clarification. >> Some tests are commented out just because they are failing, and we are >> working to fix them. For sure, it's our target to get a higher coverage and >> better quality. > OK, as I suspected. What's your feeling on patches implementing new > tests, for e.g. QDeclarativeContactModel, which is one of my first > 'victims' with a few patches? Mika and Cristiano are better contacts for Contacts API. >> Currently, we are doing some refactoring / improvement for the APIs (mainly >> limiting some unnecessary flexibility and reducing some complexity), so >> probably it's further impacting our tests and merging from QtM. > At least for the tests part, it shouldn't be. I think in an ideal > world, you should be doing your best to follow your refactoring with > test updates, and using those test results to make sure that nothing > is breaking. I understand that this isn't strictly *always* possible, > but that should be the exception, not the norm as much as possible. > That's why, for instance, I'm talking about *creating* unit tests for > QDCM before I even touch it. Because I don't want to break it. Yes, that's true, and we're exactly trying the same. However, it's difficult for the tests that are already commented out. > It does complicate the QtM merge situation a bit more, yeah. I guess > we'll just have to manage that, somehow. We must ;) > thanks, > Robin ================ Xizhi Zhu (Steven) Software Engineer @ Qt Development Frameworks Nokia Mobile: +358 (0)50 480 1247 From robin+qt at viroteck.net Sun Oct 23 20:38:28 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Sun, 23 Oct 2011 20:38:28 +0200 Subject: [Development] Status of windows CE support In-Reply-To: References: Message-ID: resending from the correct address, again. (sorry guys, I'll figure out how to use my mail client one day.) On Sun, Oct 23, 2011 at 12:43 PM, Robin Burchell wrote: > Hi, > > CC to Lars, because I guess platforms is one of the things a CM would > be responsible for... :) > > As has been previously discussed, the primary platforms for Qt are > Windows, Linux, and OS X. This has lead to code from e.g. Symbian > being removed. What I'm wondering is; should code from e.g. Windows CE > also be dropped? Or should it be kept when stripping out other dead > mobile branches? > > Thanks, > > Robin > From robin+qt at viroteck.net Sun Oct 23 20:56:03 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Sun, 23 Oct 2011 20:56:03 +0200 Subject: [Development] QContactLocalId in Qt5 Message-ID: Hi, As of commit 9453d77995d9d36661a3be97d91742da0b449d5e in QtPim, QContactLocalId was changed from a quint32 to a QString. I'm interested to know what the justifications for this change were (unfortunately, there's no details in the commit message), because this will have pretty nasty source-incompatible effects (which Qt5 is supposed to avoid), such as in code as exposed by qdeclarativecontact's autotests: 445 QContactLocalIdFilter lif = df->filter(); 446 QVERIFY(lif.ids().size() == 3); 447 QVERIFY(lif.ids().contains(1111)); 448 QVERIFY(lif.ids().contains(2222)); 449 QVERIFY(lif.ids().contains(3333)); This code no longer builds, because QString (correctly) cannot be constructed from an integer (you need QString::number()). Thanks, Robin From thiago at kde.org Sun Oct 23 22:25:44 2011 From: thiago at kde.org (Thiago Macieira) Date: Sun, 23 Oct 2011 22:25:44 +0200 Subject: [Development] Status of windows CE support In-Reply-To: References: Message-ID: <45598269.9gQU7Ia5dm@tjmaciei-mobl2> On Sunday, 23 de October de 2011 20.38.28, Robin Burchell wrote: > > CC to Lars, because I guess platforms is one of the things a CM would > > be responsible for... :) > > > > As has been previously discussed, the primary platforms for Qt are > > Windows, Linux, and OS X. This has lead to code from e.g. Symbian > > being removed. What I'm wondering is; should code from e.g. Windows CE > > also be dropped? Or should it be kept when stripping out other dead > > mobile branches? I don't think there are any plans of removing Windows CE code. Lars, is there a maintainer for it? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From robin+qt at viroteck.net Sun Oct 23 22:27:47 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Sun, 23 Oct 2011 22:27:47 +0200 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <2885457.h2a0Rvv5Sh@spb0504> References: <562977D1-27F5-4C9D-A41A-BC68910162B5@csiro.au> <2885457.h2a0Rvv5Sh@spb0504> Message-ID: Hi Stephen, On Sun, Oct 23, 2011 at 10:15 PM, Stephen Bryant wrote: > It's 2 classes, 755 lines - including Doxygen comments. > Who should I send a copy to?  (I didn't want to spam the whole list!) Do you have a repository online on gitorious/github/other? If so, a link wouldn't be spamming IMHO. If not, nor would dropping a link to a tarball. I'm sure there's plenty of interested folks around. :) BR, Robin From Craig.Scott at csiro.au Mon Oct 24 00:21:36 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Mon, 24 Oct 2011 09:21:36 +1100 Subject: [Development] [Qt5-feedback] Command line parser in QtCore? In-Reply-To: <2885457.h2a0Rvv5Sh@spb0504> References: <562977D1-27F5-4C9D-A41A-BC68910162B5@csiro.au> <2885457.h2a0Rvv5Sh@spb0504> Message-ID: On 24/10/2011, at 7:15 AM, Stephen Bryant wrote: > Hey guys, > > Apologies for being late to the party! > > If Craig doesn't like QCommandLine, and the other implementation mentioned has > legal restrictions, I have an implementation I wrote - with no legal > restrictions other than normal Qt license compatibility. My opinion here is just one among many. ;) > > It supports most of the usual suspects: long and short options, aliases (ie: > you can treat 'h', '?' and 'help' as the same thing), parameters (even > multiple), and optionally stopping at '--'. There's no type conversion - > everything stays as a QString, but you can ask it what it found, in what > order, what it didn't recognise and what was left over at the end! Sounds more complete than the code I put up for comment. It appears you'd still have to do validation outside of the class, but if I'm the only one who cares about that, it should be trivial for us to wrap your class with something that handled validation as well. > > Oh - it doesn't need subclassing, or use signals or slots. I'm afraid it's > just old-fashioned calls to methods on an object! :-) > That should keep more people happy. ;) > It's 2 classes, 755 lines - including Doxygen comments. > Who should I send a copy to? (I didn't want to spam the whole list!) For easy reference, you could just copy the header to pastebin.com and send the link to this list. That would at least allow us to review the API, which is probably more important at this first stage than the implementation. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From rohan.mcgovern at nokia.com Mon Oct 24 04:01:27 2011 From: rohan.mcgovern at nokia.com (Rohan McGovern) Date: Mon, 24 Oct 2011 12:01:27 +1000 Subject: [Development] [Qt5-feedback] 3rdpart platform plugins, tests and CI In-Reply-To: References: <1319069281-sup-7301@bq-menoetius> Message-ID: <1319420129-sup-1442@bq-menoetius> Holger Freyther said: > > I understand that in the beginning infrastructure will be solely operated > by Nokia, would it make sense to setup a Jenkins outside of Nokia? I am not sure. The only immediate benefits I can see from doing that is (1) removes one blocker for non-Nokia entities to add test machines with their own configurations, (2) the full build logs could immediately be made public. The disadvantage would be disruption on the existing codereview/CI setup for all developers. The build logs issue is tracked by https://bugreports.qt.nokia.com/browse/QTQAINFRA-139 and should be solvable with a less drastic solution than an entire switchover of the CI tool. > Is there > a list of what Pulse/Scripts do that Jenkins is not capable of doing right > now? No, not right now. It would make sense to create this. In our setup, the responsibilities of Pulse/Jenkins/whatever else at that layer consists of "merely": - schedule arbitrary test scripts over a pool of machines - gather and store build logs, test results - reading the contents of some git repositories - run arbitrary pre/post build commands for a few things (e.g. automatic reboot of virtual machines after each test run) I expect these requirements are simple enough to be satisfied by many tools. The actual test logic and test machine setups are not implemented in Pulse at all, they are almost all public and could be immediately used outside of Nokia's current Pulse setup. - http://qt.gitorious.org/qt/qtqa <- the scripts used for testing Qt5 in CI - http://qt.gitorious.org/qtqa/testconfig <- glue between CI tool (e.g. Pulse) and the above scripts - http://qt.gitorious.org/qtqa/sysadmin <- metadata for configuration of test machines There is some documentation at http://wiki.qt-project.org/index.php/Public_Autotest_Infrastructure which should be expanded. > I assume the Qt Project starts off while still using your internal > and non-free pulse system while an alternative is built? > Yes, as far as the CI system is concerned, the Qt project going live meant nothing other than the firewall rules blocking access to codereview.qt-project.org from outside of Nokia being dropped. > > If they are generic enough to be usable for e.g. "any" DirectFB backend, > > then it may be appropriate to check them into the source tree, if they > > are fairly stable. If they're likely to be unstable, or they are very > > large, we don't have any good solution at the moment :( > > The question is a general one. How do we have custom results? In this > specific case the DirectFB software image decoders generate different > results to Qt, but if I would build a SoC platform and I decide to run > Qt tests and my hardware is giving a slightly different result i would > want to override some results? Any idea? > > In case of image results it would make sense to look for 'foo.png' > in images/foo.png, images/QPA-DirectFB/foo.png, > images/QPA-DirectFB/HW/foo.png, That would be fine, we've used that approach for testdata sometimes in the past. However it's hard to decide how much detail needs to go into the identification of the testdata. For example, maybe changing the version of system libraries such as freetype could change the font rendering slightly, so would you then include the freetype version number in the string as well? > maybe even have qrc:/ look into an external path? > Not sure about that. From lars.knoll at nokia.com Mon Oct 24 09:12:59 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Mon, 24 Oct 2011 07:12:59 +0000 Subject: [Development] Status of windows CE support In-Reply-To: <45598269.9gQU7Ia5dm@tjmaciei-mobl2> Message-ID: On 10/23/11 10:25 PM, "ext Thiago Macieira" wrote: >On Sunday, 23 de October de 2011 20.38.28, Robin Burchell wrote: >> > CC to Lars, because I guess platforms is one of the things a CM would >> > be responsible for... :) >> > >> > As has been previously discussed, the primary platforms for Qt are >> > Windows, Linux, and OS X. This has lead to code from e.g. Symbian >> > being removed. What I'm wondering is; should code from e.g. Windows CE >> > also be dropped? Or should it be kept when stripping out other dead >> > mobile branches? > >I don't think there are any plans of removing Windows CE code. Lars, is >there >a maintainer for it? Not currently. But the code is usually a small variation of the regular Windows code and I think we should keep it around for now. What we can remove is everything that's related to the windowing system, as that has to go through Lighthouse in the future. Ie. we keep stuff that should be in Q_OS_WINCE and remove stuff that's inside Q_WS_WINCE. But please keep in mind that we haven't been very good in keeping the usage of these defines consistent. So something inside Q_WS_WIN(CE) might actually be Q_OS_* code :) Cheers, Lars From thiago.macieira at intel.com Mon Oct 24 09:32:00 2011 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Oct 2011 09:32 +0200 Subject: [Development] V8's location In-Reply-To: <20111023150724.666C0208DE@hoat.troll.no> References: <20111023150724.666C0208DE@hoat.troll.no> Message-ID: <21731853.v4jSBZRpxK@tjmaciei-mobl2> On Sunday, 23 de October de 2011, às 17.07.24, you wrote: > Samuel Rødal has posted comments on this change. > > Change subject: Improve drawing scaled image with raster using SSE2 > ...................................................................... > > > Patch Set 2: Do not submit > > You accidentally got src/3rdparty/v8 included in your change, could you > remove it? Can we move V8 out of qtbase and into a top-level module? I've done that mistake above several times. The fact that V8 is inside qtbase means I cannot do a git commit -a, despite the submodule ignore command. Also, can we move it to Gitorious and enable Gerrit for it? I have a patch to make it compile with ICC and I'd rather not have to create a github account just for this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- ---------------------------------------------------------------------- Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, Sweden Registration Number: 556189-6027 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From simon.hausmann at nokia.com Mon Oct 24 10:11:00 2011 From: simon.hausmann at nokia.com (Simon Hausmann) Date: Mon, 24 Oct 2011 10:11:00 +0200 Subject: [Development] V8's location In-Reply-To: <21731853.v4jSBZRpxK@tjmaciei-mobl2> References: <20111023150724.666C0208DE@hoat.troll.no> <21731853.v4jSBZRpxK@tjmaciei-mobl2> Message-ID: <201110241011.00871.simon.hausmann@nokia.com> On Monday, October 24, 2011 09:32:00 AM ext Thiago Macieira wrote: > On Sunday, 23 de October de 2011, às 17.07.24, you wrote: > > Samuel Rødal has posted comments on this change. > > > > Change subject: Improve drawing scaled image with raster using SSE2 > > ...................................................................... > > > > > > Patch Set 2: Do not submit > > > > You accidentally got src/3rdparty/v8 included in your change, could you > > remove it? > > Can we move V8 out of qtbase and into a top-level module? I've done that > mistake above several times. The fact that V8 is inside qtbase means I cannot > do a git commit -a, despite the submodule ignore command. > > Also, can we move it to Gitorious and enable Gerrit for it? I have a patch to > make it compile with ICC and I'd rather not have to create a github account > just for this. Isn't the right solution then to get your patch either upstream or into the Qt copy? I'm not sure if putting v8 into gerrit helps much, because things like rebasing are much harder with Gerrit. In a strange sense we want to make it difficult to modify our fork of V8 :) That said, does your employer allow you to contribute the patch upstream? Simon From thiago.macieira at intel.com Mon Oct 24 14:15:38 2011 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Oct 2011 14:15:38 +0200 Subject: [Development] V8's location In-Reply-To: <201110241011.00871.simon.hausmann@nokia.com> References: <21731853.v4jSBZRpxK@tjmaciei-mobl2> <201110241011.00871.simon.hausmann@nokia.com> Message-ID: <18951072.WCAbSzNWtu@tjmaciei-mobl2> On Monday, 24 de October de 2011 10.11.00, Simon Hausmann wrote: > > Can we move V8 out of qtbase and into a top-level module? I've done that > > mistake above several times. The fact that V8 is inside qtbase means I > > cannot do a git commit -a, despite the submodule ignore command. > > > > Also, can we move it to Gitorious and enable Gerrit for it? I have a patch > > to make it compile with ICC and I'd rather not have to create a github > > account just for this. > > Isn't the right solution then to get your patch either upstream or into the > Qt copy? Yes and no. Yes, I should get my fixes into the Qt copy (at least). But it's not a full solution since very often I have pending changes or in-progress development that I committed. To put it bluntly: git submodules should not be used in an active repository. > I'm not sure if putting v8 into gerrit helps much, because things like > rebasing are much harder with Gerrit. In a strange sense we want to make it > difficult to modify our fork of V8 :) You can give push-to-branch rights in Gerrit, which allows rebasing. > That said, does your employer allow you to contribute the patch upstream? To Qt, it's in progress and should happen soon. To V8, definitely not for me. If the repository is not moved to Gerrit, which is fine, I'll probably just publish my changes in Gitorious and expect V8's maintainer to merge them on their own. But please move the submodule to qt5.git. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- ---------------------------------------------------------------------- Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, Sweden Registration Number: 556189-6027 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From rickstockton at reno-computerhelp.com Tue Oct 25 00:14:23 2011 From: rickstockton at reno-computerhelp.com (Rick Stockton) Date: Mon, 24 Oct 2011 15:14:23 -0700 Subject: [Development] 31 mouse buttons in Qt 5.0 Message-ID: <4EA5E33F.80805@reno-computerhelp.com> This replaces my 4.x Proposal, which was titled "I have a way to support *ALL* MOUSE BUTTONS in Qt, while staying compatible with the 4.x series!" http://developer.qt.nokia.com/forums/viewthread/6547/ This message duplicates a new forum topic at: http://developer.qt.nokia.com/forums/viewthread/10970/ Here are the main changes: (1) Qt 5.0 eliminates a very large number of plugins :)) making the job much smaller. On Linux (my platform), I propose to implement only XCB and Wayland. (2) Since Qt 5.0 will require re-compilation of Applications written against earlier versions of Qt, BIINARY compatibility is a non-issue (right?). SOURCE Compatibility remains critical- and so, I will not try to add the (int) button number into the event signatures. Instead, I will expand the range of values which Qt::MouseButton (and the corresponding flags) can take, using 31 bits. Should I go ahead and use the high-order bit as well? (3) XCB does not automatically provide a 32-bit mask field (the kernel evdev driver, which we use for Wayland input, does include the full mask). It is TBD whether our code should: (A) obtain the full mask automatically, and setting Qt::MouseButtons accordingly; or (B) leave high-order bits unset in events, returning the full mask as the value of a SEPARATE function call. I feel that alternative (A) is far less confusing, and have been advised by some X11 experts (Peter H., Daniel S.,) that the overhead and reliability of mixing a query-state function call (i.e., to get the mask) into the code path of this Event processing is a non-issue -- as long as we avoid doing it with every single XCB event which occurs on on Wheel "Buttons". (Wait until we're done compressing these lower-level events, and acquire the current mask field when we're preparing to create the QWheelEvent.) The need for this 'enhancement' seems to be even more severe than it appeared to be a year ago -- our current 5.0 Wayland/evdev plugin code actually REDUCES the number of Qt-supported buttons, from 5 to 3. We're losing the "Back" and "Forward" buttons, AKA "XButton1" and "XButton2". (IMO, That's not a healthy direction; Qt becomes less attractive for writing web Browsers, FIle Managers, and etc.) This would be my first submission of code into Qt. If it's no-go, please advise: What are the problems with this approach, and are there ways to avoid the problems which I don't yet see? In any case, you all have my greatest thanks for any advice and replies. ;) From dhaivatpandya at gmail.com Tue Oct 25 00:55:48 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Mon, 24 Oct 2011 17:55:48 -0500 Subject: [Development] Crazy Idea In-Reply-To: <4EA3022B.4090108@gmail.com> References: <6983815.U6Lvx3ECs5@g2> <4EA3022B.4090108@gmail.com> Message-ID: So, no matter how we look at this, we obviously need: 1) FastCGI support 2) A web server that supports async So, we might as well get cracking. I set up a Gitorious repo here: https://gitorious.org/qtweb/qtweb For the lack of a better name, we'll be calling it QtWeb, if you come up with a better name that most people like, we can change it. So, if you are interested in contributing, please tell me, so we can have an initial set of contributors. 2011/10/22 qtnext > Hi, > > I think there is to side : > - Server Side : > - light web server with easy bridge with Qt > - Websocket and Qt : there is an existing websocket lib for Qt : > http://gitorious.org/qtwebsocket > > - and the dream : the client side : > - for me a QML translator to javascript : perhaps in the same GWT > (google) do > > > There is a lot of related thread in qt list, forum and there is a lot of > library around server or client web side. > for example : http://developer.qt.nokia.com/forums/viewthread/4347 > > Perhaps the start is to have a list of all available lib around Qt + web, > contact all the people around these libs, and start to have a coherent > package ? > > > Le 22/10/2011 19:11, Pau Garcia i Quiles a écrit : > > Hi, > > Have you ever used Wt? > > It does everything you say it's difficult. > > > On Sat, Oct 22, 2011 at 7:04 PM, Dhaivat Pandya wrote: > >> Here's my stance on that. >> If it is possible to keep the ability to write Javascript for custom UI >> widgets (or, C++ that generates a custom Javascript widget), I am for this. >> If not, it would very difficult to produce web apps that have some special >> "pizazz". >> >> Web development interfaces are quite different from desktop interfaces >> because >> >> - There are a ton of different browsers, mobile, web, etc. >> - All kinds of technologies one has to fix up >> >> Also, if that is done, all the existing code for Javascript (such as >> jQuery and the likes) cannot be used, unless the cross compiled C++ can work >> with existing Javascript. If that is possible (as I mentioned), I'm totally >> in for this idea, but, IMO, that is a difficult thing to accomplish. >> >> On Sat, Oct 22, 2011 at 11:16 AM, Pau Garcia i Quiles < >> pgquiles at elpauer.org> wrote: >> >>> >>> >>> On Sat, Oct 22, 2011 at 6:05 PM, Dhaivat Pandya < >>> dhaivatpandya at gmail.com> wrote: >>> >>>> Okay, so, people do want this to happen. So, the first things we should >>>> decide would be what features/ideas one would need. I say: >>>> >>>> Now, IMHO, if we do make it a QPA by just changing the backend, that >>>> would be exactly like Wt. >>>> >>> >>> Which is exactly what I'd like to see. >>> >>> I'm not asking for a web framework/library based on Qt, but for a new >>> target for Qt: instead of compiling for Windows, Linux, Symbian or MeeGo, I >>> would choose "cross-compile for web". The end result would be a FastCGI >>> module, or a single executable which embeds its own web server (exactly like >>> in Qt). >>> >>> Emweb has put a lot of thought into Wt, really. >>> >>> >>> Also, even though desktop apps have been written like this for a very >>>> long time, webapps (again, IMHO) are better arranged as MVC. >>>> >>>> 1) Templates >>>> 2) MVC properly done >>>> 3) Some type of scaffolding script >>>> 4) The core needs to be extremely fast and async >>>> 5) Database requests are shifted off to another thread, etc. This is not >>>> possible (well, it is, but, not very useful) in languages such as Python, >>>> PHP, Ruby since they all use green threading, which works, but, isn't quite >>>> as fast. >>>> 6) Crash support, if something crashes, don't give a crazy error to the >>>> user, figure out where it crashed, write to logs, and the web developer uses >>>> an error page. Figuring out where it crashed is mostly where the work is >>>> done. >>>> 7) Qt libraries are used as much as possible >>>> 8) (this one needs community support to happen) Relation to scripting >>>> languages, such as Javascript, Lua, etc. >>>> >>>> What do you think? >>>> >>>> >>> I think there have been several projects trying that: >>> >>> Creole ( http://blogs.kde.org/node/3707 ) >>> QtWui ( http://qtwui.sourceforge.net/ ) >>> ... >>> >>> I want write once, compile everywhere. Even if that means having three >>> "different" UIs (desktop, mobile, web), it would be a wonderful feature. See >>> Gtk+ HTML5 backend. >>> >>> >>> >>> 2011/10/22 Pau Garcia i Quiles >>>> >>>>> Hi, >>>>> >>>>> IMHO a proper implementation needs to be a QPA platform. >>>>> >>>>> Widgets need to be "drawn" in this "web" target, like in X11, Wayland, >>>>> Windows, etc. The only change would be the low level primitives are HTML + >>>>> CSS + JavaScript + SVG (and maybe even images), like Wt does. >>>>> >>>>> Trivia: the first version of Wt used Qt instead as the backend. They >>>>> moved to Boost because of licensing (Qt was not LGPL back then) and >>>>> threading. >>>>> >>>>> >>>>> >>>>> On Sat, Oct 22, 2011 at 10:55 AM, wrote: >>>>> >>>>>> >From my point of view: >>>>>> >>>>>> Having something here would be great. I don't think it should be part >>>>>> of >>>>>> the essential Qt modules, but as an add-on it would be a very welcome >>>>>> addition :) >>>>>> >>>>>> Cheers, >>>>>> Lars >>>>>> >>>>>> On 10/22/11 7:09 AM, "ext Mark Constable" wrote: >>>>>> >>>>>> >On 2011-10-21 10:10 PM, Dhaivat Pandya wrote: >>>>>> >> This seems like something that's way out there, and may have been >>>>>> >> suggested before and rejected, but, I'm bringing it up anyway. What >>>>>> >> would the Qt community think of a web framework devised around Qt? >>>>>> > >>>>>> >Speaking personally I'd love to see... >>>>>> > >>>>>> >. a web server similar to lighttpd but 100% based on Qt >>>>>> > >>>>>> >. a Qt5/V8 Javascript "engine" similar to NodeJS >>>>>> > >>>>>> >. an optional but builtin C++ FastCGI interface for the above >>>>>> > >>>>>> >In other words the essential tools for a Qt Server Side JavaScript >>>>>> >solution, with Websocket support, so it can be as both a traditional >>>>>> >webserver or a local backend to a HTML5/QML desktop system. >>>>>> > >>>>>> >Why another webserver when lighttpd, nginx, even apache, already >>>>>> exist >>>>>> >as stable codebases? Because none of them allow me to build, develop >>>>>> >and deploy them, and any web based projects, within QtCreator using >>>>>> >CMake and Git. There is currently a complete development disconnect >>>>>> >when deploying a typical HTTP based remote server within a Qt >>>>>> project. >>>>>> > >>>>>> >> Qt has all the stuff one needs to build a legitimate web framework, >>>>>> >> connection to a scripting language (PySide, or any language with a >>>>>> C++ >>>>>> >> API, such as Lua), Sql libraries, async socket libraries, XML, >>>>>> >> everything. We just need some (okay, not some, a lot) of code to >>>>>> glue >>>>>> >> this all together into a well knit package. I'll await suggestions. >>>>>> > >>>>>> >Wouldn't Wt provide a lot of that? http://www.webtoolkit.eu/wt >>>>>> > >>>>>> >_______________________________________________ >>>>>> >Development mailing list >>>>>> >Development at qt-project.org >>>>>> >http://lists.qt-project.org/mailman/listinfo/development >>>>>> >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pau Garcia i Quiles >>>>> http://www.elpauer.org >>>>> (Due to my workload, I may need 10 days to answer) >>>>> >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> >>>>> >>>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >> >> > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markc at renta.net Tue Oct 25 04:14:31 2011 From: markc at renta.net (Mark Constable) Date: Tue, 25 Oct 2011 12:14:31 +1000 Subject: [Development] Crazy Idea In-Reply-To: References: <6983815.U6Lvx3ECs5@g2> <4EA3022B.4090108@gmail.com> Message-ID: <1396335.ZD1IC21GZP@g2> On 2011-10-24 05:55 PM, Dhaivat Pandya wrote: > So, no matter how we look at this, we obviously need: > > 1) FastCGI support There maybe some clues here if you are not aware of it... https://github.com/fredemmott/fastcgiqt > 2) A web server that supports async With lighttpd and nginx as examples but unfortunately not in C++. > So, we might as well get cracking. > I set up a Gitorious repo here: https://gitorious.org/qtweb/qtweb Excellent. > For the lack of a better name, we'll be calling it QtWeb, if you come > up with a better name that most people like, we can change it. Seems perfect if not otherwise already taken. Perhaps start a new thread with QtWeb as the Subject. > So, if you are interested in contributing, please tell me, so we can > have an initial set of contributors. Please sign me up. From dhaivatpandya at gmail.com Tue Oct 25 04:33:50 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Mon, 24 Oct 2011 21:33:50 -0500 Subject: [Development] Crazy Idea In-Reply-To: <1396335.ZD1IC21GZP@g2> References: <6983815.U6Lvx3ECs5@g2> <4EA3022B.4090108@gmail.com> <1396335.ZD1IC21GZP@g2> Message-ID: Okay, I'll be starting a new thread, and, as far as I know, QtWeb is not taken. Go ahead and fork the repo, I'll pull in any changes you have. On Mon, Oct 24, 2011 at 9:14 PM, Mark Constable wrote: > On 2011-10-24 05:55 PM, Dhaivat Pandya wrote: > > So, no matter how we look at this, we obviously need: > > > > 1) FastCGI support > > There maybe some clues here if you are not aware of it... > > https://github.com/fredemmott/fastcgiqt > > > 2) A web server that supports async > > With lighttpd and nginx as examples but unfortunately not in C++. > > > So, we might as well get cracking. > > I set up a Gitorious repo here: https://gitorious.org/qtweb/qtweb > > Excellent. > > > For the lack of a better name, we'll be calling it QtWeb, if you come > > up with a better name that most people like, we can change it. > > Seems perfect if not otherwise already taken. Perhaps start a new > thread with QtWeb as the Subject. > > > So, if you are interested in contributing, please tell me, so we can > > have an initial set of contributors. > > Please sign me up. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhaivatpandya at gmail.com Tue Oct 25 04:38:21 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Mon, 24 Oct 2011 21:38:21 -0500 Subject: [Development] QtWeb In-Reply-To: References: Message-ID: QtWeb: https://gitorious.org/qtweb/qtweb Web framework for Qt, right now, all we have decided is the FastCGI base. Either it can be a Wt style framework with Qt components, or, a more traditional MVC framework (more community support on the latter, so that is mostly likely the POA). Fork, commit, push. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago at kde.org Tue Oct 25 08:17:23 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 25 Oct 2011 08:17:23 +0200 Subject: [Development] 31 mouse buttons in Qt 5.0 In-Reply-To: <4EA5E33F.80805@reno-computerhelp.com> References: <4EA5E33F.80805@reno-computerhelp.com> Message-ID: <10657852.USMpV3XR3V@tjmaciei-mobl2> On Monday, 24 de October de 2011 15.14.23, Rick Stockton wrote: > (A) obtain the full mask automatically, and setting > Qt::MouseButtons accordingly; or > (B) leave high-order bits unset in events, returning the full > mask as the value of a SEPARATE function call. > > I feel that alternative (A) is far less confusing, and have been advised > by some X11 experts (Peter H., Daniel S.,) that the overhead and > reliability of mixing a query-state function call (i.e., to get the > mask) into the code path of this Event processing is a non-issue -- as > long as we avoid doing it with every single XCB event which occurs on on > Wheel "Buttons". (Wait until we're done compressing these lower-level > events, and acquire the current mask field when we're preparing to > create the QWheelEvent.) Are you proposing opening and checking /dev/input/mice for each mouse / wheel event that is about to be delivered? That's a definite NO-GO. Get the information from XCB or Wayland. If they don't give that information, fix them and then update the Lighthouse plugin. > The need for this 'enhancement' seems to be even more severe than it > appeared to be a year ago -- our current 5.0 Wayland/evdev plugin code > actually REDUCES the number of Qt-supported buttons, from 5 to 3. We're > losing the "Back" and "Forward" buttons, AKA "XButton1" and "XButton2". > (IMO, That's not a healthy direction; Qt becomes less attractive for > writing web Browsers, FIle Managers, and etc.) > > This would be my first submission of code into Qt. If it's no-go, please > advise: What are the problems with this approach, and are there ways to > avoid the problems which I don't yet see? Modify the Lighthouse plugin to get the information from the correct source: the windowing/compositing server. Reading from /dev/input is *wrong*. This information should be included in the native event handle obtained from the server. If it's not included, then you should query the server *using* the same event pointer, as we need to obtain the state at the time the event was generated, not at the time it was processed. If those systems do not include said information in any form, then you should consider that this information does not *exist*. If you feel strongly about the case, prepare patches for those systems and update their API to include the extra information. Only then can you update the Lighthouse driver to deliver more information. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From markc at renta.net Tue Oct 25 08:55:14 2011 From: markc at renta.net (Mark Constable) Date: Tue, 25 Oct 2011 16:55:14 +1000 Subject: [Development] QtWeb In-Reply-To: References: Message-ID: <7034849.77R9SOIAtZ@g2> On 2011-10-24 09:38 PM, Dhaivat Pandya wrote: > QtWeb: https://gitorious.org/qtweb/qtweb > > Web framework for Qt, right now, all we have decided is the FastCGI > base. These might help with the webserver itself... https://github.com/nikhilm/qhttpserver (the above uses NodeJS's http://github.com/ry/http-parser) https://github.com/acossette/pillow And FWIW "QtWeb" is actually used for a browser, http://www.qtweb.net/ From eike.ziller at nokia.com Tue Oct 25 11:44:08 2011 From: eike.ziller at nokia.com (eike.ziller at nokia.com) Date: Tue, 25 Oct 2011 09:44:08 +0000 Subject: [Development] Fwd: [Qt-creator] Fwd: Proposing Hugues Delorme for Approver Status References: <4EA18097.9010202@nokia.com> Message-ID: <2400D2E2-D125-4065-BADA-5C4B781BA781@nokia.com> And, since approver status is for the whole "Qt Project" and not separately defined for the Qt framework and Qt Creator, it probably makes sense to post it on the development@ list as well (until we've figured out where these kind of requests should actually be sent to). Br, Eike Begin forwarded message: > From: ext Tobias Hunger > Date: 21 October 2011 16:24:23 CEST > To: > Subject: [Qt-creator] Fwd: Proposing Hugues Delorme for Approver Status > > This is taking some getting used to:-) Again, this time to the new list: > > -------- Original Message -------- > Subject: [Qt-creator] Proposing Hugues Delorme for Approver Status > Date: Fri, 21 Oct 2011 16:18:13 +0200 > From: ext Tobias Hunger > Reply-To: > To: qt-creator at qt.nokia.com > > Hello Qt Creator subscribers, > > following the Qt open governance process I hereby propose Hugues Delorme > for the role of approver. > > He wrote the Bazaar plugin for Qt Creator and did significant updates > to the overall version control handling in Qt Creator. I think that > warrants the Approver status. > > Eike Ziller is seconding this proposal. > > Please raise any concerns you might have till Nov. 11. Thank you. > > Best Regards, > Tobias > > -- > Tobias Hunger > Software Engineer > Nokia, Qt Development Frameworks > > Nokia gate5 GmbH > Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany > Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B > Umsatzsteueridentifikationsnummer: DE 812 845 193 > Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt.nokia.com > http://lists.qt.nokia.com/mailman/listinfo/qt-creator > > -- > Tobias Hunger > Software Engineer > Nokia, Qt Development Frameworks > > Nokia gate5 GmbH > Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany > Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B > Umsatzsteueridentifikationsnummer: DE 812 845 193 > Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori From thiago at kde.org Tue Oct 25 11:59:54 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 25 Oct 2011 11:59:54 +0200 Subject: [Development] API review for the new QUrl Message-ID: <1505427.QI81GE2Stf@tjmaciei-mobl2> I can't post the code just yet, but I can post the new API. Questions: - I un-deprecated fromEncoded and toEncoded, as they're used everywhere. Should I do the same for fromPercentEncoding and toPercentEncoding? They convert from QString to QByteArray and vice-versa, while QByteArray::fromPercentEncoding operates only on QByteArray. - QUrl::url() returns a QString. It should have a "to" prefix, since it returns a temporary. It's the exact same function as toString(). Should it be kept? - QUrlQuery does not keep the order of the items (it's kept in a hash). Is the order important? Observations: - unlike what I had proposed before, I kept the StrictMode parsing (or will have kept). However, unlike Qt 4, the actual parser is tolerant, with StrictMode implemented as a checker before the actual parser. This should improve in performance because 99% of the users use TolerantMode. - errorString is much more limited than in Qt 4 because I was only willing to dedicate 4 bytes for the error (one error code and one QChar). I feel that if you need a *real* URL validator, with very detailed explanations, you should use a dedicated class, not a generic URL container. - QString-based methods are rehabilitated, including the constructor and toString(). The constructor and copy operator from QString are still "disablable" with an #ifdef so you can spot unnecessary parsing. The QByteArray based methods are deprecated, except for fromEncoded / toEncoded. - talking about parsing: it's NOT lazy anymore. It's done at the moment you set the URL. Why? Because the one in Qt 4 was NOT THREAD-SAFE. Any use of const_cast(this) in a non-detached class is just plain wrong. - QUrl now operates *only* in encoded mode, but it does partially decode wherever possible. The default mode (PrettyDecoded) means most components will actually appear decoded, unless the component contains a character that should appear encoded in URL or cannot be represented at all in QString (such as a lone %80). - IP addresses are actually parsed and fixed appropriately (see the blog) - QUrl lowercases the scheme, so you no longer have to write: if (url.scheme().compare(QLatin1String("http"), Qt::CaseInsensitive) == 0) or the much worse: if (url.scheme().toLower() == QLatin1String("http")) class Q_CORE_EXPORT QUrl { public: enum ParsingMode { TolerantMode, StrictMode }; // encoding / toString values enum UrlFormattingOption { None = 0x0, RemoveScheme = 0x1, RemovePassword = 0x2, RemoveUserInfo = RemovePassword | 0x4, RemovePort = 0x8, RemoveAuthority = RemoveUserInfo | RemovePort | 0x10, RemovePath = 0x20, RemoveQuery = 0x40, RemoveFragment = 0x80, // 0x100 was a private code in Qt 4, keep unused for a while StripTrailingSlash = 0x200 }; enum ComponentFormattingOption { FullyEncoded = 0x0000, DecodeSpaces = 0x1000, DecodeUnambiguousDelimiters = 0x2000, DecodeAllDelimiters = DecodeUnambiguousDelimiters | 0x4000, DecodeUnicode = 0x8000, PrettyDecoded = DecodeSpaces | DecodeUnambiguousDelimiters | DecodeUnicode, MostDecoded = PrettyDecoded | DecodeAllDelimiters }; Q_DECLARE_FLAGS(ComponentFormattingOptions, ComponentFormattingOption) #ifdef qdoc Q_DECLARE_FLAGS(FormattingOptions, UrlFormattingOption) #else typedef QUrlTwoFlags FormattingOptions; #endif QUrl(); QUrl(const QUrl ©); QUrl &operator =(const QUrl ©); #ifdef QT_NO_URL_CAST_FROM_STRING explicit QUrl(const QString &url, ParsingMode mode = TolerantMode); #else QUrl(const QString &url, ParsingMode mode = TolerantMode); QUrl &operator=(const QString &url); #endif #ifdef Q_COMPILER_RVALUE_REFS QUrl(QUrl &&other) : d(0) { qSwap(d, other.d); } inline QUrl &operator=(QUrl &&other) { qSwap(d, other.d); return *this; } #endif ~QUrl(); inline void swap(QUrl &other) { qSwap(d, other.d); } void setUrl(const QString &url, ParsingMode mode = TolerantMode); QString url(FormattingOptions options = FormattingOptions(PrettyDecoded)) const; QString toString(FormattingOptions options = FormattingOptions(PrettyDecoded)) const; QByteArray toEncoded(FormattingOptions options = FullyEncoded) const; static QUrl fromEncoded(const QByteArray &url, ParsingMode mode = TolerantMode); static QUrl fromUserInput(const QString &userInput); bool isValid() const; QString errorString() const; bool isEmpty() const; void clear(); void setScheme(const QString &scheme); QString scheme() const; void setAuthority(const QString &authority); QString authority(ComponentFormattingOptions options = PrettyDecoded) const; void setUserInfo(const QString &userInfo); QString userInfo(ComponentFormattingOptions options = PrettyDecoded) const; void setUserName(const QString &userName); QString userName(ComponentFormattingOptions options = PrettyDecoded) const; void setPassword(const QString &password); QString password(ComponentFormattingOptions = PrettyDecoded) const; void setHost(const QString &host); QString host(ComponentFormattingOptions = PrettyDecoded) const; QString topLevelDomain(ComponentFormattingOptions options = PrettyDecoded) const; void setPort(int port); int port(int defaultPort = -1) const; void setPath(const QString &path); QString path(ComponentFormattingOptions options = PrettyDecoded) const; bool hasQuery() const; void setQuery(const QString &query); void setQuery(const QUrlQuery &query); QString query(ComponentFormattingOptions = PrettyDecoded) const; bool hasFragment() const; QString fragment(ComponentFormattingOptions options = PrettyDecoded) const; void setFragment(const QString &fragment); QUrl resolved(const QUrl &relative) const; bool isRelative() const; bool isParentOf(const QUrl &url) const; bool isLocalFile() const; static QUrl fromLocalFile(const QString &localfile); QString toLocalFile() const; void detach(); bool isDetached() const; bool operator <(const QUrl &url) const; bool operator ==(const QUrl &url) const; bool operator !=(const QUrl &url) const; #if QT_DEPRECATED_SINCE(5,0) QT_DEPRECATED static QString fromPercentEncoding(const QByteArray &encoded) { return QString::fromUtf8(QByteArray::fromPercentEncoding(encoded)); } QT_DEPRECATED static QByteArray toPercentEncoding(const QString &string, const QByteArray &exclude = QByteArray(), const QByteArray &include = QByteArray()) { return string.toUtf8().toPercentEncoding(exclude, include); } QT_DEPRECATED static QString fromPunycode(const QByteArray &punycode) { return fromAce(punycode); } QT_DEPRECATED static QByteArray toPunycode(const QString &string) { return toAce(string); } QT_DEPRECATED void setEncodedUrl(const QByteArray &url, ParsingMode mode = TolerantMode) { setUrl(QString::fromUtf8(url), mode); } QT_DEPRECATED QByteArray encodedUserName() const { return userName(FullyEncoded).toLatin1(); } QT_DEPRECATED void setEncodedUserName(const QByteArray &value) { setUserName(QString::fromLatin1(value)); } QT_DEPRECATED QByteArray encodedPassword() const { return password(FullyEncoded).toLatin1(); } QT_DEPRECATED void setEncodedPassword(const QByteArray &value) { setPassword(QString::fromLatin1(value)); } QT_DEPRECATED QByteArray encodedHost() const { return host(FullyEncoded).toLatin1(); } QT_DEPRECATED void setEncodedHost(const QByteArray &value) { setHost(QString::fromLatin1(value)); } QT_DEPRECATED QByteArray encodedPath() const { return path(FullyEncoded).toLatin1(); } QT_DEPRECATED void setEncodedPath(const QByteArray &value) { setPath(QString::fromLatin1(value)); } QT_DEPRECATED QByteArray encodedQuery() const { return toLatin1_helper(query(FullyEncoded)); } QT_DEPRECATED void setEncodedQuery(const QByteArray &value) { setQuery(QString::fromLatin1(value)); } QT_DEPRECATED QByteArray encodedFragment() const { return toLatin1_helper(fragment(FullyEncoded)); } QT_DEPRECATED void setEncodedFragment(const QByteArray &value) { setFragment(QString::fromLatin1(value)); } #endif public: static QString fromAce(const QByteArray &); static QByteArray toAce(const QString &); static QStringList idnWhitelist(); static void setIdnWhitelist(const QStringList &); }; class Q_CORE_EXPORT QUrlQuery { public: QUrlQuery(); explicit QUrlQuery(const QUrl &url); explicit QUrlQuery(const QString &queryString); QUrlQuery(const QUrlQuery &other); QUrlQuery &operator=(const QUrlQuery &other); #ifdef Q_COMPILER_RVALUE_REFS QUrlQuery &operator=(QUrlQuery &&other) { qSwap(d, other.d); return *this; } #endif ~QUrlQuery(); bool operator==(const QUrlQuery &other) const; bool operator!=(const QUrlQuery &other) const { return !(*this == other); } void swap(QUrlQuery &other) { qSwap(d, other.d); } bool isEmpty() const; bool isDetached() const; void clear(); QString query(QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const; void setQuery(const QString &queryString); QString toString(QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const { return query(encoding); } void setQueryDelimiters(QChar valueDelimiter, QChar pairDelimiter); QChar queryValueDelimiter() const; QChar queryPairDelimiter() const; void setQueryItems(const QList > &query); QList > queryItems(QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const; bool hasQueryItem(const QString &key) const; void addQueryItem(const QString &key, const QString &value); void removeQueryItem(const QString &key); QString queryItemValue(const QString &key, QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const; QStringList allQueryItemValues(const QString &key, QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const; void removeAllQueryItems(const QString &key); static QChar defaultQueryValueDelimiter(); static QChar defaultQueryPairDelimiter(); }; -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From kurta.radu at gmail.com Tue Oct 25 12:15:25 2011 From: kurta.radu at gmail.com (Radu - Ionut Kurta) Date: Tue, 25 Oct 2011 13:15:25 +0300 Subject: [Development] QtWeb Message-ID: I would suggest going for an mvc framework as a wt like framework already exist namely wt and a ruby on rails like framework will have a greater success imho. -- My programs never have bugs, they just develop random features. -- C/C++ ... I don't see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste. -- C++ doesn't try to make it impossible for bad programmers to write bad programs; it enables reasonable developers to create superior software. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.laine at m4x.org Tue Oct 25 12:55:04 2011 From: jeremy.laine at m4x.org (jeremy.laine at m4x.org) Date: Tue, 25 Oct 2011 12:55:04 +0200 Subject: [Development] QtWeb In-Reply-To: References: Message-ID: <978tsv.ltmbo8.2s76lc-qmf@drake.jerryweb.org> Not sure if it is of interest if your focus is on fcgi but I have a qt-based http server I'd be happy to contribute: http://opensource.bolloretelecom.eu/projects/qdjango/browser/src/QDjangoHttpServer.h Am at qtdd11 if you want to talk. -- Jeremy On 25/10/11 04:38 Dhaivat Pandya wrote: QtWeb: https://gitorious.org/qtweb/qtweb Web framework for Qt, right now, all we have decided is the FastCGI base. Either it can be a Wt style framework with Qt components, or, a more traditional MVC framework (more community support on the latter, so that is mostly likely the POA). Fork, commit, push. From nicola at nicoladefilippo.it Tue Oct 25 15:50:22 2011 From: nicola at nicoladefilippo.it (Nicola De Filippo) Date: Tue, 25 Oct 2011 15:50:22 +0200 Subject: [Development] error compiling Message-ID: <2833613.1bqNhHil1e@kubuntu> Hi, compiling qt5 on kubuntu 11.10 and gcc 4.6.1 i have this error: In file included from ../../../Source/JavaScriptCore/wtf/PassRefPtr.h:25:0, from ../../../Source/JavaScriptCore/wtf/CrossThreadRefCounted.h:35, from ../../../Source/JavaScriptCore/wtf/text/StringImpl.h:28, from ../../../Source/JavaScriptCore/runtime/UString.h:26, from ../../../Source/JavaScriptCore/yarr/YarrPattern.h:30, from ../../../Source/JavaScriptCore/yarr/YarrInterpreter.h:29, from ../../../Source/JavaScriptCore/yarr/YarrInterpreter.cpp:28: ../../../Source/JavaScriptCore/wtf/NullPtr.h:48:1: error: identifier ‘nullptr’ will become a keyword in C++0x [-Werror=c++0x-compat] cc1plus: all warnings being treated as errors make[3]: *** [.obj/release-static/YarrInterpreter.o] Errore 1 make[3]: uscita dalla directory "/home/nicola/src/qt5/qt5/qtwebkit/WebKitBuild/Release/JavaScriptCore" make[2]: *** [sub-JavaScriptCore-JavaScriptCore-pro-install_subtargets- ordered] Errore 2 make[2]: uscita dalla directory "/home/nicola/src/qt5/qt5/qtwebkit/WebKitBuild/Release" make[1]: *** [module-qtwebkit-install] Errore 2 make[1]: uscita dalla directory "/home/nicola/src/qt5/qt5" make: *** [sub-qtwebkit-pri-install_subtargets] Errore 2 Which is gcc version necessary? N. From robin+qt at viroteck.net Tue Oct 25 15:56:27 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Tue, 25 Oct 2011 15:56:27 +0200 Subject: [Development] error compiling In-Reply-To: <2833613.1bqNhHil1e@kubuntu> References: <2833613.1bqNhHil1e@kubuntu> Message-ID: Hi, On Tue, Oct 25, 2011 at 3:50 PM, Nicola De Filippo wrote: > ../../../Source/JavaScriptCore/wtf/NullPtr.h:48:1: error: identifier ‘nullptr’ > will become a keyword in C++0x [-Werror=c++0x-compat] You probably want to exclude QtWebkit for now. It doesn't appear to have (yet) undergone much active effort for Qt 5, and thus the snapshot in gerrit is pretty out of date. Alternatively, gcc4.5 may work. BR, Robin From kgardner at zebraimaging.com Tue Oct 25 18:18:19 2011 From: kgardner at zebraimaging.com (Keith Gardner) Date: Tue, 25 Oct 2011 11:18:19 -0500 Subject: [Development] QImage Support for Grayscale Images Message-ID: Is there a plan for adding grayscale support to QImage? I know that there are enums in place in preparation for this capability. I have also looked at the bug tracker and found pages of bugs requesting this feature. I personally would like to see it implemented because I use grayscale textures in my apps and am also using a grayscale camera. This one missing feature is forcing me to use FreeImage directly to do my load/save operations even though I want to use only use Qt data types. Thanks, Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmeyer1969+qt at gmail.com Tue Oct 25 21:38:25 2011 From: cmeyer1969+qt at gmail.com (Chris Meyer) Date: Tue, 25 Oct 2011 12:38:25 -0700 Subject: [Development] Why does QFactoryLoader and QLibrary cache information in QSettings? Message-ID: Why does QFactoryLoader and QLibrary cache information in QSettings? Does this cache information need to be available between application launches? Is there a performance reason? Are the reasons different from platform to platform? Could the use of QSettings be replaced with a local QMap object? corelib/plugin/qfactoryloader.cpp corelib/plugin/qlibrary.cpp We're trying to minimize (actually: eliminate) usage of QSettings so that helper apps embedded in our Mac OS app store application don't write to disk. From fransklaver at gmail.com Tue Oct 25 21:48:58 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Tue, 25 Oct 2011 21:48:58 +0200 Subject: [Development] Why does QFactoryLoader and QLibrary cache information in QSettings? In-Reply-To: References: Message-ID: On Tue, 25 Oct 2011 21:38:25 +0200, Chris Meyer wrote: > Why does QFactoryLoader and QLibrary cache information in QSettings? > > Does this cache information need to be available between application > launches? > > Is there a performance reason? As I always understood (from the docs), the plug-in information is stored in QSettings to speed up validation in between runs. So the first run would take slightly longer to start up than consecutive runs. > Are the reasons different from platform to platform? Not likely. > Could the use of QSettings be replaced with a local QMap object? I don't think this would add value, unless certain things are queried more often. I would expect a local variable to be sufficient. You could probably sneak around this by specifying a custom format (QSettings::registerFormat()[1]) and provide read/write functions that don't access disk. Then QSettings::setDefaultFormat()[2] to the resulting value. Hope this helps. Cheers, Frans [1] http://doc.trolltech.com/latest/qsettings.html#registerFormat [2] http://doc.trolltech.com/latest/qsettings.html#setDefaultFormat From robin+qt at viroteck.net Tue Oct 25 21:54:33 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Tue, 25 Oct 2011 21:54:33 +0200 Subject: [Development] Why does QFactoryLoader and QLibrary cache information in QSettings? In-Reply-To: References: Message-ID: Hi, On Tue, Oct 25, 2011 at 9:38 PM, Chris Meyer wrote: > Why does QFactoryLoader and QLibrary cache information in QSettings? > > Does this cache information need to be available between application launches? This thread may be relevant to you: http://www.mail-archive.com/qt5-feedback at qt.nokia.com/msg00705.html BR, Robin From cmeyer1969+qt at gmail.com Tue Oct 25 22:14:50 2011 From: cmeyer1969+qt at gmail.com (Chris Meyer) Date: Tue, 25 Oct 2011 13:14:50 -0700 Subject: [Development] Why does QFactoryLoader and QLibrary cache information in QSettings? In-Reply-To: References: Message-ID: On Tue, Oct 25, 2011 at 12:54 PM, Robin Burchell wrote: > Hi, > > On Tue, Oct 25, 2011 at 9:38 PM, Chris Meyer wrote: >> Why does QFactoryLoader and QLibrary cache information in QSettings? >> >> Does this cache information need to be available between application launches? > > This thread may be relevant to you: > http://www.mail-archive.com/qt5-feedback at qt.nokia.com/msg00705.html Perfect! For reference, I'll be using this patch (or something close) on 4.7 which came from the thread you linked to: http://pastebin.com/n9wkKXWn From kok3rs at gmail.com Tue Oct 25 22:19:29 2011 From: kok3rs at gmail.com (Antonis Tsiapaliokas) Date: Tue, 25 Oct 2011 23:19:29 +0300 Subject: [Development] New feature to qstring | QString::toBool() Message-ID: Hello I have found this feature request to bugzilla, https://bugreports.qt.nokia.com/browse/QTBUG-21384 , and i have create a patch for this http://codereview.qt-project.org/#change,7394 . Since a qstring has the toDouble, toint, toDouble, toFload etc, i think that it could be great to add this feature to qstring. Also, please read the comment from the John Brooks, which i think that he is right. So what do you think? Is there any way to add this feature or it will to hackish? (if we assume that we want to support for all the ways that a string can represent a bool...) Regards Antonis Tsiapaliokas -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph at maxiom.de Tue Oct 25 22:29:52 2011 From: christoph at maxiom.de (Christoph Feck) Date: Tue, 25 Oct 2011 22:29:52 +0200 Subject: [Development] QImage Support for Grayscale Images In-Reply-To: References: Message-ID: <201110252229.53433.christoph@maxiom.de> On Tuesday 25 October 2011 18:18:19 Keith Gardner wrote: > Is there a plan for adding grayscale support to QImage? I know > that there are enums in place in preparation for this capability. > I have also looked at the bug tracker and found pages of bugs > requesting this feature. I personally would like to see it > implemented because I use grayscale textures in my apps and am > also using a grayscale camera. This one missing feature is > forcing me to use FreeImage directly to do my load/save operations > even though I want to use only use Qt data types. > > Thanks, > Keith QImage supports 8 bit grayscale images via QImage::Format_Indexed8. Depending on how you initialize the palette, you can have value 255 mean black or white. Rendering to 8 bit images is not supported, though. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team From marius.storm-olsen at nokia.com Tue Oct 25 22:51:31 2011 From: marius.storm-olsen at nokia.com (marius.storm-olsen at nokia.com) Date: Tue, 25 Oct 2011 20:51:31 +0000 Subject: [Development] Keep dependent projects in mind when approving changes Message-ID: Hi Maintainers and Approver, Please keep in mind dependent modules when you approve and merge in changes which can lead to dependent projects failing. If you know that a commit has a risk of destabilizing other modules, please ensure that you are prepared to also do a fix in the dependent module, to help mitigate those libraries failing their CI runs. I don't have the exact case handy right now, but have been told that recent commits in QtBase has made other modules fail their CI runs. Given that non-Nokian personnel cannot yet see the CI results, please note that Nokian's need to help out a bit extra to flag the issues for others, until we have managed to put in place a system to expose the CI test results. Sorry for the inconvenience. -- .marius Head of Qt OSS From fransklaver at gmail.com Tue Oct 25 22:53:02 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Tue, 25 Oct 2011 22:53:02 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: Message-ID: Hi, On Tue, 25 Oct 2011 22:19:29 +0200, Antonis Tsiapaliokas wrote: > Also, please read the comment from the John Brooks, which i think that > he isright. So what do you think? I would say he is right. He strongly hints at the possibility that bool is too context dependent. And I agree with that. This thing is tricky to tackle. QString was created to easily handle localization. Chances are you are going to not only interpret true/false, but also ja/(nee|nein|nej), oui/non, si/no and whatever may mean true or yes (or OK?) in whatever language. What if a language introduces a new word to mean true? You just don't have to handle natural language issues with doubles, floats and integers, which is why that can be done by QString hands down. I think deciding on the meaning of a string is one of the things better left to its user. Outside the string you know exactly what you expect. A number, a word, what language the word is going to be in, which words are going to mean 'true', which are 'false' and which should produce an error. bool yes = (str.toInt() != 0); bool yes = (str.compare(tr("true"), Qt::CaseInsensitive) == 0); bool yes = (str.compare("true", Qt::CaseInsensitive) == 0); bool yes = QVariant(str).toBool(); // tricky but might work Based on the fact that you need a lot of information to correctly interpret the string into a boolean value, I would say this can't really cover a lot of common cases without being a hackish blob of code. It is probably better to not include this in QString. Cheers, Frans From thiago at kde.org Tue Oct 25 22:57:35 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 25 Oct 2011 22:57:35 +0200 Subject: [Development] Why does QFactoryLoader and QLibrary cache information in QSettings? In-Reply-To: References: Message-ID: <3697240.OPUEeCghOF@tjmaciei-mobl2> On Tuesday, 25 de October de 2011 12.38.25, Chris Meyer wrote: > Why does QFactoryLoader and QLibrary cache information in QSettings? It doesn't. Nor anymore, in Qt 5, since 8ed47d961dc7e6f161030654d11cd330a542eadf. The reason it did that is because it cached the determination of whether a file that looked like a plugin was actually a plugin. See the email that Robin linked to. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago at kde.org Tue Oct 25 23:01:43 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 25 Oct 2011 23:01:43 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: Message-ID: <1936959.zcCqCOUUE9@tjmaciei-mobl2> On Tuesday, 25 de October de 2011 23.19.29, Antonis Tsiapaliokas wrote: > Hello > > I have found this feature request to bugzilla, > https://bugreports.qt.nokia.com/browse/QTBUG-21384 , and i have create a > patch for this http://codereview.qt-project.org/#change,7394 . Since a > qstring has the toDouble, toint, toDouble, toFload etc, i think that it > could be great to add this feature to qstring. Also, please read the comment > from the John Brooks, which i think that he is right. So what do you think? > Is there any way to add this feature or it will to hackish? (if we assume > that we want to support for all the ways that a string can represent a > bool...) QVariant has toBool just like it has toDouble and toInt, so I think it makes sense to have it in QString and in QByteArray. So I recommend: 1) document very well what is true and what isn't 2) make sure all three classes work the same way. If not, change them so that they all have toBool() const and they all operate equally. 3) add unit tests 4) ensure that QVariant::toBool calls into QString::toBool and QByteArray::toBool, as applicable. Note pending the commits by Jędrzej that are refactoring the QVariant internals. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From dhaivatpandya at gmail.com Tue Oct 25 23:09:07 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Tue, 25 Oct 2011 16:09:07 -0500 Subject: [Development] QtWeb In-Reply-To: <978tsv.ltmbo8.2s76lc-qmf@drake.jerryweb.org> References: <978tsv.ltmbo8.2s76lc-qmf@drake.jerryweb.org> Message-ID: So, the general sentiment is something like an MVC type framework, so, we will most likely work on that. If you want to be a part of this, please fork this repo: https://gitorious.org/qtweb/qtweb I will accept pull requests if they make any remotest idea of "sense" right now, since we dont' have much going. The first thing (if you would like to contribute) would be to read up on FCGI, and start writing the FCGI IO library in Qt. If you don't want to contribute code, tell us want you want in the actual framework, so that it will be included eventually. As for the HTTP server, we will most likely have to borrow some code to being with, (and parts of the QDjangoHttpServer can be a candidate), but, once we get up and running, we should be good. Also, as most people use Apache, we should have support (through FCGI) for that as well, IMO. Lastly, ties to a scripting language would be excellent, and it would be great if we could start with Lua since it is dead simple to tie in with C/C++ code, and then add Python capability as we get going farther into the project. On Tue, Oct 25, 2011 at 5:55 AM, wrote: > Not sure if it is of interest if your focus is on fcgi but I have a > qt-based http server I'd be happy to contribute: > > > http://opensource.bolloretelecom.eu/projects/qdjango/browser/src/QDjangoHttpServer.h > > Am at qtdd11 if you want to talk. > > -- > Jeremy > On 25/10/11 04:38 Dhaivat Pandya wrote: > > QtWeb: https://gitorious.org/qtweb/qtweb > > > Web framework for Qt, right now, all we have decided is the FastCGI base. > > > Either it can be a Wt style framework with Qt components, or, a more > traditional MVC framework (more community support on the latter, so that is > mostly likely the POA). > > > Fork, commit, push. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago at kde.org Tue Oct 25 23:15:35 2011 From: thiago at kde.org (Thiago Macieira) Date: Tue, 25 Oct 2011 23:15:35 +0200 Subject: [Development] Keep dependent projects in mind when approving changes In-Reply-To: References: Message-ID: <10410862.n3gfBNfhIh@tjmaciei-mobl2> On Tuesday, 25 de October de 2011 20.51.31, marius.storm-olsen at nokia.com wrote: > Hi Maintainers and Approver, > > Please keep in mind dependent modules when you approve and merge in > changes which can lead to dependent projects failing. If you know that a > commit has a risk of destabilizing other modules, please ensure that you > are prepared to also do a fix in the dependent module, to help mitigate > those libraries failing their CI runs. Adding my voice to Marius's: please try to type make in every module (or the biggest modules) if you make API changes in Qt of any kind. That's true even for when the CI system reports everything in the public. Most approvers trust that the author has compiled almost everything and will not bother to check if the contribution causes such a breakage. That means if you cause them too often, it looks bad on you. In theory, every contributor and approver is responsible for keeping the reference platforms working. In practice, that's very hard to do for some, who don't have access to all of them. If you're uncertain, from the discussion here in Munich, we recommend that you attempt a "buddy system": ask on this mailing list if there's anyone with the missing platforms who could help you. For that, I encourage you to create repositories on Gitorious, GitHub or BitBucket with your own changes, so that your buddies test and report back. And to stress the point: - any API changes should be reviewed with the maintainer - any permanent source-incompatible changes must be approved by Lars -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From illissius at gmail.com Tue Oct 25 23:32:51 2011 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Tue, 25 Oct 2011 23:32:51 +0200 Subject: [Development] QtWeb In-Reply-To: References: <978tsv.ltmbo8.2s76lc-qmf@drake.jerryweb.org> Message-ID: 2011/10/25 Dhaivat Pandya : > So, the general sentiment is something like an MVC type framework, so, we > will most likely work on that. > If you want to be a part of this, please fork this > repo: https://gitorious.org/qtweb/qtweb > I will accept pull requests if they make any remotest idea of "sense" right > now, since we dont' have much going. > The first thing (if you would like to contribute) would be to read up on > FCGI, and start writing the FCGI IO library in Qt. > If you don't want to contribute code, tell us want you want in the actual > framework, so that it will be included eventually. > As for the HTTP server, we will most likely have to borrow some code to > being with, (and parts of the QDjangoHttpServer can be a candidate), but, > once we get up and running, we should be good. > Also, as most people use Apache, we should have support (through FCGI) for > that as well, IMO. > Lastly, ties to a scripting language would be excellent, and it would be > great if we could start with Lua since it is dead simple to tie in with > C/C++ code, and then add Python capability as we get going farther into the > project. I am not participating in this project and don't know anything about anything, but wouldn't JavaScript be the logical choice, given that it already ships with and is integrated to some degree with Qt? > On Tue, Oct 25, 2011 at 5:55 AM, wrote: >> >> Not sure if it is of interest if your focus is on fcgi but I have a >> qt-based http server I'd be happy to contribute: >> >> >> http://opensource.bolloretelecom.eu/projects/qdjango/browser/src/QDjangoHttpServer.h >> >> Am at qtdd11 if you want to talk. >> >> -- >> Jeremy >> On 25/10/11 04:38 Dhaivat Pandya wrote: >> >> QtWeb: https://gitorious.org/qtweb/qtweb >> >> >> Web framework for Qt, right now, all we have decided is the FastCGI base. >> >> >> Either it can be a Wt style framework with Qt components, or, a more >> traditional MVC framework (more community support on the latter, so that is >> mostly likely the POA). >> >> >> Fork, commit, push. >> >> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Work is punishment for failing to procrastinate effectively. From fransklaver at gmail.com Tue Oct 25 23:33:04 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Tue, 25 Oct 2011 23:33:04 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <1936959.zcCqCOUUE9@tjmaciei-mobl2> References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> Message-ID: Hi, On Tue, 25 Oct 2011 23:01:43 +0200, Thiago Macieira wrote: > QVariant has toBool just like it has toDouble and toInt, so I think it > makes sense to have it in QString and in QByteArray. It makes sense from an equal-API point of view. On the other hand, QVariant has a significantly different task than QString does -- QString is, AFAIK, not a union replacement like QVariant is. Does it make sense to add QString::toBool() from a basic task perspective? > 1) document very well what is true and what isn't Restricting the use to e.g. English only, would not be really useful when parsing (localized) user input, although I don't think this would happen a lot. I only know of a few cases where an end-user is expected to explicitly type yes or no into an input field, and those are command line tools. Wouldn't that be pretty much the only use case? I might have overlooked things. It's getting late anyway. > 2) make sure all three classes work the same way. If not, change them so > that they all have toBool() const and they all operate equally. > > 3) add unit tests > > 4) ensure that QVariant::toBool calls into QString::toBool and > QByteArray::toBool, as applicable. Note pending the commits by Jędrzej > that are refactoring the QVariant internals. If QString::toBool() is added, would there also be a need for something like static QString::boolean(bool value, char format = 't')? Cheers, Frans From thiago at kde.org Wed Oct 26 08:10:02 2011 From: thiago at kde.org (Thiago Macieira) Date: Wed, 26 Oct 2011 08:10:02 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> Message-ID: <3093976.pLZdUD33hK@tjmaciei-mobl2> On Tuesday, 25 de October de 2011 23.33.04, Frans Klaver wrote: > > 1) document very well what is true and what isn't > > Restricting the use to e.g. English only, would not be really useful when > parsing (localized) user input, although I don't think this would happen a > lot. I only know of a few cases where an end-user is expected to > explicitly type yes or no into an input field, and those are command line > tools. Wouldn't that be pretty much the only use case? > > I might have overlooked things. It's getting late anyway. I agree with your argument, I just don't think it's applicable. QString is not localised and has never promised to be. QString::number generates C-locale numbers and toInt/toDouble parse C-locale; QDate::toString generates C-locale dates (or should), etc. If you want localised information, you should use QLocale. > > 2) make sure all three classes work the same way. If not, change them so > > that they all have toBool() const and they all operate equally. > > > > 3) add unit tests > > > > 4) ensure that QVariant::toBool calls into QString::toBool and > > QByteArray::toBool, as applicable. Note pending the commits by Jędrzej > > that are refactoring the QVariant internals. > > If QString::toBool() is added, would there also be a need for something > like static QString::boolean(bool value, char format = 't')? It's much easier to use the ternary operator and just select which option you want to use. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From markc at renta.net Wed Oct 26 08:13:38 2011 From: markc at renta.net (Mark Constable) Date: Wed, 26 Oct 2011 16:13:38 +1000 Subject: [Development] QtWeb In-Reply-To: References: Message-ID: <2204798.sjspC4COLi@g2> On 2011-10-25 11:32 PM, Gábor Lehel wrote: > > Lastly, ties to a scripting language would be excellent, and it > > would be great if we could start with Lua since it is dead simple > > to tie in with C/C++ code, and then add Python capability as we > > get going farther into the project. > > I am not participating in this project and don't know anything about > anything, but wouldn't JavaScript be the logical choice, given that it > already ships with and is integrated to some degree with Qt? Totally agree, V8 in particular. The main reason for focussing on JS is that the language itself is entirely async which fits in nicely with Qt's signal/slot async event driven potential. Personally, I have no interest in using anything but Javascript, with PHP as a sync based fallback because of the huge amount of "legacy" web apps available. https://github.com/nikhilm/confkdein11/tree/master/qtjs From jan-arve.saether at nokia.com Wed Oct 26 08:31:37 2011 From: jan-arve.saether at nokia.com (jan-arve.saether at nokia.com) Date: Wed, 26 Oct 2011 06:31:37 +0000 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <3093976.pLZdUD33hK@tjmaciei-mobl2> References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> Message-ID: ext Thiago Macieira wrote on 2011-10-26: > On Tuesday, 25 de October de 2011 23.33.04, Frans Klaver wrote: >>> 1) document very well what is true and what isn't >> >> Restricting the use to e.g. English only, would not be really useful >> when parsing (localized) user input, although I don't think this >> would happen a lot. I only know of a few cases where an end-user is >> expected to explicitly type yes or no into an input field, and those >> are command line tools. Wouldn't that be pretty much the only use case? >> >> I might have overlooked things. It's getting late anyway. > > I agree with your argument, I just don't think it's applicable. > QString is not localised and has never promised to be. QString::number > generates C-locale numbers and toInt/toDouble parse C-locale; > QDate::toString generates C-locale dates (or should), etc. If you want > localised information, you should use QLocale. > >>> 2) make sure all three classes work the same way. If not, change >>> them so that they all have toBool() const and they all operate equally. >>> >>> 3) add unit tests >>> >>> 4) ensure that QVariant::toBool calls into QString::toBool and >>> QByteArray::toBool, as applicable. Note pending the commits by >>> Jędrzej that are refactoring the QVariant internals. >> >> If QString::toBool() is added, would there also be a need for >> something like static QString::boolean(bool value, char format = 't')? > > It's much easier to use the ternary operator and just select which > option you want to use. > I think the same argumentation (there is another, simple way) can be used for debating whether we should add QString::toBool(). I think I'm opposed to adding these functions, just because I don't see how they add value: Consider this code: bool parseOk; if (str.toBool(&parseOk)) { if (parseOk) enableSuperFastRenderer(); } then this: if (str == QLatin1String("true")) { enableSuperFastRenderer(); } which would you prefer? regards, Jan-Arve From fransklaver at gmail.com Wed Oct 26 08:39:31 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Wed, 26 Oct 2011 08:39:31 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> Message-ID: On Wed, Oct 26, 2011 at 8:31 AM, wrote: > Consider this code: > > bool parseOk; > if (str.toBool(&parseOk)) { >    if (parseOk) >        enableSuperFastRenderer(); > } I think that in most, if not all cases, the parseOk argument would or even should be omitted (just like with QVariant): if (str.toBool()) { enableSuperFastRenderer(); } because the results will be exactly the same as your example. > then this: > > if (str == QLatin1String("true")) { >    enableSuperFastRenderer(); > } > > which would you prefer? I ask you the same question. Cheers, Frans From fransklaver at gmail.com Wed Oct 26 08:51:46 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Wed, 26 Oct 2011 08:51:46 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <3093976.pLZdUD33hK@tjmaciei-mobl2> References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> Message-ID: On Wed, Oct 26, 2011 at 8:10 AM, Thiago Macieira wrote: > I agree with your argument, I just don't think it's applicable. QString is not > localised and has never promised to be. QString::number generates C-locale > numbers and toInt/toDouble parse C-locale; QDate::toString generates C-locale > dates (or should), etc. If you want localised information, you should use > QLocale. Given that information and assuming that the results match QVariant, I don't see any reason not to include QString::toBool(). The assumption will obviously always be valid if QVariant uses QString::toBool() for parsing. >> If QString::toBool() is added, would there also be a need for something >> like static QString::boolean(bool value, char format = 't')? > > It's much easier to use the ternary operator and just select which option you > want to use. Consider: bool b = true; QString str1 = b?"treu":"false"; if (str1.toBool()) { // we never get here... } QString str2 = QString::boolean(b); if (str2.toBool()) { // we will get here } This example might be a bit far-fetched and I do agree that the advantage, if any, would be fairly small. QString::boolean() would always produce a value that is guaranteed to be correctly parsed by QString::toBool(). The ternery operator not so much. Also the user doesn't have to explicitly know about which values evaluate to true in QString::toBool() to enter the correct value; from an API perspective I think it would make sense to enable a black-box round-trip. Cheers, Frans From jan-arve.saether at nokia.com Wed Oct 26 09:15:59 2011 From: jan-arve.saether at nokia.com (jan-arve.saether at nokia.com) Date: Wed, 26 Oct 2011 07:15:59 +0000 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> Message-ID: ext Frans Klaver wrote on 2011-10-26: > On Wed, Oct 26, 2011 at 8:31 AM, wrote: > >> Consider this code: >> >> bool parseOk; >> if (str.toBool(&parseOk)) { >>    if (parseOk) >>        enableSuperFastRenderer(); >> } > > I think that in most, if not all cases, the parseOk argument would or > even should be omitted (just like with QVariant): > > if (str.toBool()) { > enableSuperFastRenderer(); > } > > because the results will be exactly the same as your example. > >> then this: >> >> if (str == QLatin1String("true")) { >>    enableSuperFastRenderer(); >> } >> >> which would you prefer? > > I ask you the same question. > Ok, so toBool() will return false if it fails. Then you would need the not-so-nice code for checking for false: bool parseOk; if (!str.toBool(&parseOk)) { if (parseOk) disableSuperFastRenderer(); } regards, Jan-Arve From andre at familiesomers.nl Wed Oct 26 09:21:41 2011 From: andre at familiesomers.nl (Andre Somers) Date: Wed, 26 Oct 2011 09:21:41 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> Message-ID: <4EA7B505.7000600@familiesomers.nl> Op 26-10-2011 8:39, Frans Klaver schreef: > On Wed, Oct 26, 2011 at 8:31 AM, wrote: > >> Consider this code: >> >> bool parseOk; >> if (str.toBool(&parseOk)) { >> if (parseOk) >> enableSuperFastRenderer(); >> } > I think that in most, if not all cases, the parseOk argument would or > even should be omitted (just like with QVariant): > > if (str.toBool()) { > enableSuperFastRenderer(); > } > > because the results will be exactly the same as your example. > >> then this: >> >> if (str == QLatin1String("true")) { >> enableSuperFastRenderer(); >> } >> >> which would you prefer? > I ask you the same question. IMHO, there is a big difference between a string that correctly converts to false, and one that can not be converted to a boolean. Do you really wish to make that difference invisible? That would not only break symetry with QString::toInt, it would lead to an IMHO useless method. I agree with Jan Arve on this topic. You need to have verification that a conversion succeeded. André From fransklaver at gmail.com Wed Oct 26 10:02:36 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Wed, 26 Oct 2011 10:02:36 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <4EA7B505.7000600@familiesomers.nl> References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> <4EA7B505.7000600@familiesomers.nl> Message-ID: On Wed, Oct 26, 2011 at 9:21 AM, Andre Somers wrote: > IMHO, there is a big difference between a string that correctly converts > to false, and one that can not be converted to a boolean. Do you really > wish to make that difference invisible? Certainly not. > I agree with Jan Arve on this topic. You need to have verification that > a conversion succeeded. I do agree that you need to have the verification available, however, I daresay in a lot of cases the need for it is not that big. I at least don't care if or why a boolean conversion fails in a lot of cases (with QVariant currently). Then there's readability for slightly more complex situations. Assuming that QString::toBool() acts like QVariant::toBool() and returns true if the contents are "1", "true", or "y", false otherwise, consider the following: bool ok; bool result = str.toBool(&ok); if (ok) { if (result) enableSuperFastRenderer(); else disableSuperFastRenderer(); } else { doSomethingSmart(); } against if (str.compare("true", Qt::CaseInsensitive) == 0 || str.compare("y", Qt::CaseInsensitive) == 0 || str == "1" ) { enableSuperFastRenderer(); } else if (str.compare("false", Qt::CaseInsensitive) == 0 || str.compare("n", Qt::CaseInsensitive) == 0 || str == "0") { disableSuperFastRenderer(); } else { doSomethingSmart(); } If I had the choice, I'd take the first option over the second. And honestly, what are the odds someone instead would write: if (str == QLatin1String("true")) { enableSuperFastRenderer(); } else { disableSuperFastRenderer(); } What would you do if you couldn't parse string. Make the assumption you can, and enable the super fast renderer? All at the risk of playing the devil's advocate, of course. Cheers, Frans From rasky at develer.com Wed Oct 26 11:12:36 2011 From: rasky at develer.com (Giovanni Bajo) Date: Wed, 26 Oct 2011 11:12:36 +0200 Subject: [Development] Gerrit HTTP vs HTTPS Message-ID: Hi, I'm not sure what's the correct "meta-list" now (list for discussion on the qt-project itself), so I'm posting there. I apologize in advance if it is not the correct list. Gerrit is available on both http:// and https://, but since it's using HTTP basic-auth, passwords are transmitted in clear over the wire. Does the non-secure instance serve any purpose? Otherwise, I guess it's better to disable it, or at least change it to a redirector to the secure instance. Thanks! -- Giovanni Bajo :: rasky at develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4819 bytes Desc: not available URL: From thiago at kde.org Wed Oct 26 11:18:10 2011 From: thiago at kde.org (Thiago Macieira) Date: Wed, 26 Oct 2011 11:18:10 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: Message-ID: <2424940.XqeZldd5ej@tjmaciei-mobl2> On Wednesday, 26 de October de 2011 07.15.59, jan-arve.saether at nokia.com wrote: > bool parseOk; > if (!str.toBool(&parseOk)) { > if (parseOk) > disableSuperFastRenderer(); > } bool parseOk if (!str.toBool(&parseOk) && parseOk) disableSuperFastRenderer(); Or you can accept that, if the user types crap instead of "false", it's false. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From andre at familiesomers.nl Wed Oct 26 12:50:19 2011 From: andre at familiesomers.nl (Andre Somers) Date: Wed, 26 Oct 2011 12:50:19 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> <4EA7B505.7000600@familiesomers.nl> Message-ID: <4EA7E5EB.2030109@familiesomers.nl> Op 26-10-2011 10:02, Frans Klaver schreef: > On Wed, Oct 26, 2011 at 9:21 AM, Andre Somers wrote: > >> IMHO, there is a big difference between a string that correctly converts >> to false, and one that can not be converted to a boolean. Do you really >> wish to make that difference invisible? > Certainly not. > >> I agree with Jan Arve on this topic. You need to have verification that >> a conversion succeeded. > I do agree that you need to have the verification available, however, > I daresay in a lot of cases the need for it is not that big. I at > least don't care if or why a boolean conversion fails in a lot of > cases (with QVariant currently). OK, you might be right about that. > > Then there's readability for slightly more complex situations. > Assuming that QString::toBool() acts like QVariant::toBool() and > returns true if the contents are "1", "true", or "y", false otherwise, > consider the following: > > bool ok; > bool result = str.toBool(&ok); > if (ok) { > if (result) > enableSuperFastRenderer(); > else > disableSuperFastRenderer(); > } else { > doSomethingSmart(); > } Note that the verification flag would be optional anyway. If you return false if ok is false, then you can easily choose if you need verification or not. It just needs to be clearly documented. However, if you think that it would be good for readability, wouldn't it then make sense to have a way to do this in a localized way as well? The various true & false strings could conceivably be in QLocale? Otherwise, you still end up in the same situation if your application needs localization (and most do, I think). > > What would you do if you couldn't parse string. Make the assumption > you can, and enable the super fast renderer? I *might* want to bail out and warn the user, but it depends on the situation, of course. André From fransklaver at gmail.com Wed Oct 26 13:01:52 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Wed, 26 Oct 2011 13:01:52 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <4EA7E5EB.2030109@familiesomers.nl> References: <1936959.zcCqCOUUE9@tjmaciei-mobl2> <3093976.pLZdUD33hK@tjmaciei-mobl2> <4EA7B505.7000600@familiesomers.nl> <4EA7E5EB.2030109@familiesomers.nl> Message-ID: On Wed, Oct 26, 2011 at 12:50 PM, Andre Somers wrote: > Note that the verification flag would be optional anyway. If you return > false if ok is false, then you can easily choose if you need > verification or not. It just needs to be clearly documented. As always. > However, if > you think that it would be good for readability, wouldn't it then make > sense to have a way to do this in a localized way as well? The various > true & false strings could conceivably be in QLocale? Otherwise, you > still end up in the same situation if your application needs > localization (and most do, I think). The localized way should be done the same way as one would handle localized numbers (like properly handling 1,234.56 and 1.234,56). >> What would you do if you couldn't parse string. Make the assumption >> you can, and enable the super fast renderer? > I *might* want to bail out and warn the user, but it depends on the > situation, of course. Of course. I would think however that in these cases you shouldn't really be explicitly relying on QString::toBool(), but that is a completely different discussion altogether. From jeremy.laine at m4x.org Wed Oct 26 15:15:11 2011 From: jeremy.laine at m4x.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Wed, 26 Oct 2011 15:15:11 +0200 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups Message-ID: Some time ago a bug [1] was filed against Qt pointing out the fact there that Qt4 has no API for doing DNS SRV lookups. Such lookups are important for implementing both XMPP and SIP applications, and as such I wrote an implementation for the QXmpp [2] project which has been in use for over a year. I got some initial feedback from Qt developers both on the merge request on gitorious [3] and on IRC, and I adjusted the code accordingly. I would like to get some further feedback on the API / implementation in order to hopefully get the code merged into Qt, and have submitted it to gerrit for review [4]. Comments are welcome! Jeremy [1] https://bugreports.qt.nokia.com/browse/QTBUG-10481 [2] http://code.google.com/p/qxmpp/ [3] http://qt.gitorious.org/qt/qt/merge_requests/887 [4] http://codereview.qt-project.org/7475 From san at sansano.inf.utfsm.cl Thu Oct 27 17:42:01 2011 From: san at sansano.inf.utfsm.cl (Sergio Ahumada Navea) Date: Thu, 27 Oct 2011 17:42:01 +0200 Subject: [Development] Gerrit HTTP vs HTTPS In-Reply-To: References: Message-ID: <4EA97BC9.5060504@sansano.inf.utfsm.cl> On 10/26/2011 11:12 AM, Giovanni Bajo wrote: > Hi, > > I'm not sure what's the correct "meta-list" now (list for discussion on the qt-project itself), so I'm posting there. I apologize in advance if it is not the correct list. > > Gerrit is available on both http:// and https://, but since it's using HTTP basic-auth, passwords are transmitted in clear over the wire. Does the non-secure instance serve any purpose? Otherwise, I guess it's better to disable it, or at least change it to a redirector to the secure instance. > > Thanks! Hi, You might want to vote/comment/follow this task https://bugreports.qt.nokia.com/browse/QTQAINFRA-167 Cheers, -- Sergio Ahumada Navea san at sansano.inf.utfsm.cl From shane.kearns at accenture.com Wed Oct 26 17:56:49 2011 From: shane.kearns at accenture.com (shane.kearns at accenture.com) Date: Wed, 26 Oct 2011 15:56:49 +0000 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups In-Reply-To: References: Message-ID: <7163F5DC5711224C8D28FF8936EA845A04B4BD@048-CH1MPN1-054.048d.mgd.msft.net> > -----Original Message----- > On Behalf Of Jeremy Lainé > Sent: Wednesday, October 26, 2011 14:15 > To: development at qt-project.org > Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups > ... > I would like to get some further feedback on the API / implementation > in order to hopefully get the code merged into Qt, and have submitted > it to gerrit for review [4]. Comments are welcome! > > Jeremy > Hi Jeremy, I suggest QDnsServiceInfo and QDnsServiceRecord for the API class names. While a "host" is well known enough for the QHostInfo class name you started with, a "srv" isn't obvious. It is a "service" (with "SRV" being a DNS abbreviation, like "A") To avoid ambiguity with other types of service, QDnsService makes sense to me. Shane ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From robin+qt at viroteck.net Wed Oct 26 18:34:20 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Wed, 26 Oct 2011 18:34:20 +0200 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups In-Reply-To: <7163F5DC5711224C8D28FF8936EA845A04B4BD@048-CH1MPN1-054.048d.mgd.msft.net> References: <7163F5DC5711224C8D28FF8936EA845A04B4BD@048-CH1MPN1-054.048d.mgd.msft.net> Message-ID: Hi, On Wed, Oct 26, 2011 at 5:56 PM, wrote: > To avoid ambiguity with other types of service, QDnsService makes sense to me. It's also a lot easier to pronounce, which is always a good thing. :) BR, Robin From olivier at woboq.com Wed Oct 26 19:44:15 2011 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 26 Oct 2011 19:44:15 +0200 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups In-Reply-To: References: Message-ID: <2478062.lAXoXOmD7x@l09> On Wednesday 26 October 2011 15:15:11 Jeremy Lainé wrote: > Some time ago a bug [1] was filed against Qt pointing out the fact there > that Qt4 has no API for doing DNS SRV lookups. Such lookups are important > for implementing both XMPP and SIP applications, and as such I wrote an > implementation for the QXmpp [2] project which has been in use for over a > year. I got some initial feedback from Qt developers both on the merge > request on gitorious [3] and on IRC, and I adjusted the code accordingly. > > I would like to get some further feedback on the API / implementation in > order to hopefully get the code merged into Qt, and have submitted it to > gerrit for review [4]. Comments are welcome! I'll sumarize my comment on gitorious and what we talked about here: I think this could be a great addition in QtNetwork (I have not read the code itself). But I this this is a low level class (in the same sens as QHostInfo is) What i mean by that is that in practice, developers do not use QHostInfo dirrectly, they just want just to write socket->connect("website.example", "xmpp-server"); And then Qt takes care of internal of looking up the SRV records, so application developper do not need to care. So that API should be IMHO: QAbstractSocket::connectToHost(QString hostName, QString service, …) (so you connect to a service name instead of a port number) Qt would internaly look the srv record of the dns and if they do not exist, connect to the default port for that service. Meaning less code for the application to write (the way the old KExtandedSocket wokred http://api.kde.org/3.5-api/kdelibs- apidocs/kdecore/html/classKExtendedSocket.html#93e3553faaf7dcd4191a3562bc10cc27 or KNetwork::KBufferedSocket http://api.kde.org/4.x-api/kdelibs- apidocs/kdecore/html/classKNetwork_1_1KBufferedSocket.html ) And also, QHostInfo should be static QHostInfo::lookupHost(QString hostName, QString service, QObject *receiver, char *slot); And add a portNumber accessor to QHostInfo This is also how works the POSIX API (we use) to lookup DNS int getaddrinfo(const char *node, const char *service, const struct addrinfo *hints, struct addrinfo **res); (Notice you should provide a service string, currently Qt do not provide one) So that class really fits into Qt. But only as a low level class (that could even stay internal maybe, I still fail to see a use case for it that is not covered by the convinience i suggest) From robin+qt at viroteck.net Wed Oct 26 20:03:56 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Wed, 26 Oct 2011 20:03:56 +0200 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups In-Reply-To: <2478062.lAXoXOmD7x@l09> References: <2478062.lAXoXOmD7x@l09> Message-ID: Hi, On Wed, Oct 26, 2011 at 7:44 PM, Olivier Goffart wrote: > So that class really fits into Qt. But only as a low level class > (that could even stay internal maybe, I still fail to see a use case for it > that is not covered by the convinience i suggest) (without ever having actually read the standard to date, despite using it quite a lot...) Writing classes implementing DNS-SD would probably be a lot easier with this, for example. There are undoubtedly others. It is low level, sure. That doesn't mean it isn't useful for people doing relatively low-level things. I'm not against 'prettier' API built on top of this as convenience building blocks, but I would quite like the base to be there if I need it, too, without having to reinvent the wheel. BR, Robin From olivier at woboq.com Wed Oct 26 20:04:13 2011 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 26 Oct 2011 20:04:13 +0200 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups In-Reply-To: References: <2478062.lAXoXOmD7x@l09> Message-ID: <1595951.9IMqJgRCla@l09> On Wednesday 26 October 2011 20:03:56 Robin Burchell wrote: > Hi, > > On Wed, Oct 26, 2011 at 7:44 PM, Olivier Goffart wrote: > > So that class really fits into Qt. But only as a low level class > > (that could even stay internal maybe, I still fail to see a use case for > > it that is not covered by the convinience i suggest) > > (without ever having actually read the standard to date, despite using > it quite a lot...) Writing classes implementing DNS-SD would probably > be a lot easier with this, for example. There are undoubtedly others. > > It is low level, sure. That doesn't mean it isn't useful for people > doing relatively low-level things. Don't get me wrong ;-) I fully agree with that. > I'm not against 'prettier' API > built on top of this as convenience building blocks, but I would quite > like the base to be there if I need it, too, without having to > reinvent the wheel. From dangelog at gmail.com Wed Oct 26 20:44:09 2011 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 26 Oct 2011 20:44:09 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: Message-ID: 2011/10/25 Antonis Tsiapaliokas : > So what do you think? Is there any way to add this feature or it will to > hackish? (if we assume that we want to support for all the ways that a > string can represent a bool...) I think we should then really discuss about what should be considered to be "true" (and what to be "false", so we also figure out if a "bool *ok" parameter is actually needed or not). In my humble opinion, a case insensitive comparison against the string "true" is too generic and weak (not to mention English-only). If that's a way of checking some user input I think it's simply a bad idea to have it inside QString. For instance, Perl thinks that empty string and the literal "0" are false, and any other string is true. In Python and JS only the empty strings are false. Should Qt do something similar? -- Giuseppe D'Angelo From christoph at maxiom.de Wed Oct 26 23:27:13 2011 From: christoph at maxiom.de (Christoph Feck) Date: Wed, 26 Oct 2011 23:27:13 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: Message-ID: <201110262327.13699.christoph@maxiom.de> On Tuesday 25 October 2011 22:53:02 Frans Klaver wrote: > Hi, > > On Tue, 25 Oct 2011 22:19:29 +0200, Antonis Tsiapaliokas > > wrote: > > Also, please read the comment from the John Brooks, which i think > > that he isright. So what do you think? > > I would say he is right. He strongly hints at the possibility that > bool is too context dependent. And I agree with that. > > This thing is tricky to tackle. QString was created to easily > handle localization. Chances are you are going to not only > interpret true/false, but also ja/(nee|nein|nej), oui/non, si/no > and whatever may mean true or yes (or OK?) in whatever language. > What if a language introduces a new word to mean true? You just > don't have to handle natural language issues with doubles, floats > and integers, which is why that can be done by QString hands down. As far as I remember, POSIX locales offer strings or regexps for YES and NO, so it might be possible to add something to QLocale to access those strings. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team From olivier at woboq.com Wed Oct 26 23:28:53 2011 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 26 Oct 2011 23:28:53 +0200 Subject: [Development] QT_DEPRECATED_SINCE and QT_DISABLE_DEPRECATED_BEFORE Message-ID: <28690528.yQRvmtI1D4@l09> Hi, First, let me re-introduce (for those that did not know) QT_DEPRECATED_SINCE: It was added in the commit 6618dd877f83be56d140882a2f6c3fa5a985c2d2 The goal of this macro is to "versionize" when a a function is deprecated. Then, one can define in his project QT_DISABLE_DEPRECATED_BEFORE to control which function to enable/disable. The goals are: - let the developpers of application hide the deprecated symbols while compiling their application, forcing compile error in order to avoid using them by mistake - "Customer" that build Qt and do not need binary compatibility could compile Qt without the deprecated functions. The idea was that QT_DISABLE_DEPRECATED_BEFORE would be defined to 5.0 by default (that would not change for all the Qt 5.x series) Meaning that, by default, all the API deprecated in 5.0 would not be avaliabe unless one define in his .pro file QT_DISABLE_DEPRECATED_BEFORE to a version lower than 4.x (to enable all the compatibility with qt4) Also, all the code within QT_DEPRECATED_SINCE(5,0) need to be inline so it is bnary compatible to enable or disable those function. (Of course, it is not binary comatible to change it to 5.1) Anyway, one of the problem that we saw is that the code within QT_DEPRECATED_SINCE(5,0) tend not to compile[1] That could be fixed by the compilerwarning test in qt-qa which test that all our headers compile without warnings (or errors) with different flags. But the other problem is that it is hard to deprecate function that are used by other module, as putting them inside QT_DEPRECATED_SINCE break the compilation. After a small talk with David Faure, we came to the conclusion that maybe it would be a good temporary solution to define QT_DISABLE_DEPRECATED_BEFORE to 4.9 to re-enable (temporarely) all the deprecated function, untill the feature freeze. So others module have time to adapt to the deprecation warnings. The change is there: http://codereview.qt-project.org/#change,7494 Comments? -- Olivier [1] (cf e19292120b33f55a10f233bdaab7030f4299db66 or http://codereview.qt-project.org/7493 From dhaivatpandya at gmail.com Thu Oct 27 00:02:22 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Wed, 26 Oct 2011 17:02:22 -0500 Subject: [Development] QtWeb In-Reply-To: <2204798.sjspC4COLi@g2> References: <2204798.sjspC4COLi@g2> Message-ID: I also agree. Javascript just never occurred to me... On Wed, Oct 26, 2011 at 1:13 AM, Mark Constable wrote: > On 2011-10-25 11:32 PM, Gábor Lehel wrote: > > > Lastly, ties to a scripting language would be excellent, and it > > > would be great if we could start with Lua since it is dead simple > > > to tie in with C/C++ code, and then add Python capability as we > > > get going farther into the project. > > > > I am not participating in this project and don't know anything about > > anything, but wouldn't JavaScript be the logical choice, given that it > > already ships with and is integrated to some degree with Qt? > > Totally agree, V8 in particular. The main reason for focussing on JS is > that the language itself is entirely async which fits in nicely with > Qt's signal/slot async event driven potential. Personally, I have no > interest in using anything but Javascript, with PHP as a sync based > fallback because of the huge amount of "legacy" web apps available. > > https://github.com/nikhilm/confkdein11/tree/master/qtjs > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago at kde.org Thu Oct 27 07:23:58 2011 From: thiago at kde.org (Thiago Macieira) Date: Thu, 27 Oct 2011 07:23:58 +0200 Subject: [Development] QT_DEPRECATED_SINCE and QT_DISABLE_DEPRECATED_BEFORE In-Reply-To: <28690528.yQRvmtI1D4@l09> References: <28690528.yQRvmtI1D4@l09> Message-ID: <4632533.e3vacnqiy7@tjmaciei-mobl2> On Wednesday, 26 de October de 2011 23.28.53, Olivier Goffart wrote: > After a small talk with David Faure, we came to the conclusion that maybe > it would be a good temporary solution to define > QT_DISABLE_DEPRECATED_BEFORE to 4.9 to re-enable (temporarely) all the > deprecated function, untill the feature freeze. So others module have time > to adapt to the deprecation warnings. > > The change is there: http://codereview.qt-project.org/#change,7494 > > Comments? Qt itself needs to be built with that macro enabled. On some platforms (*cough* Windows *cough*), the compiler (*cough* MSVC *cough*) will try to export the entire class, including inline functions, so it needs to see all functions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From lars.knoll at nokia.com Thu Oct 27 08:21:12 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Thu, 27 Oct 2011 06:21:12 +0000 Subject: [Development] Keep dependent projects in mind when approving changes In-Reply-To: Message-ID: On 10/25/11 10:51 PM, "ext marius.storm-olsen at nokia.com" wrote: >Hi Maintainers and Approver, > >Please keep in mind dependent modules when you approve and merge in >changes which can lead to dependent projects failing. If you know that a >commit has a risk of destabilizing other modules, please ensure that you >are prepared to also do a fix in the dependent module, to help mitigate >those libraries failing their CI runs. > >I don't have the exact case handy right now, but have been told that >recent commits in QtBase has made other modules fail their CI runs. Let me add a bit to that. We do have multiple repositories and modules being part of Qt. Breaking source compatibility in one of them does make life difficult for the people working on the modules on top. So I would like to encourage everybody to try to find ways to do these kind of changes incrementally. If you e.g. plan on renaming a method, the best way would be to add the new signature and mark the old one as deprecated. Give a heads up and we can then remove the old one after 2-3 weeks when all dependent modules have changed to the new API. In addition, I'd like to be added as a reviewer for changes that break source compatibility with the public API of Qt 4.x. Please also add some comment in the changes file in this case. Cheers, Lars From robin+qt at viroteck.net Thu Oct 27 09:17:41 2011 From: robin+qt at viroteck.net (Robin Burchell) Date: Thu, 27 Oct 2011 09:17:41 +0200 Subject: [Development] Keep dependent projects in mind when approving changes In-Reply-To: References: Message-ID: Hi Lars, On Thu, Oct 27, 2011 at 8:21 AM, wrote: > In addition, I'd like to be added as a reviewer for changes that break > source compatibility with the public API of Qt 4.x. Please also add some > comment in the changes file in this case. Following up on this, do you have any information about this source-incompatible change: http://lists.qt-project.org/pipermail/development/2011-October/000030.html Other reasons why I'd like this change justified: - It's also going to be a lot less efficient to have a QContactLocalId as a QHash key in Qt5 - QString keys are naturally less memory-efficient. BR, Robin From rohan.mcgovern at nokia.com Thu Oct 27 09:43:22 2011 From: rohan.mcgovern at nokia.com (Rohan McGovern) Date: Thu, 27 Oct 2011 17:43:22 +1000 Subject: [Development] Keep dependent projects in mind when approving changes In-Reply-To: References: Message-ID: <1319701059-sup-4967@bq-menoetius> marius.storm-olsen at nokia.com said: > Hi Maintainers and Approver, > > Please keep in mind dependent modules when you approve and merge in > changes which can lead to dependent projects failing. If you know that a > commit has a risk of destabilizing other modules, please ensure that you > are prepared to also do a fix in the dependent module, to help mitigate > those libraries failing their CI runs. > > I don't have the exact case handy right now, but have been told that > recent commits in QtBase has made other modules fail their CI runs. > > Given that non-Nokian personnel cannot yet see the CI results, please note > that Nokian's need to help out a bit extra to flag the issues for others, > until we have managed to put in place a system to expose the CI test > results. > Just to add a bit. Although the CI results are not publicly available in full, it is possible to be appraised of many source-incompatible changes by keeping an eye on changes from Qt Submodule Update Bot ( http://codereview.qt-project.org/#dashboard,1000191 ). That bot will twice daily attempt to update qt5.git with the tip of all modules, so most significant source breaks ought to be detected within 12 hours of submission. Here is an example of an update attempt which succeeded on the first try: http://codereview.qt-project.org/6795 And an example of an update attempt which took several attempts as various source-incompatible changes were handled: http://codereview.qt-project.org/7109 From fransklaver at gmail.com Thu Oct 27 11:48:52 2011 From: fransklaver at gmail.com (Frans Klaver) Date: Thu, 27 Oct 2011 11:48:52 +0200 Subject: [Development] [Interest] Qt 5 worries - A plea for software rendering fallbacks In-Reply-To: <785FCF147323E247A7822F328786814D0188EBA9@grzsms406.andritz.com> References: <785FCF147323E247A7822F328786814D0188EBA9@grzsms406.andritz.com> Message-ID: Hi, On Thu, Oct 27, 2011 at 11:37 AM, Schimkowitsch Robert wrote: > I see there's no Qt5-Feedback list up and running, so I'll post here in the > meantime. AFAIK all qt5 feedback can go onto the development mailing list now. It's probably best to continue the discussion there. Cheers, Frans > I have really big issues with the "OpenGL ES" decision. I have developed a > 2D-graphic engine for Windows (kinda similar to GraphicsView in its > abilities), based on OpenGL. > > Over the years, I had tons of trouble with > -) Memory or resource leaks in graphic card drivers > -) Crashes when using Remote Desktop > -) Drivers only working in single monitor mode > -) Issues where the graphic output would look different on a certain graphic > card (an absolute no-go for a technical application that people depend on) > > After battling those issues for several years, I had to drop back to the > Microsoft OpenGL 1.1 software driver. Fortunately, it is  quite fast enough > for what I need. It does have it's flaws, but at least I know them and can > work around them. > > Please, take it from someone who has been trough the fires: Provide a pure > software rendering fallback, at least for QWidget and QGraphicsView-based > applications! > > Allow the developer to choose this fallback! > > It makes all the difference between testing the resulting application once, > or on every graphic card with every driver version a customer might use. > Which is obviously impossible. > > Kind regards > > Robert Schimkowitsch From simon.hausmann at nokia.com Thu Oct 27 12:21:18 2011 From: simon.hausmann at nokia.com (Simon Hausmann) Date: Thu, 27 Oct 2011 12:21:18 +0200 Subject: [Development] [Interest] Qt 5 worries - A plea for software rendering fallbacks In-Reply-To: References: <785FCF147323E247A7822F328786814D0188EBA9@grzsms406.andritz.com> Message-ID: <201110271221.18654.simon.hausmann@nokia.com> On Thursday, October 27, 2011 11:48:52 AM ext Frans Klaver wrote: > Hi, > > On Thu, Oct 27, 2011 at 11:37 AM, Schimkowitsch Robert > wrote: > > > I see there's no Qt5-Feedback list up and running, so I'll post here in the > > meantime. > > AFAIK all qt5 feedback can go onto the development mailing list now. > It's probably best to continue the discussion there. > > Cheers, > Frans > > > > I have really big issues with the "OpenGL ES" decision. I have developed a > > 2D-graphic engine for Windows (kinda similar to GraphicsView in its > > abilities), based on OpenGL. > > > > Over the years, I had tons of trouble with > > -) Memory or resource leaks in graphic card drivers > > -) Crashes when using Remote Desktop > > -) Drivers only working in single monitor mode > > -) Issues where the graphic output would look different on a certain graphic > > card (an absolute no-go for a technical application that people depend on) > > > > After battling those issues for several years, I had to drop back to the > > Microsoft OpenGL 1.1 software driver. Fortunately, it is quite fast enough > > for what I need. It does have it's flaws, but at least I know them and can > > work around them. > > > > Please, take it from someone who has been trough the fires: Provide a pure > > software rendering fallback, at least for QWidget and QGraphicsView-based > > applications! > > > > Allow the developer to choose this fallback! That fallback exists, doesn't it? I mean, QWidget and QGraphicsView contine to use the raster paint engine by default for the backing store in Qt 5. Nothing changed here :) On a related note: The Chromium folks seem to be rather successful in shipping WebGL on Windows on top of Angle ( http://code.google.com/p/angleproject/ ). It would be nice to try out Angle for QtQuick/OpenGL in Qt 5 on Windows. Simon > > It makes all the difference between testing the resulting application once, > > or on every graphic card with every driver version a customer might use. > > Which is obviously impossible. From lars.knoll at nokia.com Thu Oct 27 12:22:45 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Thu, 27 Oct 2011 10:22:45 +0000 Subject: [Development] [Interest] Qt 5 worries - A plea for software rendering fallbacks In-Reply-To: Message-ID: On 10/27/11 11:48 AM, "ext Frans Klaver" wrote: >Hi, > >On Thu, Oct 27, 2011 at 11:37 AM, Schimkowitsch Robert > wrote: > >> I see there's no Qt5-Feedback list up and running, so I'll post here in >>the >> meantime. > >AFAIK all qt5 feedback can go onto the development mailing list now. >It's probably best to continue the discussion there. Yes. development at qt-project.org is the place for these discussions and is (so far) completely about Qt 5 :) > >Cheers, >Frans > > >> I have really big issues with the "OpenGL ES" decision. I have >>developed a >> 2D-graphic engine for Windows (kinda similar to GraphicsView in its >> abilities), based on OpenGL. >> >> Over the years, I had tons of trouble with >> -) Memory or resource leaks in graphic card drivers >> -) Crashes when using Remote Desktop >> -) Drivers only working in single monitor mode >> -) Issues where the graphic output would look different on a certain >>graphic >> card (an absolute no-go for a technical application that people depend >>on) >> >> After battling those issues for several years, I had to drop back to the >> Microsoft OpenGL 1.1 software driver. Fortunately, it is quite fast >>enough >> for what I need. It does have it's flaws, but at least I know them and >>can >> work around them. >> >> Please, take it from someone who has been trough the fires: Provide a >>pure >> software rendering fallback, at least for QWidget and >>QGraphicsView-based >> applications! To repeat it once again: QWidgets (and that includes QGraphicsView) do NOT require any OpenGL in Qt 5. Cheers, Lars >> >> Allow the developer to choose this fallback! >> >> It makes all the difference between testing the resulting application >>once, >> or on every graphic card with every driver version a customer might use. >> Which is obviously impossible. >> >> Kind regards >> >> Robert Schimkowitsch >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at nokia.com Thu Oct 27 12:30:52 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Thu, 27 Oct 2011 10:30:52 +0000 Subject: [Development] [Interest] Qt 5 worries - A plea for software rendering fallbacks In-Reply-To: <201110271221.18654.simon.hausmann@nokia.com> Message-ID: On 10/27/11 12:21 PM, "ext Simon Hausmann" wrote: [snip] > >On a related note: The Chromium folks seem to be rather successful in >shipping >WebGL on Windows on top of Angle ( http://code.google.com/p/angleproject/ >). >It would be nice to try out Angle for QtQuick/OpenGL in Qt 5 on Windows. Absolutely. We should explore both Angle and Mesa/llvmpipe as fallback options for OpenGL rendering in Qt. Another interesting question will be how to provide runtime (more exact startup-time) switching of the GL implementation. This could be required to be able to run in recovery mode on Windows and for RDP. Cheers, Lars > > >Simon > >> > It makes all the difference between testing the resulting application >>once, >> > or on every graphic card with every driver version a customer might >>use. >> > Which is obviously impossible. > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From dhaivatpandya at gmail.com Thu Oct 27 16:06:27 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Thu, 27 Oct 2011 09:06:27 -0500 Subject: [Development] QtWeb In-Reply-To: References: <2204798.sjspC4COLi@g2> Message-ID: So, as far as I see it, we will not be needing the Filter, or Access Control mechanisms for FCGI (at least to begin with), what do you guys say? On Wed, Oct 26, 2011 at 5:02 PM, Dhaivat Pandya wrote: > I also agree. Javascript just never occurred to me... > > > On Wed, Oct 26, 2011 at 1:13 AM, Mark Constable wrote: > >> On 2011-10-25 11:32 PM, Gábor Lehel wrote: >> > > Lastly, ties to a scripting language would be excellent, and it >> > > would be great if we could start with Lua since it is dead simple >> > > to tie in with C/C++ code, and then add Python capability as we >> > > get going farther into the project. >> > >> > I am not participating in this project and don't know anything about >> > anything, but wouldn't JavaScript be the logical choice, given that it >> > already ships with and is integrated to some degree with Qt? >> >> Totally agree, V8 in particular. The main reason for focussing on JS is >> that the language itself is entirely async which fits in nicely with >> Qt's signal/slot async event driven potential. Personally, I have no >> interest in using anything but Javascript, with PHP as a sync based >> fallback because of the huge amount of "legacy" web apps available. >> >> https://github.com/nikhilm/confkdein11/tree/master/qtjs >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.laine at m4x.org Thu Oct 27 16:32:25 2011 From: jeremy.laine at m4x.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Thu, 27 Oct 2011 16:32:25 +0200 Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups In-Reply-To: <7163F5DC5711224C8D28FF8936EA845A04B4BD@048-CH1MPN1-054.048d.mgd.msft.net> References: <7163F5DC5711224C8D28FF8936EA845A04B4BD@048-CH1MPN1-054.048d.mgd.msft.net> Message-ID: <49CBD8B1-5865-4FBF-9B68-AFAA1709A27C@m4x.org> > I suggest QDnsServiceInfo and QDnsServiceRecord for the API class names. > While a "host" is well known enough for the QHostInfo class name you started with, a "srv" isn't obvious. > It is a "service" (with "SRV" being a DNS abbreviation, like "A") > To avoid ambiguity with other types of service, QDnsService makes sense to me. > Ah, excellent, the names have been bothering me ever since I started writing these classes. Does anyone see a problem with QDnsServiceInfo / QDnsServiceRecord ? If not I'll update my patch with these names. Jeremy From paivi.rajala at nokia.com Thu Oct 27 17:08:32 2011 From: paivi.rajala at nokia.com (paivi.rajala at nokia.com) Date: Thu, 27 Oct 2011 15:08:32 +0000 Subject: [Development] Keep dependent projects in mind when approving changes In-Reply-To: References: Message-ID: <9FE29B091662B04B8A02813AE1A4EE92013C0789@008-AM1MPN1-043.mgdnok.nokia.com> Hi Robin, We thought that having an integer QContactLocalId is a bit too restricting. E.g. if you have a uuid as backend contact id (as the case is in JsonDb backend), it's lot simpler to treat it as a string than as an integer. Changing QContactLocalId to QString was the first step in trying to make contact ids a bit more flexible. Another step towards that direction would be to hide the internal format of backend contact id by providing a wrapper class for backend ids. This pattern has been used in Organizer, see http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemengineid.h and http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemid.h. Any other ideas about how to make handling of backend contact ids both flexible and efficient are welcome. About source-compatibility... As a Qt5 AddOn module QtPim has little less restrictions regarding source-compatibility than Essential modules, see e.g. http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition. While we try not to break source-compatibility if it's not necessary, we also see moving from QtMobility to QtPim as a good opportunity to simplify QtPim APIs a bit and to make some other changes, which might be more difficult later. Some of the changes are already visible in qtpim repository, some are still in the planning phase. We will tell more about the changes and reasoning behind them in the near future. Br, Päivi -----Original Message----- From: development-bounces+paivi.rajala=nokia.com at qt-project.org [mailto:development-bounces+paivi.rajala=nokia.com at qt-project.org] On Behalf Of ext Robin Burchell Sent: 27. lokakuuta 2011 10:18 To: Knoll Lars (Nokia-MP-Qt/Oslo) Cc: development at qt-project.org Subject: Re: [Development] Keep dependent projects in mind when approving changes Hi Lars, On Thu, Oct 27, 2011 at 8:21 AM, wrote: > In addition, I'd like to be added as a reviewer for changes that break > source compatibility with the public API of Qt 4.x. Please also add > some comment in the changes file in this case. Following up on this, do you have any information about this source-incompatible change: http://lists.qt-project.org/pipermail/development/2011-October/000030.html Other reasons why I'd like this change justified: - It's also going to be a lot less efficient to have a QContactLocalId as a QHash key in Qt5 - QString keys are naturally less memory-efficient. BR, Robin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andreas at hanssen.name Thu Oct 27 20:13:25 2011 From: andreas at hanssen.name (Andreas Aardal Hanssen) Date: Thu, 27 Oct 2011 20:13:25 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <201110262327.13699.christoph@maxiom.de> References: <201110262327.13699.christoph@maxiom.de> Message-ID: 2011/10/26 Christoph Feck > As far as I remember, POSIX locales offer strings or regexps for YES > and NO, so it might be possible to add something to QLocale to access > those strings. By auto-converting a QString to a bool we'll be adding ambiguity to Qt APIs. If there's no intuitive way to convert a QString to a boolean, then QString IMO should not provide that as a function... I find it especially disturbing that translatability and locale is considered. Literal interpretation of a string needs to be completely unambiguous, just like QString("123").toInt() is. If we add QString::toBool(), I think we are adding future bugs to applications that make use of this function. We'll find code that calls toBool() on all kinds of strings with hard-to-read outcomes. QString(QChar::Null).toBool() QString("0").toBool() QString("null").toBool() QString("nil").toBool() QString().toBool() QString("false").toBool() QString("no").toBool() QString("not").toBool() QString("!").toBool() QString("negative").toBool() Do any of these examples have any _intuitive_, unambiguous return values? I vote -1 on this feature. Just write: if (value == "true") { } or if (value.compare("true", Qt::CaseInsensitive) == 0) { } or write a grammar and a proper parser :-). -- Andreas Aardal Hanssen From andre at familiesomers.nl Thu Oct 27 21:25:28 2011 From: andre at familiesomers.nl (Andre Somers) Date: Thu, 27 Oct 2011 21:25:28 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: References: <201110262327.13699.christoph@maxiom.de> Message-ID: <4EA9B028.6000702@familiesomers.nl> Op 27-10-2011 20:13, Andreas Aardal Hanssen schreef: > 2011/10/26 Christoph Feck >> As far as I remember, POSIX locales offer strings or regexps for YES >> and NO, so it might be possible to add something to QLocale to access >> those strings. > By auto-converting a QString to a bool we'll be adding ambiguity to Qt > APIs. If there's no intuitive way to convert a QString to a boolean, > then QString IMO should not provide that as a function... I find it > especially disturbing that translatability and locale is considered. > Literal interpretation of a string needs to be completely unambiguous, > just like QString("123").toInt() is. QString("1,234").toDouble() also isn't all that clear either, only the QLocale version of those is localized. With a US locale, that would result in 1234.0 (more than a thousand), while in the Netherlands, it would be 1.234 (one and a bit). *If* QString::toBool is introduced, there needs to be a properly localized or at least localizable version in QLocale as well, I think. André From thiago at kde.org Thu Oct 27 22:19:51 2011 From: thiago at kde.org (Thiago Macieira) Date: Thu, 27 Oct 2011 22:19:51 +0200 Subject: [Development] New feature to qstring | QString::toBool() In-Reply-To: <4EA9B028.6000702@familiesomers.nl> References: <4EA9B028.6000702@familiesomers.nl> Message-ID: <1491472.VdHXeiVXSG@doriath> On Thursday, 27 de October de 2011 21:25:28 Andre Somers wrote: > QString("1,234").toDouble() also isn't all that clear either, only the > QLocale version of those is localized. > With a US locale, that would result in 1234.0 (more than a thousand), > while in the Netherlands, it would be 1.234 (one and a bit). Right: that needs to be fixed: QString should operate ONLY on the C locale. If you need anything with other locales, it should be clearly marked (like "%L1" in arg()) or you should use QLocale. The same goes for QDate and QTime. Does anyone volunteer to do this change? > > If QString::toBool is introduced, there needs to be a properly > localized or at least localizable version in QLocale as well, I think. > > André -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago at kde.org Fri Oct 28 12:58:43 2011 From: thiago at kde.org (Thiago Macieira) Date: Fri, 28 Oct 2011 12:58:43 +0200 Subject: [Development] V8's location In-Reply-To: <18951072.WCAbSzNWtu@tjmaciei-mobl2> References: <201110241011.00871.simon.hausmann@nokia.com> <18951072.WCAbSzNWtu@tjmaciei-mobl2> Message-ID: <2096870.aMQIkY2amg@doriath> On Monday, 24 de October de 2011 14:15:38 Thiago Macieira wrote: > > Isn't the right solution then to get your patch either upstream or into > > the > > Qt copy? > > Yes and no. Yes, I should get my fixes into the Qt copy (at least). But > it's not a full solution since very often I have pending changes or > in-progress development that I committed. [...] > But please move the submodule to qt5.git. Can we move the submodule? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From simon.hausmann at nokia.com Fri Oct 28 13:06:50 2011 From: simon.hausmann at nokia.com (Simon Hausmann) Date: Fri, 28 Oct 2011 13:06:50 +0200 Subject: [Development] V8's location In-Reply-To: <2096870.aMQIkY2amg@doriath> References: <18951072.WCAbSzNWtu@tjmaciei-mobl2> <2096870.aMQIkY2amg@doriath> Message-ID: <201110281306.50692.simon.hausmann@nokia.com> On Friday, October 28, 2011 12:58:43 PM ext Thiago Macieira wrote: > On Monday, 24 de October de 2011 14:15:38 Thiago Macieira wrote: > > > Isn't the right solution then to get your patch either upstream or into > > > the > > > Qt copy? > > > > Yes and no. Yes, I should get my fixes into the Qt copy (at least). But > > it's not a full solution since very often I have pending changes or > > in-progress development that I committed. > [...] > > But please move the submodule to qt5.git. > > Can we move the submodule? Well, you as maintainer of QtCore decide, right? Simon From stephen.kelly at kdab.com Fri Oct 28 13:13:20 2011 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Fri, 28 Oct 2011 13:13:20 +0200 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? Message-ID: <1501696.SO6s6Am3CA@hal> Hi, == Summary == I'm considering adding some cmake files to Qt, which would be installed by Qt, and which would make it easier for CMake based projects to depend on Qt. I'm CC'ing the cmake developers too see what they think of the idea too. == Clarification == To avoid misunderstanding: * This proposal is not about porting the Qt build system to CMake. * This would not make Qt depend on CMake at all * I am proposing to add some plain text files to the Qt repo for installation * Those plain text files would need to be generated while building Qt (using existing mechanisms, like perl). == How CMake finds packages == (Skip this section if you already know how CMake finds packages) For those who have not used CMake before, it has two ways to find dependencies: * If you want to find a dependency, you write a Find.cmake file or use an existing one. Usually this Find.cmake will not be installed. * If you want to be easily found for others to depend on, you write a Config.cmake file and install it to a location CMake will use to find things like that. I assume this is similar to how pkgconfig works, but I have never used pkgconfig. This is most common in the case of projects which use CMake themselves, but there's no reason projects which do not use CMake can't provide similar files. This becomes even more useful with recent CMake features based on finding packages. Either way, if someone does this in CMake: find_package(Package) the result is the ability to use the headers and libraries from Package. CMake ships with FindQt4.cmake, so anyone using CMake uses find_package(Qt4) to be able to use Qt 4. == Qt5Config.cmake == I propose that we ship a Qt5Config.cmake file with Qt which we install, along with macros equivalent to what is currently in Qt4Macros.cmake, and some Targets.cmake files. Then find_package(Qt5) in CMake would use that Config file and there would be no need for a FindQt5.cmake. The advantage of this are: * It allows people using CMake to start experimenting with Qt 5 ports sooner * When new features arrive in Qt (such as new libraries like QtDeclarative was in Qt 4) we can update the Qt5Config file immediately and test the new features more easily. * We can use the cmake imported targets feature to more easily support debug and release versions on Windows. * KDE does not need a separate FindQt.cmake to the one shipped by CMake. == Maintainance == KDAB (specifically myself) can maintain these CMakes files. We have other engineers with both Qt and CMake competencies, and there are more people in the CMake and KDE communities with cross-competencies. That is assuming it works of course. I haven't even prototyped yet in case there is some reason this shouldn't be done. I'm quite confident it will work though. I can't think of any reason this effort should be prevented, but if you have a reason, please let me know. I'm looking for early objections before I start to do any work. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3636 bytes Desc: not available URL: From thiago at kde.org Fri Oct 28 13:56:20 2011 From: thiago at kde.org (Thiago Macieira) Date: Fri, 28 Oct 2011 13:56:20 +0200 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: <1501696.SO6s6Am3CA@hal> References: <1501696.SO6s6Am3CA@hal> Message-ID: <4290345.Zvx1mKeUHZ@doriath> On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: > * If you want to be easily found for others to depend on, you write a > Config.cmake file and install it to a location CMake will use > to find things like that. I assume this is similar to how pkgconfig > works, but I have never used pkgconfig. Just like pkgconfig, I'd recommend that we make it one file per library, not one global Qt5Config.cmake. Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake and it includes NO other Qt addon. For those addons, they need to provide the Config files themselves. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago at kde.org Fri Oct 28 13:58:58 2011 From: thiago at kde.org (Thiago Macieira) Date: Fri, 28 Oct 2011 13:58:58 +0200 Subject: [Development] V8's location In-Reply-To: <201110281306.50692.simon.hausmann@nokia.com> References: <2096870.aMQIkY2amg@doriath> <201110281306.50692.simon.hausmann@nokia.com> Message-ID: <3744090.Vti1h7oV3F@doriath> On Friday, 28 de October de 2011 13:06:50 you wrote: > On Friday, October 28, 2011 12:58:43 PM ext Thiago Macieira wrote: > > On Monday, 24 de October de 2011 14:15:38 Thiago Macieira wrote: > > > > Isn't the right solution then to get your patch either upstream or > > > > into > > > > the > > > > Qt copy? > > > > > > Yes and no. Yes, I should get my fixes into the Qt copy (at least). But > > > it's not a full solution since very often I have pending changes or > > > in-progress development that I committed. > > > > [...] > > > > > But please move the submodule to qt5.git. > > > > Can we move the submodule? > > Well, you as maintainer of QtCore decide, right? No, since it's not part of QtCore. The qtbase.git maintainer (Lars) could decide that. Also, I have not yet understood how the qt5.pro and overall structure work. I know how to build in one of my builds, but the other one fails (with the EXACT same sources). Besides, I have no idea if there are CI or QA rules that need to be updated. I'd rather not do it myself. Better let someone who has created a module before do it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From stephen.kelly at kdab.com Fri Oct 28 14:21:23 2011 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Fri, 28 Oct 2011 14:21:23 +0200 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: <4290345.Zvx1mKeUHZ@doriath> References: <1501696.SO6s6Am3CA@hal> <4290345.Zvx1mKeUHZ@doriath> Message-ID: <2917101.QGB9UMCzEJ@hal> On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote: > On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: > > * If you want to be easily found for others to depend on, you write a > > > > Config.cmake file and install it to a location CMake > > will use> > > to find things like that. I assume this is similar to how pkgconfig > > works, but I have never used pkgconfig. > > Just like pkgconfig, I'd recommend that we make it one file per library, not > one global Qt5Config.cmake. What I want to investigate (I haven't yet, but I'm confident it will work) is if we can have both. We could have Qt5Core.cmake, Qt5Gui.cmake etc, and Qt5Config would be an aggregate which include()s the other configs based on the FIND_COMPONENTS. find_package(Qt5 COMPONENTS QtCore) or find_package(Qt5 COMPONENTS QtGui) for example. > Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake and it > includes NO other Qt addon. For those addons, they need to provide the > Config files themselves. Can you remind me where to find out what Qt5Essentials is or where I can find out? Searching in http://wiki.qt-project.org/ isn't throwing up anything. Is it roughly the contents of qtbase.git? Or does it include qtdeclarative.git too? Details like what would be included in Qt5Config could be discussed once there's some prototyping happening. I don't really feel strongly about it as long as it's roughly equivalent to what was made available by FindQt4.cmake. I'll wait a bit for other objections before prototyping though anyway. Then we can start looking at the real details. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From lars.knoll at nokia.com Fri Oct 28 14:38:38 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Fri, 28 Oct 2011 12:38:38 +0000 Subject: [Development] V8's location In-Reply-To: <3744090.Vti1h7oV3F@doriath> Message-ID: On 10/28/11 1:58 PM, "ext Thiago Macieira" wrote: >On Friday, 28 de October de 2011 13:06:50 you wrote: >> On Friday, October 28, 2011 12:58:43 PM ext Thiago Macieira wrote: >> > On Monday, 24 de October de 2011 14:15:38 Thiago Macieira wrote: >> > > > Isn't the right solution then to get your patch either upstream or >> > > > into >> > > > the >> > > > Qt copy? >> > > >> > > Yes and no. Yes, I should get my fixes into the Qt copy (at least). >>But >> > > it's not a full solution since very often I have pending changes or >> > > in-progress development that I committed. >> > >> > [...] >> > >> > > But please move the submodule to qt5.git. >> > >> > Can we move the submodule? >> >> Well, you as maintainer of QtCore decide, right? > >No, since it's not part of QtCore. The qtbase.git maintainer (Lars) could >decide that. > >Also, I have not yet understood how the qt5.pro and overall structure >work. I >know how to build in one of my builds, but the other one fails (with the >EXACT >same sources). > >Besides, I have no idea if there are CI or QA rules that need to be >updated. >I'd rather not do it myself. > >Better let someone who has created a module before do it. We've been moving this lib quite a bit already. If we move it again, I'd prefer it would end up at it's final location. The move was done before we had the decision to keep QtCore independent of V8 and to separate the QJS* classes and the QML engine into it's own module. With the above decision it might make sense to move V8, the QJS* classes and the QML engine all into the same shared library. Kent & Aaron, any thoughts? Cheers, Lars From sh at theharmers.co.uk Fri Oct 28 15:11:08 2011 From: sh at theharmers.co.uk (Sean Harmer) Date: Fri, 28 Oct 2011 14:11:08 +0100 Subject: [Development] New circular buffer container for Qt5 Message-ID: <2448442.11HaI3QjHb@titan> Hi, I would like to introduce a new generic container class to Qt, QCircularBuffer. This email is to see if there are any objections to doing so. This class is similar to QVector but it provides circular semantics. For example, appending to an already full circular buffer will overwrite the oldest item i.e. it forms a kind of LRU cache. The API is essentially a Qt'ified version of the boost::circular_buffer [1] API so hopefully people will find it simple to use. This type of container is very useful for logging or data acquisition/visualisation applications as it provides a static memory profile and fast performance for adding new data to the container. Appending and prepending are always O(1) operations which fills in a gap in the performance characteristics offered by the existing Qt containers. It tries to be smart when modifying the contents of the container by depending upon the type of item being stored. Copying is also kept to a minimum to improve performance (see the insert() and remove()) functions. It is a template class so no extra code is generated in the Qt shared libraries. It is fairly trivial to use this class as the underlying container of a bounded buffer that can be used with the producer-consumer pattern. I am willing to also contribute code for this to the Qt project if people think it would be useful. I have already used this container in several applications and it comes with comprehensive documentation and an auto test. Kind regards, Sean [1] - http://www.boost.org/doc/libs/1_47_0/libs/circular_buffer/doc/circular_buffer.html From thiago at kde.org Fri Oct 28 15:26:18 2011 From: thiago at kde.org (Thiago Macieira) Date: Fri, 28 Oct 2011 15:26:18 +0200 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: <2917101.QGB9UMCzEJ@hal> References: <1501696.SO6s6Am3CA@hal> <4290345.Zvx1mKeUHZ@doriath> <2917101.QGB9UMCzEJ@hal> Message-ID: <4078753.Lrv1z0VIHg@doriath> On Friday, 28 de October de 2011 14:21:23 Stephen Kelly wrote: > > Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake and it > > includes NO other Qt addon. For those addons, they need to provide the > > Config files themselves. > > Can you remind me where to find out what Qt5Essentials is or where I can > find out? Searching in http://wiki.qt-project.org/ isn't throwing up > anything. Is it roughly the contents of qtbase.git? Or does it include > qtdeclarative.git too? Qt 5 = Qt Essentials + Qt Addons Qt Essentials = QtCore, QtNetwork, QtGui, QtWebKit, QtDeclarative/Qt Quick plus QtWidgets on desktop Technically speaking, in order to build those you're going to need some other dependencies (QtSvg, QtXmlPatterns, V8), but they don't constitute part of the required Essentials API, just as non-Qt dependencies don't either. It also specifically excludes (for the moment) some libs inside qtbase.git that should be moved out, like QtDBus, QtXml and QtSql. Everything else is part of the Addons, like QtSvg, QtXmlPatterns, QtMultimediaKit and all other new addons to be created by the community or contributed from KDE or other sources. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago at kde.org Fri Oct 28 15:30:45 2011 From: thiago at kde.org (Thiago Macieira) Date: Fri, 28 Oct 2011 15:30:45 +0200 Subject: [Development] New circular buffer container for Qt5 In-Reply-To: <2448442.11HaI3QjHb@titan> References: <2448442.11HaI3QjHb@titan> Message-ID: <3380740.dRaxqbVSD9@doriath> On Friday, 28 de October de 2011 14:11:08 Sean Harmer wrote: > This class is similar to QVector but it provides circular semantics. For > example, appending to an already full circular buffer will overwrite the > oldest item i.e. it forms a kind of LRU cache. The API is essentially a > Qt'ified version of the boost::circular_buffer [1] API so hopefully people > will find it simple to use. I'd like to see this API. > Appending and prepending are always O(1) operations which fills in a gap in > the performance characteristics offered by the existing Qt containers. How does it implement copy-on-write semantics? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From sh at theharmers.co.uk Fri Oct 28 15:45:21 2011 From: sh at theharmers.co.uk (Sean Harmer) Date: Fri, 28 Oct 2011 14:45:21 +0100 Subject: [Development] New circular buffer container for Qt5 In-Reply-To: <3380740.dRaxqbVSD9@doriath> References: <2448442.11HaI3QjHb@titan> <3380740.dRaxqbVSD9@doriath> Message-ID: <5262560.FkL2zB5yQC@titan> Hi, On Friday 28 October 2011 15:30:45 Thiago Macieira wrote: > On Friday, 28 de October de 2011 14:11:08 Sean Harmer wrote: > > This class is similar to QVector but it provides circular semantics. For > > example, appending to an already full circular buffer will overwrite the > > oldest item i.e. it forms a kind of LRU cache. The API is essentially a > > Qt'ified version of the boost::circular_buffer [1] API so hopefully > > people will find it simple to use. > > I'd like to see this API. You can see the patch in this old MR (see qcircularbuffer.h): https://qt.gitorious.org/qt/qtbase/merge_requests/60 If there is interest I'll submit it to gerrit using the new route for submission. > > Appending and prepending are always O(1) operations which fills in a gap > > in the performance characteristics offered by the existing Qt > > containers. > How does it implement copy-on-write semantics? It uses QSharedData[Pointer]. Cheers, Sean From lars.knoll at nokia.com Fri Oct 28 15:45:43 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Fri, 28 Oct 2011 13:45:43 +0000 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: <4078753.Lrv1z0VIHg@doriath> Message-ID: On 10/28/11 3:26 PM, "ext Thiago Macieira" wrote: >On Friday, 28 de October de 2011 14:21:23 Stephen Kelly wrote: >> > Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake >>and it >> > includes NO other Qt addon. For those addons, they need to provide the >> > Config files themselves. >> >> Can you remind me where to find out what Qt5Essentials is or where I can >> find out? Searching in http://wiki.qt-project.org/ isn't throwing up >> anything. Is it roughly the contents of qtbase.git? Or does it include >> qtdeclarative.git too? > >Qt 5 = Qt Essentials + Qt Addons > >Qt Essentials = QtCore, QtNetwork, QtGui, QtWebKit, QtDeclarative/Qt Quick > plus QtWidgets on desktop > >Technically speaking, in order to build those you're going to need some >other >dependencies (QtSvg, QtXmlPatterns, V8), but they don't constitute part >of the >required Essentials API, just as non-Qt dependencies don't either. It >also >specifically excludes (for the moment) some libs inside qtbase.git that >should >be moved out, like QtDBus, QtXml and QtSql. > >Everything else is part of the Addons, like QtSvg, QtXmlPatterns, >QtMultimediaKit and all other new addons to be created by the community >or >contributed from KDE or other sources. That's not quite up to date. The latest list can be found at http://developer.qt.nokia.com/wiki/Qt_5.0, and I think Henry has been sending this link a couple of times to the qt5-feedback list. Cheers, Lars From lars.knoll at nokia.com Fri Oct 28 14:44:36 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Fri, 28 Oct 2011 12:44:36 +0000 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: <1501696.SO6s6Am3CA@hal> Message-ID: Hi Stephen, On 10/28/11 1:13 PM, "ext Stephen Kelly" wrote: > >Hi, > >== Summary == > >I'm considering adding some cmake files to Qt, which would be installed >by Qt, >and which would make it easier for CMake based projects to depend on Qt. > >I'm CC'ing the cmake developers too see what they think of the idea too. > >== Clarification == > >To avoid misunderstanding: > >* This proposal is not about porting the Qt build system to CMake. >* This would not make Qt depend on CMake at all >* I am proposing to add some plain text files to the Qt repo for >installation >* Those plain text files would need to be generated while building Qt >(using >existing mechanisms, like perl). > >== How CMake finds packages == > >(Skip this section if you already know how CMake finds packages) > >For those who have not used CMake before, it has two ways to find >dependencies: > >* If you want to find a dependency, you write a Find.cmake file >or use > an existing one. Usually this Find.cmake will not be >installed. > >* If you want to be easily found for others to depend on, you write a > Config.cmake file and install it to a location CMake will >use to > find things like that. I assume this is similar to how pkgconfig >works, but > I have never used pkgconfig. > > This is most common in the case of projects which use CMake >themselves, > but there's no reason projects which do not use CMake can't provide > similar files. This becomes even more useful with recent CMake >features > based on finding packages. > >Either way, if someone does this in CMake: > >find_package(Package) > >the result is the ability to use the headers and libraries from Package. > >CMake ships with FindQt4.cmake, so anyone using CMake uses > >find_package(Qt4) > >to be able to use Qt 4. > >== Qt5Config.cmake == > >I propose that we ship a Qt5Config.cmake file with Qt which we install, >along >with macros equivalent to what is currently in Qt4Macros.cmake, and some >Targets.cmake files. > >Then find_package(Qt5) in CMake would use that Config file and there >would be no >need for a FindQt5.cmake. > >The advantage of this are: > >* It allows people using CMake to start experimenting with Qt 5 ports >sooner >* When new features arrive in Qt (such as new libraries like >QtDeclarative was >in Qt 4) we can update the Qt5Config file immediately and test the new >features >more easily. >* We can use the cmake imported targets feature to more easily support >debug >and release versions on Windows. >* KDE does not need a separate FindQt.cmake to the one shipped by CMake. > >== Maintainance == > >KDAB (specifically myself) can maintain these CMakes files. We have other >engineers with both Qt and CMake competencies, and there are more people >in >the CMake and KDE communities with cross-competencies. > >That is assuming it works of course. I haven't even prototyped yet in >case >there is some reason this shouldn't be done. I'm quite confident it will >work though. > > > >I can't think of any reason this effort should be prevented, but if you >have a >reason, please let me know. I'm looking for early objections before I >start to >do any work. I think that's reasonable in general. It's similar to what we do to support pkgconfig. I agree with Thiago's comment that this should be split and we should have one file per shared library. How is this dependency wise? Would we need to install these files into a special location and how do we know where this location is? Does supporting the feature require cmake to be installed? Cheers, Lars From lists at milliams.com Fri Oct 28 16:24:08 2011 From: lists at milliams.com (Matt Williams) Date: Fri, 28 Oct 2011 16:24:08 +0200 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: References: <1501696.SO6s6Am3CA@hal> Message-ID: On 28 October 2011 14:44, wrote: > Hi Stephen, > > On 10/28/11 1:13 PM, "ext Stephen Kelly" wrote: > >> >>Hi, >> >>== Summary == >> >>I'm considering adding some cmake files to Qt, which would be installed >>by Qt, >>and which would make it easier for CMake based projects to depend on Qt. >> >>I'm CC'ing the cmake developers too see what they think of the idea too. >> >>== Clarification == >> >>To avoid misunderstanding: >> >>* This proposal is not about porting the Qt build system to CMake. >>* This would not make Qt depend on CMake at all >>* I am proposing to add some plain text files to the Qt repo for >>installation >>* Those plain text files would need to be generated while building Qt >>(using >>existing mechanisms, like perl). >> >>== How CMake finds packages == >> >>(Skip this section if you already know how CMake finds packages) >> >>For those who have not used CMake before, it has two ways to find >>dependencies: >> >>* If you want to find a dependency, you write a Find.cmake file >>or use >>    an existing one. Usually this Find.cmake will not be >>installed. >> >>* If you want to be easily found for others to depend on, you write a >>    Config.cmake file and install it to a location CMake will >>use to >>    find things like that. I assume this is similar to how pkgconfig >>works, but >>    I have never used pkgconfig. >> >>    This is most common in the case of projects which use CMake >>themselves, >>    but there's no reason projects which do not use CMake can't provide >>    similar files. This becomes even more useful with recent CMake >>features >>    based on finding packages. >> >>Either way, if someone does this in CMake: >> >>find_package(Package) >> >>the result is the ability to use the headers and libraries from Package. >> >>CMake ships with FindQt4.cmake, so anyone using CMake uses >> >>find_package(Qt4) >> >>to be able to use Qt 4. >> >>== Qt5Config.cmake == >> >>I propose that we ship a Qt5Config.cmake file with Qt which we install, >>along >>with macros equivalent to what is currently in Qt4Macros.cmake, and some >>Targets.cmake files. >> >>Then find_package(Qt5) in CMake would use that Config file and there >>would be no >>need for a FindQt5.cmake. >> >>The advantage of this are: >> >>* It allows people using CMake to start experimenting with Qt 5 ports >>sooner >>* When new features arrive in Qt (such as new libraries like >>QtDeclarative was >>in Qt 4) we can update the Qt5Config file immediately and test the new >>features >>more easily. >>* We can use the cmake imported targets feature to more easily support >>debug >>and release versions on Windows. >>* KDE does not need a separate FindQt.cmake to the one shipped by CMake. >> >>== Maintainance == >> >>KDAB (specifically myself) can maintain these CMakes files. We have other >>engineers with both Qt and CMake competencies, and there are more people >>in >>the CMake and KDE communities with cross-competencies. >> >>That is assuming it works of course. I haven't even prototyped yet in >>case >>there is some reason this shouldn't be done. I'm quite confident it will >>work though. >> >> >> >>I can't think of any reason this effort should be prevented, but if you >>have a >>reason, please let me know. I'm looking for early objections before I >>start to >>do any work. > > I think that's reasonable in general. It's similar to what we do to > support pkgconfig. I agree with Thiago's comment that this should be split > and we should have one file per shared library. I think Stephen's suggestion of having one CMake file for all Qt Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the most sense, at least for specifying which QtEssential libraries to build against. It is the way most CMake files like this are done and is not dissimilar to how the existing FindQt4.cmake works. Whether we have a separate CMake file for Qt Addons (whether a separate one for each module of another combined one) becomes a separate issue. > How is this dependency wise? Would we need to install these files into a > special location and how do we know where this location is? Does > supporting the feature require cmake to be installed? >From http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package (page down a little) you have a number of options of where to install them. For example /(share|lib)/*/(cmake|CMake)/ where could be /usr and could be 'Qt5' so they could be installed in /usr/share/Qt5/cmake. There's similar special paths on Windows and Mac. For the purpose of building and installing Qt we have no dependence on CMake. As Stephen says the files could just be created from some templates using a bit of Perl (or whatever you want). For someone building a project which depends on Qt they would of course need CMake to find these files. -- Matt Williams http://milliams.com From pgquiles at elpauer.org Fri Oct 28 16:28:44 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Fri, 28 Oct 2011 16:28:44 +0200 Subject: [Development] mingw x64 Message-ID: Hi, According to the wiki, MinGW will only be supported for 32-bit compilations. http://developer.qt.nokia.com/wiki/Qt_5.0 I was wondering if there are any plans to add 64-bit to those platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit recently, which should pave the way. Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) From stephen.kelly at kdab.com Fri Oct 28 17:11:20 2011 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Fri, 28 Oct 2011 17:11:20 +0200 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: References: <1501696.SO6s6Am3CA@hal> Message-ID: <1430452.L3dRMdS181@hal> On Friday, October 28, 2011 16:24:08 Matt Williams wrote: > On 28 October 2011 14:44, wrote: > > > > I think that's reasonable in general. It's similar to what we do to > > support pkgconfig. I agree with Thiago's comment that this should be > > split and we should have one file per shared library. > > I think Stephen's suggestion of having one CMake file for all Qt > Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the > most sense, at least for specifying which QtEssential libraries to > build against. It is the way most CMake files like this are done and > is not dissimilar to how the existing FindQt4.cmake works. Whether we > have a separate CMake file for Qt Addons (whether a separate one for > each module of another combined one) becomes a separate issue. Yes, that should certainly work. The idea of one config file per library should also work: find_package(Qt5Core) find_package(Qt5Gui) find_package(Qt5Widgets) then the contents of Qt5Config would look something like (CMake code): foreach(_component Qt5_FIND_COMPONENTS) if (_component MATCHES QtCore) find_package(Qt5Core NOMODULE) endif() # ... etc endforeach() Regarding what Qt5Config should be able to find, I would say that it should be able to find QtWidgets, which is not an essential module, but an addon in Qt 5. I'll prototype it next week and see how it goes. > > > How is this dependency wise? Would we need to install these files into a > > special location and how do we know where this location is? Does > > supporting the feature require cmake to be installed? > > From http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package > (page down a little) you have a number of options of where to install > them. For example /(share|lib)/*/(cmake|CMake)/ where > could be /usr and could be 'Qt5' so they could be > installed in /usr/share/Qt5/cmake. There's similar special paths on > Windows and Mac. > > For the purpose of building and installing Qt we have no dependence on > CMake. As Stephen says the files could just be created from some > templates using a bit of Perl (or whatever you want). For someone > building a project which depends on Qt they would of course need CMake > to find these files. Yep, I have nothing more to add to this. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From lars.knoll at nokia.com Fri Oct 28 21:14:02 2011 From: lars.knoll at nokia.com (lars.knoll at nokia.com) Date: Fri, 28 Oct 2011 19:14:02 +0000 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: <1430452.L3dRMdS181@hal> Message-ID: On 10/28/11 5:11 PM, "ext Stephen Kelly" wrote: >On Friday, October 28, 2011 16:24:08 Matt Williams wrote: >> On 28 October 2011 14:44, wrote: >> > >> > I think that's reasonable in general. It's similar to what we do to >> > support pkgconfig. I agree with Thiago's comment that this should be >> > split and we should have one file per shared library. >> >> I think Stephen's suggestion of having one CMake file for all Qt >> Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the >> most sense, at least for specifying which QtEssential libraries to >> build against. It is the way most CMake files like this are done and >> is not dissimilar to how the existing FindQt4.cmake works. Whether we >> have a separate CMake file for Qt Addons (whether a separate one for >> each module of another combined one) becomes a separate issue. > >Yes, that should certainly work. The idea of one config file per library >should also work: > >find_package(Qt5Core) >find_package(Qt5Gui) >find_package(Qt5Widgets) > >then the contents of Qt5Config would look something like (CMake code): > >foreach(_component Qt5_FIND_COMPONENTS) > if (_component MATCHES QtCore) > find_package(Qt5Core NOMODULE) > endif() > # ... etc >endforeach() > >Regarding what Qt5Config should be able to find, I would say that it >should be able to find QtWidgets, which is not an essential module, but >an addon in Qt 5. > >I'll prototype it next week and see how it goes. My request here is that we don't add anything to qtbase that references stuff on top (e.g. xmlpatterns). Modules should stay (wellŠ rather: become) fully self contained. I also think that in this case each module should on installation provide the file required to support cmake as a build system. Ie. qtxmlpatterns should install one file somewhere that then magically makes find_package(Qt5XmlPatterns) work. Cheers, Lars > >> >> > How is this dependency wise? Would we need to install these files >>into a >> > special location and how do we know where this location is? Does >> > supporting the feature require cmake to be installed? >> >> From >>http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package >> (page down a little) you have a number of options of where to install >> them. For example /(share|lib)/*/(cmake|CMake)/ where >> could be /usr and could be 'Qt5' so they could be >> installed in /usr/share/Qt5/cmake. There's similar special paths on >> Windows and Mac. >> >> For the purpose of building and installing Qt we have no dependence on >> CMake. As Stephen says the files could just be created from some >> templates using a bit of Perl (or whatever you want). For someone >> building a project which depends on Qt they would of course need CMake >> to find these files. > >Yep, I have nothing more to add to this. > >Thanks, > >-- >Stephen Kelly | Software Engineer >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 >KDAB - Qt Experts - Platform-Independent Software Solutions >_______________________________________________ Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From rich at kde.org Fri Oct 28 22:54:32 2011 From: rich at kde.org (Richard Moore) Date: Fri, 28 Oct 2011 21:54:32 +0100 Subject: [Development] Qt Project Missing Infrastructure Message-ID: Qt Project Missing Infrastructure ================================= These are my notes from the 1 hour session on missing infrastructure for the Qt project taken at QtDevDays2011 at the Qt contributor meeting. * Bugtracker * Currently on Nokia can close bugs * Plan is that approvers will be able to close bugs etc. too. The idea is that the JIRA settings will mirror the relevant groups in gerrit. * The Qt JIRA will be moving to qt-project. * CI * Moving to qt-project, but it's hard. * Moving away from pulse to an open source implementation. * The current build/test farm itself will remain private to nokia. * Rohan and Sergio are working on these changes. * Intention is that 3rd parties should be able to provide additional test platforms. * Desire to allow people to test stuff without actually pushing it into the main build * Possibly a mechanism that allows people to request that the tests be run against a branch. * Who should be allowed to do this? * Possibly get approval by asking the QA team, or the maintainer of a subsystem. * In terms of development for platforms a developer doesn't have * Ask someone to test it for you * Send to build system, wait for the results! * Possibility of asking for someone to allow you access to a machine running the relvant OS. * Possibility that companies such as Nokia, Digia, Intel etc. might be willing to provide some machines for this kind of purpose. * Mailing lists * All discussion will generally happen on the public lists. * Internal Nokia lists are to close. * It's fine to have face to face discussions etc. but write them up for the mailing list if they're substantial. * If it's not on the mailing list it's not decided. Only by posting to the ML can a decision be made. * wiki.qt-project.org now exists * Intended to be a wiki for people developing Qt itself * Some docs from the existing wiki should move here * Not for info about developing /using/ qt * There are no internal docs on how things work to release * Never been written down * Also the older changelogs can never be made into a releasable state. * Do we need more MLs? * Wait and see, qt-interest has remained relatively steady * Qt-project should host the archive of all past qt releases. * Releases * Start a release team * Release team will 'start the clock' on a release, then decide when the required quality level has been reached. * The decision of if the quality is good enough will be made by the release team. * Aim to release within a month to six weeks of starting the process. * If bugs are found during testing then maintainers are the ones who should ensure they get fixed. * Need a build farm and a content distribution network * Qt project to release source code * Should we also release binaries? Probably yes, so we need to be able to build them. * Should we release binary snapshots such as those currently provided for creator? * Leave the SDK releases to nokia? * SDK release is huge, approx 1TB of data on the 1st day, 20TB in the first week. * Leaving it to nokia will delay the binary release while legal checks etc. are performed. From andy.fillebrown at gmail.com Sat Oct 29 00:06:35 2011 From: andy.fillebrown at gmail.com (andy fillebrown) Date: Fri, 28 Oct 2011 18:06:35 -0400 Subject: [Development] mingw x64 In-Reply-To: References: Message-ID: AFAIK, python enabled gdb does not compile with any version of 64 bit mingw. Cheers, ~ andy.f On Fri, Oct 28, 2011 at 10:28 AM, Pau Garcia i Quiles wrote: > Hi, > > According to the wiki, MinGW will only be supported for 32-bit compilations. > > http://developer.qt.nokia.com/wiki/Qt_5.0 > > I was wondering if there are any plans to add 64-bit to those > platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows > moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit > recently, which should pave the way. > > Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Craig.Scott at csiro.au Sat Oct 29 00:38:16 2011 From: Craig.Scott at csiro.au (Craig.Scott at csiro.au) Date: Sat, 29 Oct 2011 09:38:16 +1100 Subject: [Development] Installing Qt5Config.cmake from the Qt repo? In-Reply-To: References: Message-ID: <2948E2A9-A23E-40FC-B936-57C9CC325BFE@csiro.au> On 29/10/2011, at 6:14 AM, wrote: > > > On 10/28/11 5:11 PM, "ext Stephen Kelly" wrote: > >> On Friday, October 28, 2011 16:24:08 Matt Williams wrote: >>> On 28 October 2011 14:44, wrote: >>>> >>>> I think that's reasonable in general. It's similar to what we do to >>>> support pkgconfig. I agree with Thiago's comment that this should be >>>> split and we should have one file per shared library. >>> >>> I think Stephen's suggestion of having one CMake file for all Qt >>> Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the >>> most sense, at least for specifying which QtEssential libraries to >>> build against. It is the way most CMake files like this are done and >>> is not dissimilar to how the existing FindQt4.cmake works. Whether we >>> have a separate CMake file for Qt Addons (whether a separate one for >>> each module of another combined one) becomes a separate issue. >> >> Yes, that should certainly work. The idea of one config file per library >> should also work: >> >> find_package(Qt5Core) >> find_package(Qt5Gui) >> find_package(Qt5Widgets) >> >> then the contents of Qt5Config would look something like (CMake code): >> >> foreach(_component Qt5_FIND_COMPONENTS) >> if (_component MATCHES QtCore) >> find_package(Qt5Core NOMODULE) >> endif() >> # ... etc >> endforeach() >> >> Regarding what Qt5Config should be able to find, I would say that it >> should be able to find QtWidgets, which is not an essential module, but >> an addon in Qt 5. >> >> I'll prototype it next week and see how it goes. > While I understand that there are plenty of benefits of the new, more modular structuring of Qt5, we need to know where to draw the line on expecting devs to deal with this. The most natural way to handle the finding of Qt5 packages is using the COMPONENTS keyword with find_package(), not to have to list each module in its own find_package() command. As Stephen proposed in one of his earlier posts, the following is definitely the more natural way to pull in Qt5: find_package(Qt5 COMPONENTS QtCore QtGui ...) This also has the advantage that the dependencies between modules is handled by the Qt5Config file that provides the Qt5 info (but see further below) rather than having to rely on every dev who wants to use Qt5 to also get the dependencies right and list individual find_package() commands in the correct order. > My request here is that we don't add anything to qtbase that references > stuff on top (e.g. xmlpatterns). Modules should stay (wellŠ rather: > become) fully self contained. > > I also think that in this case each module should on installation provide > the file required to support cmake as a build system. Ie. qtxmlpatterns > should install one file somewhere that then magically makes > find_package(Qt5XmlPatterns) work. > I agree that each module should provide its own *.cmake file upon installation. If that file is installed to a well-known location, that means you won't need to have a separate find_package() call for each module. Instead, you have a top level Qt5Config which searches that well-known location and which handles them as COMPONENTS for a single find_package(Qt5) call. The top level Qt5Config would not need to hard-code any names, since it would build up a list of known components from what it finds. The dependencies between modules would be handled by the components themselves, ie if A depends on B, then the *.cmake file for A would pull in the *.cmake for B automatically, etc. One down side of this, however, is that we'd then be expecting each module maintainer to look after the relevant *.cmake file for that module. I'm all for that, but maybe not every maintainer is keen on supporting CMake files? Just a thought.... -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia From pgquiles at elpauer.org Sat Oct 29 02:43:47 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Sat, 29 Oct 2011 02:43:47 +0200 Subject: [Development] mingw x64 In-Reply-To: References: Message-ID: Hi, It works fine with the latest stable mingw-w64 release (gcc 4.6.1). See this recent thread in the mingw-w64 mailing list: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/3622 On Sat, Oct 29, 2011 at 12:06 AM, andy fillebrown wrote: > AFAIK, python enabled gdb does not compile with any version of 64 bit mingw. > > Cheers, > ~ andy.f > > > > On Fri, Oct 28, 2011 at 10:28 AM, Pau Garcia i Quiles > wrote: >> Hi, >> >> According to the wiki, MinGW will only be supported for 32-bit compilations. >> >> http://developer.qt.nokia.com/wiki/Qt_5.0 >> >> I was wondering if there are any plans to add 64-bit to those >> platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows >> moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit >> recently, which should pave the way. >> >> Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) From dhaivatpandya at gmail.com Sat Oct 29 06:13:19 2011 From: dhaivatpandya at gmail.com (Dhaivat Pandya) Date: Fri, 28 Oct 2011 23:13:19 -0500 Subject: [Development] QtWeb and the tree Message-ID: How was this made? http://wiki.qt-project.org/images/9/9c/OpenGovernance-Qt.png I would like to add QtWeb and its QtFCGI subproject to it, since those have been decided to be added on once we have a basic FCGI system going. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sierdzio at gmail.com Sat Oct 29 08:27:34 2011 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Sat, 29 Oct 2011 08:27:34 +0200 Subject: [Development] Qt Project Missing Infrastructure Message-ID: Hi, and many thanks for you email. I have some thoughts on some, mostly minor, points. I was not attending QtDD, so it might be, that it was already discussed there, if that is so - sorry. >Qt Project Missing Infrastructure >================================= >These are my notes from the 1 hour session on missing infrastructure >for the Qt project taken >at QtDevDays2011 at the Qt contributor meeting. > * It's fine to have face to face discussions etc. but write them up >for the mailing list if they're substantial. > * If it's not on the mailing list it's not decided. Only by posting >to the ML can a decision be made. That's a very important point, I guess a lot of fuss on qt5-feedback and elsewhere might have been avoided if the message about Widgets being left on raster engine was communicated clearly in advance. Oh, and since I've mentioned widgets - there still seems to be an awful lot of people not knowing the current situation. In order to solve it, could some of the Trolls, please, push a blog onto http://blog.qt.nokia.com/ and/or http://labs.qt.nokia.com/, and clarify it to more or less everybody? I know it's been said numerous times on MLs, but there remains a bunch of people still basing their opinions on the initial Qt5 announcement by Lars, which has become somewhat out-of-date now. >* wiki.qt-project.org now exists > * Some docs from the existing wiki should move here Ok, but bare in mind, that it may make some people not sure, where to look for info they need - developer.nokia.com, or qt-project.org? Also, those "some" docs will exist on both sites simutaneously? If yes, will they be kept in sync? > * Should we also release binaries? Probably yes, so we need to be >able to build them. Not releasing binaries might stop some people from downloading (especially people new to Qt - not everybody wants to start their adventure with a new toolkit by manually building and installing it), so I would strongly vote in favor of binary releases. > * Leave the SDK releases to nokia? > * SDK release is huge, approx 1TB of data on the 1st day, 20TB in >the first week. > * Leaving it to nokia will delay the binary release while legal >checks etc. are performed. Using Torrents might take some load off Nokia, while making the download process more reliable, and less prone to errors (as torrents check hashes for every part of the download). It would work flawlessly for standard releases, but might be tricky for the SDK, as it downloads packages for itself. Cheers, sierdzio -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago at kde.org Sat Oct 29 09:29:08 2011 From: thiago at kde.org (Thiago Macieira) Date: Sat, 29 Oct 2011 09:29:08 +0200 Subject: [Development] Qt Project Missing Infrastructure In-Reply-To: References: Message-ID: <4822327.sc4p7VMGsE@doriath> On Saturday, 29 de October de 2011 08:27:34 Tomasz Siekierda wrote: > Using Torrents might take some load off Nokia, while making the download > process more reliable, and less prone to errors (as torrents check hashes > for every part of the download). It would work flawlessly for standard > releases, but might be tricky for the SDK, as it downloads packages for > itself. We discussed that and, while it may take some of the load off, it will not be a complete solution. Many corporate users are behind very draconian firewalls that will not let torrents through. And even if the firewalls do allow, there's a question of whether torrents are permitted by the company's network policies. So we must offer HTTP too and use a CDN for that. Nokia already has this set up for the current system... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From rasky at develer.com Sat Oct 29 10:49:31 2011 From: rasky at develer.com (Giovanni Bajo) Date: Sat, 29 Oct 2011 10:49:31 +0200 Subject: [Development] Qt Project Missing Infrastructure In-Reply-To: <4822327.sc4p7VMGsE@doriath> References: <4822327.sc4p7VMGsE@doriath> Message-ID: <341F6EBB-AA08-4987-9B3B-543A4037196F@develer.com> Il giorno 29/ott/2011, alle ore 09:29, Thiago Macieira ha scritto: > On Saturday, 29 de October de 2011 08:27:34 Tomasz Siekierda wrote: >> Using Torrents might take some load off Nokia, while making the download >> process more reliable, and less prone to errors (as torrents check hashes >> for every part of the download). It would work flawlessly for standard >> releases, but might be tricky for the SDK, as it downloads packages for >> itself. > > We discussed that and, while it may take some of the load off, it will not be a > complete solution. Many corporate users are behind very draconian firewalls > that will not let torrents through. And even if the firewalls do allow, there's > a question of whether torrents are permitted by the company's network > policies. > > So we must offer HTTP too and use a CDN for that. Nokia already has this set up > for the current system... Obviously that's the best solution if there's someone sponsoring such a CDN, since it won't be free. Off the top of my head, we could also use Sourceforge as CDN for the time being. AFAIK, their policy allows doing that even if you are not using the rest of their infrastructure (as long as it's an open source project of course). Release managers will just have to upload releases there. -- Giovanni Bajo :: rasky at develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4819 bytes Desc: not available URL: From andy.fillebrown at gmail.com Sat Oct 29 13:52:54 2011 From: andy.fillebrown at gmail.com (andy fillebrown) Date: Sat, 29 Oct 2011 07:52:54 -0400 Subject: [Development] mingw x64 In-Reply-To: References: Message-ID: Thanks for the heads up. I'm building Qt with ruben's personal 4.6.3 now. If it works, it would be very nice to see a supported version of w64 in the Qt SDK. Cheers, ~ andy.f On Fri, Oct 28, 2011 at 8:43 PM, Pau Garcia i Quiles wrote: > Hi, > > It works fine with the latest stable mingw-w64 release (gcc 4.6.1). > See this recent thread in the mingw-w64 mailing list: > > http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/3622 > > > On Sat, Oct 29, 2011 at 12:06 AM, andy fillebrown > wrote: >> AFAIK, python enabled gdb does not compile with any version of 64 bit mingw. >> >> Cheers, >> ~ andy.f >> >> >> >> On Fri, Oct 28, 2011 at 10:28 AM, Pau Garcia i Quiles >> wrote: >>> Hi, >>> >>> According to the wiki, MinGW will only be supported for 32-bit compilations. >>> >>> http://developer.qt.nokia.com/wiki/Qt_5.0 >>> >>> I was wondering if there are any plans to add 64-bit to those >>> platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows >>> moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit >>> recently, which should pave the way. >>> >>> Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > From pgquiles at elpauer.org Sat Oct 29 14:14:10 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Sat, 29 Oct 2011 14:14:10 +0200 Subject: [Development] mingw x64 In-Reply-To: References: Message-ID: Hi, Great. Another benefit of mingw-w64 is large file support via _FILE_OFFSET_BITS=64, which makes very easy to support cross-platform applications that deal with > 2 GB files. No other MinGW flavor supports that, AFAIK. On Sat, Oct 29, 2011 at 1:52 PM, andy fillebrown wrote: > Thanks for the heads up.  I'm building Qt with ruben's personal 4.6.3 > now.  If it works, it would be very nice to see a supported version of > w64 in the Qt SDK. > > Cheers, > ~ andy.f > > > > On Fri, Oct 28, 2011 at 8:43 PM, Pau Garcia i Quiles > wrote: >> Hi, >> >> It works fine with the latest stable mingw-w64 release (gcc 4.6.1). >> See this recent thread in the mingw-w64 mailing list: >> >> http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/3622 >> >> >> On Sat, Oct 29, 2011 at 12:06 AM, andy fillebrown >> wrote: >>> AFAIK, python enabled gdb does not compile with any version of 64 bit mingw. >>> >>> Cheers, >>> ~ andy.f >>> >>> >>> >>> On Fri, Oct 28, 2011 at 10:28 AM, Pau Garcia i Quiles >>> wrote: >>>> Hi, >>>> >>>> According to the wiki, MinGW will only be supported for 32-bit compilations. >>>> >>>> http://developer.qt.nokia.com/wiki/Qt_5.0 >>>> >>>> I was wondering if there are any plans to add 64-bit to those >>>> platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows >>>> moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit >>>> recently, which should pave the way. >>>> >>>> Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) From cmeyer1969+qt at gmail.com Sat Oct 29 18:22:07 2011 From: cmeyer1969+qt at gmail.com (Chris Meyer) Date: Sat, 29 Oct 2011 09:22:07 -0700 Subject: [Development] 4.8 Build failing on Mac OS 10.7 / XCode 4.2 Message-ID: I would like to call attention to the following problem which is that the Qt 4.8 build fails using the latest Mac OS 10.7 / Xcode 4.2 tools. https://bugreports.qt.nokia.com/browse/QTBUG-20619 Somehow the RC 1 candidates are being built... so there must be some workaround. Is it possible to post the configure commands, environment, and tools used to build the official 4.8 RC's? Also, I would hope that unilaterally closing a bug that affects a primary platform (the Mac is still a primary platform, right?) with a 'Won't Fix' and closing down all discussion on the issue is a trend that won't continue. Zeno Albisser (the one who closed the bug) made some suggestions, but since the bug is closed, there is no place for developers to post information about what works and what doesn't work. My first thought is to turn off debug libs; but I'm guessing other developers have done it already so it would be nice if the bug were to remain open so that we could all benefit from trial and error until a solution is found. From thiago at kde.org Sun Oct 30 09:08:22 2011 From: thiago at kde.org (Thiago Macieira) Date: Sun, 30 Oct 2011 09:08:22 +0100 Subject: [Development] 4.8 Build failing on Mac OS 10.7 / XCode 4.2 In-Reply-To: References: Message-ID: <1500131.0t7xp3AnA4@doriath> On Saturday, 29 de October de 2011 09:22:07 Chris Meyer wrote: > I would like to call attention to the following problem which is that > the Qt 4.8 build fails using the latest Mac OS 10.7 / Xcode 4.2 tools. > > https://bugreports.qt.nokia.com/browse/QTBUG-20619 > > Somehow the RC 1 candidates are being built... so there must be some > workaround. Is it possible to post the configure commands, > environment, and tools used to build the official 4.8 RC's? > > Also, I would hope that unilaterally closing a bug that affects a > primary platform (the Mac is still a primary platform, right?) with a > 'Won't Fix' and closing down all discussion on the issue is a trend > that won't continue. You're over-reacting. That just means he (the assignee) will not fix the bug. If he had the power to close down all discussion, your email wouldn't exist and I wouldn't be typing this reply right now. Also do note that comments after the bug being closed are still received just as they were before. You can contribute more information to the report so that a solution can be found. > Zeno Albisser (the one who closed the bug) made some suggestions, but > since the bug is closed, there is no place for developers to post > information about what works and what doesn't work. My first thought > is to turn off debug libs; but I'm guessing other developers have done > it already so it would be nice if the bug were to remain open so that > we could all benefit from trial and error until a solution is found. Sure there is: the bug report. Comments are not disabled in closed bug reports. It just means Zeno is no longer looking for a solution. But if you provide one that works for everyone... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From alexis.menard at openbossa.org Sun Oct 30 11:08:07 2011 From: alexis.menard at openbossa.org (Alexis Menard) Date: Sun, 30 Oct 2011 07:08:07 -0300 Subject: [Development] 4.8 Build failing on Mac OS 10.7 / XCode 4.2 In-Reply-To: <1500131.0t7xp3AnA4@doriath> References: <1500131.0t7xp3AnA4@doriath> Message-ID: 2011/10/30 Thiago Macieira : > On Saturday, 29 de October de 2011 09:22:07 Chris Meyer wrote: >> I would like to call attention to the following problem which is that >> the Qt 4.8 build fails using the latest Mac OS 10.7 / Xcode 4.2 tools. For *your* use case. Normal and default cases work as the CI and other reports say. >> >> https://bugreports.qt.nokia.com/browse/QTBUG-20619 >> >> Somehow the RC 1 candidates are being built... so there must be some >> workaround. Is it possible to post the configure commands, >> environment, and tools used to build the official 4.8 RC's? >> >> Also, I would hope that unilaterally closing a bug that affects a >> primary platform (the Mac is still a primary platform, right?) with a >> 'Won't Fix'  and closing down all discussion on the issue is a trend >> that won't continue. It's a primary platform but an exotic build setup. > > You're over-reacting. That just means he (the assignee) will not fix the bug. > If he had the power to close down all discussion, your email wouldn't exist > and I wouldn't be typing this reply right now. > > Also do note that comments after the bug being closed are still received just > as they were before. You can contribute more information to the report so that > a solution can be found. > >> Zeno Albisser (the one who closed the bug) made some suggestions, but >> since the bug is closed, there is no place for developers to post >> information about what works and what doesn't work. My first thought >> is to turn off debug libs; but I'm guessing other developers have done >> it already so it would be nice if the bug were to remain open so that >> we could all benefit from trial and error until a solution is found. > > Sure there is: the bug report. Comments are not disabled in closed bug > reports. It just means Zeno is no longer looking for a solution. But if you > provide one that works for everyone... Which I believe it is hard to find. I would have close the bug myself. The command line option that the test case passes -arch x86 -arch x86_64 is part of the so called "combination of command lines we can't support". It perhaps worked before but with WebCore growing everyday that was pure luck. Splitting the build of WebCore into two pieces so that ranlib could work and your test case work is just stupid because it will add complexity for us to support/implement this, and we don't want. In the other hand if it's that important for you, you can try to have two builds and make a mixture of the library in one of the framework if that's possible. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >   Software Architect - Intel Open Source Technology Center >      PGP/GPG: 0x6EF45358; fingerprint: >      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358 > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil From rich at kde.org Sun Oct 30 16:18:38 2011 From: rich at kde.org (Richard Moore) Date: Sun, 30 Oct 2011 15:18:38 +0000 Subject: [Development] Qt SSL Discussions at QtDevDays 2011 Message-ID: These notes combine the results of the networking discussion at the QtDevDays2011 contributor meeting and also subsequent discussions that took place in the bar (of course). Issues with the current API =========================== 1) Currently ssl errors, and proxy authentication require a nested event loop and stall the entire QNAM that triggers the request. This issue causes problems with (for example) an authentication dialog in one tab of a browser preventing loading of pages others. 2) There is currently no opportunity to perform additional validation of the certificate chain beyond that performed during the initial handshake, but /before/ any user data is transmitted. This is an issue if you want to perform additional validation steps, examples of these are notifications when a certificate has changed from the one previously used by a site (cached earlier) and implementing certificate pinning (such as that implemented by chrome) which allows you to embed information in the client about which CA (or CAs) to expect for particular sites. Another check that can be performed at this point is OCSP, which is needed for checking for revoked certificates. 3) It is currently easy for a developer to ignore SSL errors, often without even determining which errors are occurring first. Proposed Fixes for these Problems ================================= *) Introduce an additional state to the process of connecting to an SSL server. The idea is that client applications will be able to specify that once the SSL handshake is completed that the QSslSocket should be paused. While the socket is paused, no data will be transmitted to the server. During this AwaitingConfirmation state, any additional checks can be performed. In order to continue the connection, then they must explicitly tell the socket to continue, they should also have the option to abort the connection at this point with a guarantee that none of the user's data will be transmitted to the server. This single change allows use to resolve both the first and second issue. The model for connection would be something like this: setPauseAfterHandshake(true) emit sslErrors() emit handshakeComplete() (aka encrypted()) User calls either abort() or confirmConnection() when they have completed the process. *** How do we handle proxy auth? *** Changes to ssl error handling to stop people blindly ignoring the errors. - always pause on errors - pause on no errors if previously requested (not default) - user model is to accept a cert for a given domain, not to approve or disaprove individual errors - approving some but not all errors is essentially pointless - still allow 'predefinition' of expected errors (eg. a particular cert is expected by the app) - ignoreSslErrors just calls continue (and is deprecated) - In order to report these errors we need a way to add to QSslErrors - Public method to add an error to the errorlist - QSslErrors needs to gain a custom error value - Add ocsp specific errors to qsslerror - Add accessor for QSslOcspReply to QNetworkReply - QNAM accessor to specify strict (require Good), relaxed (accept unknown, no reply or no AIA ocsp), or None (don't check) - Kill isValid() - kill completely or - testConstraint( QFlags constraint ); or - hasValidDate() - isBlacklisted() or - enum ConstraintResult { Passed, Failed, Unknown } - ConstraintResult checkConstraint( QSslError ) - Provide a way to find which was the matching root certificate - Can/do we provide access to the full chain? From pgquiles at elpauer.org Sun Oct 30 17:50:54 2011 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Sun, 30 Oct 2011 17:50:54 +0100 Subject: [Development] Fwd: [Boost-users] [C++ Now! 2012] Call for Submissions In-Reply-To: <01b901cc970f$fd08fcb0$f71af610$@gmail.com> References: <01b901cc970f$fd08fcb0$f71af610$@gmail.com> Message-ID: Hi, ---------- Forwarded message ---------- From: Hartmut Kaiser Date: Sun, Oct 30, 2011 at 3:26 PM Subject: [Boost-users] [C++ Now! 2012] Call for Submissions To: boost-users at lists.boost.org INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org), C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard.  Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways.  Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more.  Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 10th, 2012. Proposals decisions sent (tentative program available): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: *    C++11 and how it changes life for users and library writers *    General tutorial sessions on C++11, the C++11 Standardslibrary,     and one or more Boost libraries *    In-depth sessions on using specific Boost libraries *    Case studies on using Boost *    Experts panels *    Advanced sessions on implementation techniques used within Boost     libraries *    Development workshops to extend or enhance existing Boost libraries *    Workshops on design process *    Infrastructure workshops such as Build tools, Website, Testing *    Concepts and Generic Programming *    Hardware and infrastructure presentations focused on how libraries     can make better use of the technology *    Software development tools and their application to C++ and or     Boost *    Other topics likely to be of great interest to Boost users and     developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations     Presentations focus on a practitioner's ideas and                  experience with anything relevant to C++11, Boost and                  users. Panels            Panels feature three or four people presenting their                  ideas and experiences relating to C++11 and Boost's                  relevant, controversial, emerging, or unresolved issues.                  Panels may be conducted in several ways, such as                  comparative, analytic, or historic. Tutorials         Tutorials are sessions at which instructors teach                  conference participants specific skills relevant to                  C++11 and Boost. Workshops         Workshops provide an active arena for advancements in                  Boost-relevant topics. Workshops provide the opportunity                  for experienced practitioners to develop new ideas about                  a topic of common interest and experience. Author's Corner   These were introduced at BoostCon 2008, and were a great Presentations     success They are short (30 minute) sessions, focusing on                  tips on usage and design. In addition, we're looking to                  uncover the hidden design gems in Boost libraries. Tool Vendors      We actively encourage tool vendors and ISP's to submit Presentations     proposals for a special Tool Vendors Session Track aimed                  at products related to Boost and C++ (compilers,                  libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: *    The working title. *    Type of session: presentation, panel, tutorial, workshop,     authors corner, vendor track, other. *    A paragraph or two describing the topic covered, suitable for     the conference web site. *    Proposed length: 10-20 minute short talks, 45 minutes, 90     minutes, half day, full day. *    Alternate lengths, if you are willing to make adjustments: 10-     20 minute short-talks, 45 minutes, 90 minutes, half-day, full     day. *    Audience: users, developers, both. *    Level: basic, intermediate, advanced. *    A biography, suitable for the conference web site. *    Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates). The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012 at easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual      license to publish submitted materials, either electronically or      in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser at gmail.com (Program Committee Chair) Dave Abrahams, email: dave at boostpro.com (Conference Chair) On behalf of the conference organizers _______________________________________________ Boost-users mailing list Boost-users at lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- A non-text attachment was scrubbed... Name: Call for Submissions.pdf Type: application/pdf Size: 401666 bytes Desc: not available URL: From thiago at kde.org Sun Oct 30 18:18:05 2011 From: thiago at kde.org (Thiago Macieira) Date: Sun, 30 Oct 2011 18:18:05 +0100 Subject: [Development] Fwd: [Boost-users] [C++ Now! 2012] Call for Submissions In-Reply-To: References: <01b901cc970f$fd08fcb0$f71af610$@gmail.com> Message-ID: <2868600.Gr8CffEgix@doriath> Hi Pau Thanks for forwarding this. Sounds interesting to be present and discuss with the Boost developers ways to improve collaboration. Maybe someone will finally convince them to maintain binary compatibility so their libraries could become *actually* useful as part of a larger API... The discussions about C++11 and how to make the best use of the new features are also interesting. However, despite the change of name, the conference is still a Boost conference, at least according to the email you sent. There was absolutely no opening in the text for any C++ library, other than Boost and how those other libraries could interoperate with it. If someone knows these people and can ask them if they are interested in opening up some more, I guess the Qt community would be more interested in the conference. On Sunday, 30 de October de 2011 17:50:54 Pau Garcia i Quiles wrote: > Hi, > > ---------- Forwarded message ---------- > From: Hartmut Kaiser > Date: Sun, Oct 30, 2011 at 3:26 PM > Subject: [Boost-users] [C++ Now! 2012] Call for Submissions > To: boost-users at lists.boost.org > > > INAUGURAL C++ NOW! CONFERENCE 2012 > Aspen CO, USA, May 14-18, 2012, www.cppnow.org > > CALL FOR SUBMISSIONS > > We invite you to submit session proposals to the Inaugural C++ Now! > Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). > > Based on the successful traditions of 5 years of BoostCon, which was > the main face-to-face event for all things C++ and Boost > (www.boost.org), C++Now! 2012 will present leading speakers from > the whole C++ community. The conference name is changing to C++ > Now! to reflect the current value of the language, the focus on its new > state (from the new Standard), and the need to continually look to the > future so the language remains useful to the C++ community. > > The focus of this conference will be the new C++11 language Standard > and as usual Boost: what's new in C++, its Standard library, and in the > Boost libraries, how to write and maintain them, how to evangelize or > to deploy Boost within your organization. The new C++ Standard, but > also the infrastructure and process of Boost, its vision and mission - > no matter what you are interested in, it all comes together in the > C++Now! sessions. Meet the colleagues, and feel the inspiration to > support your work with C++ and Boost for the next year. > > The C++ Now! Conference is dedicated to discussion and education > about C++, an open and free language and standard. Our Conference > will focus on discussion and education about open source software > usage and developments in the C++ developer and user community. > > To reflect the breadth of the C++ and Boost communities, the > conference includes sessions aimed at three constituencies: C++ and > Boost end-users, hard-core Boost library and tool developers, and > researchers pushing the boundaries of computation. The program > fosters interaction and engagement within and across those groups, > with an emphasis on hands-on, participatory sessions. > > As a multi-paradigm language, C++ is a melting pot where the most > compelling ideas from other programming communities are blended > in powerful ways. Historically, some of the most popular sessions at > C++Now! have highlighted these concepts, from DSLs to functional > programming to transactional memory and more. Bring your C#, > Python, Ruby or Haskell influences to bear in an environment that will > broaden their exposure. > > IMPORTANT DATES > New proposal submissions due: January 10th, 2012. > Proposals decisions sent (tentative program available): February 17th, 2012. > Fully scheduled program available: February 25th, 2012. > Session materials due: April 15th, 2012. > > BEST PRESENTATION AWARDS > > We know how much effort it takes to prepare talks for our conference. > For this reason we will award the best presentations in the following > categories: Best Presentation, Best Short Presentation, Best Tutorial, > and Best Workshop. The awards will be given based on the audience's > voting. Each award will include the author's name listed on the cover > of the C++Now! website for that year and a plaque containing all the > C++Now! conference information. > > SESSION TOPICS > > Topics of interest include, but are not restricted to, the following: > * C++11 and how it changes life for users and library writers > * General tutorial sessions on C++11, the C++11 Standardslibrary, > and one or more Boost libraries > * In-depth sessions on using specific Boost libraries > * Case studies on using Boost > * Experts panels > * Advanced sessions on implementation techniques used within Boost > libraries > * Development workshops to extend or enhance existing Boost libraries > * Workshops on design process > * Infrastructure workshops such as Build tools, Website, Testing > * Concepts and Generic Programming > * Hardware and infrastructure presentations focused on how libraries > can make better use of the technology > * Software development tools and their application to C++ and or > Boost > * Other topics likely to be of great interest to Boost users and > developers > > Interactive and collaborative sessions are encouraged, as this is the > style of learning and participation that has proven most successful at > such events. Sessions can be tutorial based, with an emphasis on > interaction and participant involvement, or workshop based, whether > hands-on programming or paper-based, discussion-driven > collaborative work. > > SESSION FORMATS > > Presentations Presentations focus on a practitioner's ideas and > experience with anything relevant to C++11, Boost and > users. > Panels Panels feature three or four people presenting their > ideas and experiences relating to C++11 and Boost's > relevant, controversial, emerging, or unresolved issues. > Panels may be conducted in several ways, such as > comparative, analytic, or historic. > Tutorials Tutorials are sessions at which instructors teach > conference participants specific skills relevant to > C++11 and Boost. > Workshops Workshops provide an active arena for advancements in > Boost-relevant topics. Workshops provide the opportunity > for experienced practitioners to develop new ideas about > a topic of common interest and experience. > Author's Corner These were introduced at BoostCon 2008, and were a great > Presentations success They are short (30 minute) sessions, focusing on > tips on usage and design. In addition, we're looking to > uncover the hidden design gems in Boost libraries. > Tool Vendors We actively encourage tool vendors and ISP's to submit > Presentations proposals for a special Tool Vendors Session Track aimed > at products related to Boost and C++ (compilers, > libraries, tools, etc.). > > Other formats may also be of interest. Don't hold back a proposal just > because it doesn't fit into a pigeonhole. > > SUBMITTING A PROPOSAL > > Standard Sessions are 60 minutes. You may submit a proposal for > fractions or multiples of 90-minutes. Fractional proposals will be > grouped into 60 minute sessions covering related topics. Longer > sessions, such as tutorials and classes, will be assigned 90 minute, > three hour (i.e. half day), or six hour (i.e. full day) time slots. > > Please include: > * The working title. > * Type of session: presentation, panel, tutorial, workshop, > authors corner, vendor track, other. > * A paragraph or two describing the topic covered, suitable for > the conference web site. > * Proposed length: 10-20 minute short talks, 45 minutes, 90 > minutes, half day, full day. > * Alternate lengths, if you are willing to make adjustments: 10- > 20 minute short-talks, 45 minutes, 90 minutes, half-day, full > day. > * Audience: users, developers, both. > * Level: basic, intermediate, advanced. > * A biography, suitable for the conference web site. > * Your contact information (will not be made public). > > SUBMISSION DETAILS > > All submissions should be made through the EasyChair conference > management system: http://www.easychair.org/conferences/?conf=cppnow2012. > If you have not already registered at EasyChair, you will need to do so in > order to submit your proposal. > > All submissions will go through a peer review process. > > Authors are invited (but are not required) to submit PDF versions of > full papers of up to 10 pages in ACM conference proceedings format > (see http://www.acm.org/sigs/publications/proceedings-templates). > The full papers are not required unless you want them published in > the proceedings. > > All accepted proposals will be made available in the Association for > Computing Machinery (ACM) Digital Library (approval pending). Best > papers, after further reviews, will be considered to be book chapters > or journal articles in a renowned journal. > > The session materials go on the C++Now! website and will be available > to attendees. > > For general information on the C++Now! 2012 paper submission or > the scope of technical papers solicited, please refer to the conference > website at www.cppnow.org. For any other questions about the > submission process or paper format, please contact the Program > Committee at cppnow2012 at easychair.com. If you have any technical > problems with EasyChair, please contact EasyChair for help. > > Note: Presenters must agree to grant a non-exclusive perpetual > license to publish submitted materials, either electronically or > in print, in any media related to C++ Now!. > > Hartmut Kaiser, email: hartmut.kaiser at gmail.com (Program Committee Chair) > Dave Abrahams, email: dave at boostpro.com (Conference Chair) > > On behalf of the conference organizers > > _______________________________________________ > Boost-users mailing list > Boost-users at lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From jlayt at kde.org Sun Oct 30 20:39:54 2011 From: jlayt at kde.org (John Layt) Date: Sun, 30 Oct 2011 19:39:54 +0000 Subject: [Development] QPrinter Maintainer Message-ID: <1428956.pgOZSBVCnT@argo.layt.net> Hi, I've been appointed as the new maintainer for QPrinter so I thought it would be a good idea to introduce myself and explain what the plans are for printing. I'm a KDE hacker, where I'm maintainer for parts of our Locale, Date/Time and PIM library code, but also maintainer of the KDE additions to QPrintDialog pretty much as no-one else wanted to touch printing :-) My day job is working on mainframes in the financial services sector which is about as far from the Qt/C++ world as you can get. I make no pretence to being a great C++ hacker, or even a moderately good one, but I do care about printing support and have taken the maintainers role to ensure we can get some focus on solving the problems we have. As such I see my role more as a co-ordinator and I'll be looking to the community for help in solving specific problems. If you're interested in helping fix printing and have patches or ideas I'll be glad to hear from you. For Qt 5.0, Lars and Gunnar have separated all the printing code into a new QtBase module called QPrinterSupport. This module is marked as being Done and is intended to be replaced in Qt 5.1 or 5.2 with a new module and api that supports more modern printing features such as both 'push' and 'pull' workflows, colour management, and settings management. The initial target will be supporting the full CUPS feature set on OSX and Linux, then trying to extend that support to Windows where possible. I also have links into the OpenPrinting community and will be looking how to integrate their work as well. See http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Printing for some more details. I intend to start design work on this after I'm done with my QLocale related changes for 5.0. The first step however is to do a bug triage and see what bugs we can fix for Qt 4.8/5.0. I've had a quick skim through the 117 Open/Reported issues, and it's roughly a 50/50 split between bugs and feature requests, with a few duplicates and optimisations thrown in. A few of the bugs have patches attached and could be quick-wins for the 4.8.0 release. A few of those bugs are issues I can work on myself, mostly the Linux/CUPS related ones, but many of these bugs involve font, painting, Windows and OSX issues that lie well outside my expertise. Any help people can give on these will be great. In short: patches welcome! Just a couple of admin points on the bug-tracker, I believe the granting of management rights to non-Nokians is a work in progress? Also a lot of the bugs are assigned to Trond Kjernåsen who I believe is no longer involved in Qt? Cheers! John. From qtnext at gmail.com Sun Oct 30 22:48:17 2011 From: qtnext at gmail.com (qtnext) Date: Sun, 30 Oct 2011 22:48:17 +0100 Subject: [Development] Qt for Android : alpha 3 released ! Message-ID: <4EADC621.40702@gmail.com> just to inform that Qt for Android alpha 3 is released. Here is the annoucement from BogDan : " Hello everybody, I know we are a little late to the party, but we'd like to say: Happy birthday KDE !!! Of course we couldn't come with empty hand, so we come with a gift: the Necessitas alpha3 release ! Necessitas alpha3 release should be the last but one release, before we'll ship first beta version. Why the beta release is so important and why is delayed that much? The beta release will*GUARANTEE* the API/ABI compatibility, meaning that an application which uses that version will run without*any* change, on any further releases! It also means you can target a billion devices using Qt, much sooner than you expected Of course if the situation will require we reserve the right to release additionally alpha releases, because going to beta is a great responsibility we can't afford to screw it up.*IF* everything goes right, we want to release the first beta SDK until the end of this year ! Also don't forget that this release is focused mostly on features completeness, the next releases will be focused mostly on stability, so if your issue(s) is/are not yet fixed, please have a little more patience (and understanding ). Most of all, we need your help to make it happen, so please: - help us to write documentations, FAQ, and to update and maintain project web pages. - help us to answer peoples questions on android-qt mailing list, doing this you are helping us more than you can imagine. - report any issues you find usinghttp://code.google.com/p/android-lighthouse/issues/list, orhttps://sourceforge.net/p/necessitas/tickets/ - help us to check and fix the opened issues. - help us to implement the remaining featureshttp://community.kde.org/Necessitas/TODO ,http://community.kde.org/Necessitas/Schedules/alpha4 Alpha 3 release brings you lots of exciting features, I'd like to talk a little bit about two of them: * OpenGL this is probably the most expected and exciting feature of this release. Yes, is here ! We tried (and succeed) to give you a seamless OpenGL support, even if we have different platform plugins to handle raster and OpenGL drawings, you don't need to worry about it, if your application will require OpenGL, we'll choose automatically the right plugin for your application. * Java redesign and Ministro II, this is a huge step forward for this project, this work will give us freedom to change the platform plugin as we wish without breaking any existing application. How it works ? Your applications doesn't know anything about qt libs, platform plugins and stuff like that, it only knows that it needs to connect to Ministro service, pass some parameters to it and to wait for its response, when the response comes it will have a list with .jar files which your applications needs to load them at runtime and to instantiate the startup class, this class will load Qt libs and your application. Basically the old java part was moved to these .jar files which will be provided by Ministro, Ministro will take care that the .jar files and qt platform libs will always be compatible. BE AWARE !!! Because your application needs other java sources, please make sure you are removing the old ones (please remove android folder from any existing project)!!! I'd like to highlight the most important features: Qt framework: * OpenGL Support * Java part redesign * QAtomic implementation * Seamless Android assets support * Sync with upstream Qt 4.8.0-rc1 QtCreator: * Prepare the package for android market publishing * Sync with QtCreator 2.3.1 QtWebkit: * Sync with QtWebkit 2.2.0 * It seems that the massive memory leak form 2.1.x was fixed. QtMobility: * Sync with Qt framework changes. Necessitas SDK: * Linaro toolchain based on gcc 4.6.x (it is experimental) * Android-4+ (armv5& raster only) SDK * Android-5+ (armv5&armv7, raster&OpenGl) SDKs Minitro: * Can provide specific CPU extensions libraries, this feature allows us to provide not only platform specific libs (armv5, armv6, armv7, x86, etc.) but also libs for specific CPU extensions, e.g. if your CPU supports VFP but the platform not (is the case of armv5) Ministro can download libs for armv5*WITH* VFP flags turn on, also if automatic vectorization [1] will improve the speed will ship Qt libs compiled *completely* with NEON, where devices CPU supports NEON instructions, currently Qt detects at runtime if your CPU supports NEON and it uses that extension only in a few drawing functions. * Sync with Qt framework changes For a complete change log please run the following command on every repository: $ git log n0.21..n0.3 The following people have contributed to this project: == Code == * Thomas Senyk: OpenGL support, fixes * Ray Donnelly: Linaro toolchain integration, NDK, gdb, Windows, and Mac fixes and SDKs. * Nuno Pinheiro: beautiful artwork for necessitas project (except the SDK watermark). * Robert Schuster, Christian Küster java redesign proof of concept, Ministro code cleanup and fixes. * Espen Riskedal: fixes (initial fonts fixes) * Marius Bugge Monsen: cleanup the repo. * Åke Svedin: initial DPI fix patch. * all Nokia developers which worked to all qt projects ! * BogDan Vatra: Java redesign, QAtomic implementation, Android assets, QDesktopServices, QtCreator Android market publishing, QtCreator android plugin rework, Ministro, SDK for Linux, fixes. == Localizations == * Lauri Laanmets: Estonian * Joost Bloemen, Maarten Ditzel: Duch * Alexander Wolf: Russian * Nikos Gerontidis: Greek * Samuel Gaist: French * Andrius da Costa Ribas, Anselmo L.S. Melo: Brazilian * Leonard Lee: Malay, Chinese (Simplified and Traditional) * Thomas Senyk, Josua Dietze * Ivan: Indonesian * Dejan Gojkovic: Serbian * Maciej Kujalowicz: Polish * Tomas: Norwegian * Taro: Japanese * Seyyed Razi Alavizadeh: Persian * Roberto Luttino: Italian * BogDan Vatra: Romanian The SDKs installers can be downloaded from:https://sourceforge.net/projects/necessitas/files/ The new Ministro packages from:https://sourceforge.net/projects/ministro.necessitas.p/files/ Known issues: Linux: - None till this date. Mac: - Sadly we found a show stopper just before release and we delayed the release a few days until we'll figure out what is wrong. We'll come with a separate announcement when this platform will be ready. Windows: - You must select manually the application (projects->run->package configurations->Run: