[Qt-creator] Warning during subproject add (my format of projects)
Hi dear QtC devs and contributors! I getting every time warnings of bool JsonWizardFileGenerator::allDone(const JsonWizard *wizard, Core::GeneratedFile *file, QString *errorMessage) function ( https://qt.gitorious.org/qt-creator/qt-creator/source/50fe3585a890fdbb5b6b8598bd8ffe97c036b52d:src/plugins/projectexplorer/jsonwizard/jsonwizardfilegenerator.cpp#L208 ) : it warns me about failed try to open subproject. But I am already successfully add subproject to my project tree. BTW, I trying to add new subproject by clicking RMB->"New subproject..." Here is my function in what my plugin perform add subprojects: http://pastebin.com/pcAzAXG6 . Please tell me where I need to dig to solve my problem? ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Build Screen colors in 3.4RC1
On Thu, Apr 9, 2015 at 9:06 AM, Oleg Shalnev wrote: > I cleaned my theme. Restored default dark theme and got the same result. > I think this is about interferencion with KDE dark theme. > > 2015-04-09 8:13 GMT+03:00 Orgad Shaneh : > >> On Wed, Apr 8, 2015 at 1:35 PM, Oleg Shalnev >> wrote: >> >>> Oh, No. >>> >>> I use custom them, of course. >>> But my theme is absolute stable and migrate from version to version. >>> This theme is working good in 3.3. >>> >>> 2015-04-08 13:24 GMT+03:00 Orgad Shaneh : >>> Do you have a custom color theme or are you using the built-in one? It should be ok with the built-in. >>> >> Some role names were changed, and some roles were added. Reclone the >> built-in theme and modify it. >> >> - Orgad >> > > Please reply to the list, so others can participate :) I couldn't reproduce your problem with KDE's dark theme. Does it reproduce when you choose Dark (built-in) in the theme settings? - Orgad ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Preparing to contribute Boost.Build Plugin to Qt Creator
On Wed, Apr 15, 2015 at 10:15:40AM +0300, Orgad Shaneh wrote: > On Wed, Apr 15, 2015 at 9:58 AM, Mateusz Loskot wrote: > > The issue here is, that I know the current code will be rejected > > straight away due to Qt(Creator)-incompatible coding conventions > > used. So, we need to port to Qt coding style and we will be working > > on it as a team. > > > It won't be rejected. Wip branches are exactly for that - submitting > changes that are unacceptable under regular terms, while the final > review will be done in a single squashed commit when the work on this > branch is done. > it depends on how the involed parties want to work. it certainly would be possible to polish the "initial import" into a state that is acceptable in itself and build other self-contained changes on top. that tends to be unrealistic for big contributions by inexperienced developers, so a squash is typically unavoidable, but it comes with downsides as well (especially if it is team work, as work becomes not individually attributable any more). also, never forget that a gerrit review is a branch in itself. i have a branch with 40+ changes pending for months in gerrit (reviewers for perl code wanted, btw :D). > You should have access to +2 changes for this branch yourself. > not yet. it's preferable not to do that if the team can get an approver involved. which you definitely should, because early feedback significantly reduces the total cost. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Preparing to contribute Boost.Build Plugin to Qt Creator
On Wed, Apr 15, 2015 at 9:58 AM, Mateusz Loskot wrote: > On 15 April 2015 at 08:46, André Hartmann > wrote: > >> For example, let's assume we start working on the contribution as > follows: > >> 1. Import current sources of our plugin into > wip/boostbuildprojectmanager > > > > To submit this first commit, it would be best all current developers > give a > > +1 review to show their acceptance that the code is merged to the Qt > > repositories. > > André, > > The issue here is, that I know the current code will be rejected straight > away > due to Qt(Creator)-incompatible coding conventions used. > So, we need to port to Qt coding style and we will be working on it as a > team. > It won't be rejected. Wip branches are exactly for that - submitting changes that are unacceptable under regular terms, while the final review will be done in a single squashed commit when the work on this branch is done. You should have access to +2 changes for this branch yourself. - Orgad ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Preparing to contribute Boost.Build Plugin to Qt Creator
On 15 April 2015 at 08:46, André Hartmann wrote: >> For example, let's assume we start working on the contribution as follows: >> 1. Import current sources of our plugin into wip/boostbuildprojectmanager > > To submit this first commit, it would be best all current developers give a > +1 review to show their acceptance that the code is merged to the Qt > repositories. André, The issue here is, that I know the current code will be rejected straight away due to Qt(Creator)-incompatible coding conventions used. So, we need to port to Qt coding style and we will be working on it as a team. > Afterwards, you can pull this branch and start further work. > >> 2. git push gerrit HEAD:refs/wip/boostbuildprojectmanager (?) > > This would be done after you changed a bit, i.e. created a patch. > > Imho the command would be something like: > > git push gerrit HEAD:refs/for/wip/boostbuildprojectmanager Right, I unintentionally omitted the /for/ >> 3. Developers A and B pull the changes > > Yes, they do to test the new things out. > Then they suggest improvements to the patch, and the original developer A or > any other pushes a new change set (with step 2). I should have clarified, I mean developers A and B as developers submitting the plugin, as there is a couple of people working on it, not just me. So, A and B are not the reviewers. > It is important to keep the > Change-Id line in the commit footer, so Gerrit knows the new push belongs to > an existing change. Ok. > Once this change is ready for submission (approved), it is cherry-picked to > the wip/boostbuildprojectmanager branch and can be pulled by anyone. That process was slightly confusing to me, that git push will merge straight away but then it can be rejected in some other magical way in Gerrit. Now, it makes sense. > Further development / coding style corrections go on with new Change sets. Yes, but see my concern on rejection of the initial commit, for example. > Maybe it's best to have a look around at the open changes on Gerrit and how > other developers interact with each other. Good idea. Thank you very much for your insights. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
