Re: [Development] Code of Conduct (was: Speeding up the review process)

On Mon, Oct 16, 2017 at 08:34:09AM +0200, Viktor Engelmann wrote: > On 13.10.2017 15:33, Christian Kandeler wrote: > >> Sure - but let's think about this in a different context: imagine > >> someone applies at your company. You invite them to a job interview > >> and have one of your engineers do

Re: [Development] Review for new widget module [your advices are needed]

Thanks for your participation Christian . And i think it wouldn't be a conflicts because we have QtCharts both in widgets and QML. Could you tell what month was that Thiago's mention about the blog pos? I couldn't find it. Iman. On Mon,

Re: [Development] Review for new widget module [your advices are needed]

So the idea itself seems good to you AND that's enough for me as well. And about the next part, you will. Consider a situation that you're going to develop a client or something in embedded or desktop and you don't need to deal with QML or something else for your modern interfaces, and just wanna

Re: [Development] Future of QBS

> On Oct 16, 2017, at 4:42 AM, Kevin Kofler wrote: > > Christian Gagneraud wrote: >> I would resume this post as "I love CMake, CMake is the only way. >> You're all wrong." >> This post doesn't explain anything, doesn't gives any analysis, no >> comparison, no argument

Re: [Development] Review for new widget module [your advices are needed]

>From an end user point of view, i think it's a great idea but I think it conflicts with Qml. At work we have our own set of highly customised widgets, for embedded devices, it simply works, no need (yet) for Qml. I would be interested to see your work and give my opinion if it can help. Full

Re: [Development] Code of Conduct (was: Speeding up the review process)

oops - what I wanted to say about code of conduct: this is precisely why I opposed a code of conduct in the QtCS discussion. A code of conduct would pretty much lead to a situation where it doesn't matter if a message is understood correctly - the one who wrote it is to blame by default. Some

Re: [Development] Review for new widget module [your advices are needed]

Hi Chris, Am 16.10.2017 um 08:11 schrieb Christian Gagneraud: From an end user point of view, i think it's a great idea but I think it conflicts with Qml. At work we have our own set of highly customised widgets, for embedded devices, it simply works, no need (yet) for Qml. I would be

Re: [Development] Future of QBS

On 16/10/2017 7:31 pm, "BogDan Vatra" wrote: On luni, 16 octombrie 2017 17:38:53 EEST Christian Gagneraud wrote: > On 16 October 2017 at 15:42, Kevin Kofler wrote: > > Christian Gagneraud wrote: > >> I would resume this post as "I love CMake, CMake is

Re: [Development] Review for new widget module [your advices are needed]

Few days ago, should be easy to find on mailing list archives Sorry on my phone right now. Go to October arch. Chris ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

On luni, 16 octombrie 2017 17:38:53 EEST Christian Gagneraud wrote: > On 16 October 2017 at 15:42, Kevin Kofler wrote: > > Christian Gagneraud wrote: > >> I would resume this post as "I love CMake, CMake is the only way. > >> You're all wrong." > >> This post doesn't

Re: [Development] Future of QBS

On Mon, 16 Oct 2017 01:23:51 +0800 Ben Lau wrote: > I am still new to QBS, but I think it is better than CMake too. However, I > think it has missed a critical feature - A simple way to run custom script. > > For example, run a script to call external command (not a product

Re: [Development] Future of QBS

Hi Jake, to use your version control picture: Are we trying to sell subversion by showing how great that is compared to CVS and RCS, while git is just getting introduced into the market? I am still missing a comparison of qbs and *current* build system options. All I see is qbs vs. qmake and

Re: [Development] Future of QBS

> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > Subject: Re: [Development] Future of QBS > > Hi Jake, > > to use your version control picture: Are we trying to sell subversion by > showing how great that is compared to CVS and RCS, while git is

Re: [Development] Future of QBS

16.10.2017, 05:43, "Kevin Kofler" : > Christian Gagneraud wrote: >>  I would resume this post as "I love CMake, CMake is the only way. >>  You're all wrong." >>  This post doesn't explain anything, doesn't gives any analysis, no >>  comparison, no argument whatsoever,

Re: [Development] Future of QBS

On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote: > On 14 October 2017 at 04:22, Jean-Michaël Celerier > > wrote: > >> nobody is going to port Qt to CMake (if you disagree start a new thread) > > > >

Re: [Development] Nominating Kevin Funk for Maintainer qtbase/Build Systems/CMake

André Pönitz wrote: > > > Hi all. > > I would like to nominate Kevin Funk for Maintainer of the > Build Systems/CMake area. > > Kevin is effectively doing the job today. +1 from me too. Thanks Kevin! ___ Development mailing list

Re: [Development] Future of QBS

15.10.2017, 12:20, "Christian Gagneraud" : > On 14 October 2017 at 04:22, Jean-Michaël Celerier > wrote: >>>  nobody is going to port Qt to CMake (if you disagree start a new thread) >> >>  https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8 >

Re: [Development] Review for new widget module [your advices are needed]

Hello Iman, I tried to give a try to this thing. I think you forgot to add a couple of files: * style/palettes.h * style/styleoption.h -- Best regards, Jesús On 2017-10-14 09:33:52+02:00 iman ahmadvand wrote: Hi everyone. Before I send some code base on codereview and decide whether my

Re: [Development] Future of QBS

16.10.2017, 13:59, "Konstantin Tokarev" : > 15.10.2017, 12:20, "Christian Gagneraud" : >>  On 14 October 2017 at 04:22, Jean-Michaël Celerier >>   wrote:   nobody is going to port Qt to CMake (if you disagree start a new

Re: [Development] Future of QBS

> We've been investing into qbs since a while, and have been open about our > plans for building Qt itself with it. Even if there is no official decision > by the Qt Project to switch yet (and I think this can only be done once we > have a full port working), I think it's only fair for the

Re: [Development] Future of QBS

16.10.2017, 10:31, "Jake Petroules" : >>  On Oct 16, 2017, at 4:42 AM, Kevin Kofler wrote: >> >>  Christian Gagneraud wrote: >>>  I would resume this post as "I love CMake, CMake is the only way. >>>  You're all wrong." >>>  This post doesn't

Re: [Development] Future of QBS

> On Oct 16, 2017, at 11:14 AM, Tobias Hunger wrote: > > Hi Jake, > > to use your version control picture: Are we trying to sell subversion by > showing how great that is compared to CVS and RCS, while git is just getting > introduced into the market? Your analogy is

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

On 2017-10-13 16:03, Jedrzej Nowacki wrote: If you do like that then you are doing it wrong. Review process is _not_ based on a name / company / sun activity. It is based on the change content. Even best people do mistakes. I'm entirely with Jedrzej here. Do not +2 if you don't understand

Re: [Development] Future of QBS

> I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), has native support for arrays(!), and > functions/methods have > first-class return values(!) > * Its language has native support for properties, with syntax that really > looks

Re: [Development] Future of QBS

You'll need a strongly normalizing language for that which does not allow general recursion. Something built on the simply typed lambda calculus, but with added syntactic sugar would do. On 10/16/2017 09:08 AM, Ulf Hermann wrote: I have no real experience with Meson, but at least it has

Re: [Development] Future of QBS

> On Oct 16, 2017, at 2:46 PM, Konstantin Tokarev wrote: > > I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), has native support for arrays(!), and > functions/methods have > first-class return values(!) > *

Re: [Development] Future of QBS

On 10/16/2017 03:16 PM, Adam Treat wrote: > You'll need a strongly normalizing language for that which does not allow > general recursion. Something built on the simply typed lambda calculus, but > with added syntactic sugar would do. Hmm, is it possible to define a subset of JavaScript with

Re: [Development] Future of QBS

16.10.2017, 15:06, "Kevin Kofler" : > Tobias Hunger wrote: >>  I am still missing a comparison of qbs and *current* build system options. >>  All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake >>  is what qbs will be competing with by the time it is

Re: [Development] Future of QBS

Tobias Hunger wrote: > I am still missing a comparison of qbs and *current* build system options. > All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake > is what qbs will be competing with by the time it is ready to be used in > earnest. > > So far we excluded most possible

Re: [Development] Review for new widget module [your advices are needed]

Thank you Jesus for attempt. Actually those headers are created automatically as a pre-build step by material style generator (via src/util/util.pro project). and a python script (src/util/generate.py) is responsible for creating those needed headers from text ones. So if you just build the root

Re: [Development] Future of QBS

> Meson is, as far as I can tell (I had already looked at it a couple times), > mostly a CMake clone written in Python. I fail to see how it is conceptually > any different from (let alone better than) CMake. It is mainly pushed by > GNOME developers who are fed up of stone-age autotools, but

Re: [Development] Future of QBS

Hello, My two cents as a Qt user and occasional Meson contributor. I have the feeling that a Qt build system will always force the users to choose between another tool they know but where the Qt support might not be the best and a Qt focused tool with a good Qt support but they will have to deal

Re: [Development] Future of QBS

16.10.2017, 19:02, "jeandet" : > Le lundi 16 octobre 2017 à 15:46 +0300, Konstantin Tokarev a écrit : >>  That said, I totally dislike the idea of inventing restricted DSL >>  language for build system >>  instead of using general purpose language (like e.g. in QBS

Re: [Development] Future of QBS

Hi Jake, take a breath, I was not even trying to attack qbs. These debates get way too emotional for my taste! All I did was to ask to see qbs *sold* better and with more facts backing up our claims about it. > > to use your version control picture: Are we trying to sell > > subversion by

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

Hi, I hope people can look into Viktor’s complete proposal and think about what is good and what not. This is what we should do when someone makes a proposal to improve things. I think the idea is very good - being more efficient. What happened in this thread is taking only some parts of it

Re: [Development] Future of QBS

On 16 October 2017 at 21:40, Kevin Funk wrote: > On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote: >> On 14 October 2017 at 04:22, Jean-Michaël Celerier >> >> wrote: >> >> nobody is going to port Qt to CMake (if you disagree

Re: [Development] Future of QBS

Konstantin Tokarev wrote: > I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), CMake also has a concept of types. In particular, the cache variables (i.e., the variables you can set on the command line, which are also cached across

Re: [Development] Future of QBS

PS: Oh, and I forgot: Konstantin Tokarev wrote: > [Meson] is written in scripting language In addition to what I already wrote, this also implies that the scripting language (Python in this case) interpreter is required to build anything with it, whereas a build system in C++ such as CMake

Re: [Development] Future of QBS

16.10.2017, 16:08, "Ulf Hermann" : >>  I have no real experience with Meson, but at least it has following >> advantages: >> >>  * Its language is typed(!), has native support for arrays(!), and >> functions/methods have >>  first-class return values(!) >>  * Its language

Re: [Development] Future of QBS

16.10.2017, 16:17, "Adam Treat" : > You'll need a strongly normalizing language for that which does not > allow general recursion. Something built on the simply typed lambda > calculus, but with added syntactic sugar would do. Maybe Prolog would do it too. >> >>  Ulf >>  

Re: [Development] Future of QBS

Prolog is turing-complete and hence can be used to construct programs which do not terminate. On 10/16/2017 09:42 AM, Konstantin Tokarev wrote: 16.10.2017, 16:17, "Adam Treat" : You'll need a strongly normalizing language for that which does not allow general recursion.