Re: [Qt-creator] Qt creator + Clang model = major annoyance

[NIkolai Marchenko]

This is not the answer. Modules will only speed up the new code,
whereas Qt Creator is supposed to work reasonably fast with any c++ code.

On Sat, Jan 12, 2019 at 8:09 PM  wrote:

> Le Tue, 8 Jan 2019 07:24:25 +, Eike Ziller 
> écrivait:
>
> >In the future some time maybe.
>
> Hopefully, the introduction of Modules in C++ will considerably
> accelerate compilation speed, helping solving the Clang issue.
>
> Faster compile time thanks to modules happened in the past, like when
> porting a program from Pascal to Modula2, using compilers from the
> same vendor.
>
> Which in turn suggest a future path for Qt6 : Preparing for Modules.
>
> Quentin.
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Qt creator + Clang model = major annoyance

[NIkolai Marchenko]

Continuing my gripes with Qt Creator recently: it now tries to autocomplete
a lot more than welcome.

For whatever reason it tries to insert variable names in the function body
after you type a ( in the code and most often gets the variable wrong
forcing me to backtrack and erase.
And now I realized it even "autocompletes" the whole function signature
instead of just the name I needed it to.

Can we have controls of what it will autocomplete and what not? It was
already annoying when it incorrectly completed " to "" a lot of times, but
nowadays it just looks like an enthusiastic (but moronic) puppy bringing
you random trash and expecting you to pet it.


On Tue, Jan 8, 2019 at 9:00 PM Jason H  wrote:

> Another way to split this is what do we need while typing vs building.
>
> I could see only real-time feedback forfast things, and at/after
> build-time layer in the more expensive stuff.
>
> *Sent:* Tuesday, January 08, 2019 at 12:53 PM
> *From:* Andy 
> *To:* "Marco Bubke" 
> *Cc:* "Jason H" , "Eike Ziller" ,
> "NIkolai Marchenko" , "qt-creator@qt-project.org"
> 
> *Subject:* Re: [Qt-creator] Qt creator + Clang model = major annoyance
> "...some are actually quite cheap but other are very expensive to compute."
>
> Is there any way to indicate/figure out which options are expensive?
>
> I find many of the ones I have turned on useful from an information
> standpoint, but some files take 25 seconds to parse which makes this
> feature less useful from a usability standpoint.
>
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney <https://twitter.com/asmaloney>
>
> On Tue, Jan 8, 2019 at 12:47 PM Marco Bubke  wrote:
>
>> We collect the diagnostics as we compiling the translation unit for
>> completion, highlighting etc.. But the compiling is slower because it takes
>> time to find all the warnings, some are actually quite cheap but other are
>> very expensive to compute. An other idea was only to generate diagnostics
>> for the current files and not the include but AFAIK it is not so easy
>> because our first approach to include everything as system include is not
>> working because the files are locked again.
>> --
>> *From:* Qt-creator  on behalf of
>> Jason H 
>> *Sent:* Tuesday, January 8, 2019 4:48:28 PM
>> *To:* Eike Ziller
>> *Cc:* NIkolai Marchenko; qt-creator@qt-project.org
>> *Subject:* Re: [Qt-creator] Qt creator + Clang model = major annoyance
>>
>> > > I too have noticed QtC's recent versions slowing down. I used to
>> think it was a cool add, but it's starting to get in the way. OR it could
>> be that my expectations have increased and I rely on it more whereas it as
>> a nice-to-have. But the slowdowns remove the value added.
>> >
>> > Please definitely make sure that you use a configuration that does not
>> include any clang-tidy checks (Options > C++ > Code Model). Any of these
>> check should be considered “optional, only enable if they do not degrade
>> performance for you”.
>>
>> So I'm using "Warnings for almost everything (Copy)" (CLANG: -Weverything
>> -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-unused-macros
>> -Wno-newline-eof -Wno-exit-time-destructors -Wno-global-constructors
>> -Wno-gnu-zero-variadic-macro-arguments -Wno-documentation -Wno-shadow
>> -Wno-switch-enum -Wno-missing-prototypes -Wno-used-but-marked-unused
>> -Wno-unknown-pragmas; Clang-Tidy: Disable; Clazy: 0 (no false positives) )
>> But I don't remember setting this up. I have disabled Clazy and will see
>> how that goes.
>>
>> I have no clue how any of this works, but I'd like to suggest something
>> (which may be completely wrong) It seems that an async approach would be
>> the way to go. I don't really need clang-tidy or clazy blocking me. Rather,
>> eventually the errors should be first, warnings, then hints. Maybe you get
>> them all at the same time, but I was under the impression that with these
>> being separate tools, their outputs could be integrated separately? So run
>> the compiler first, then clang-tidy, then clazy.  Then having a "compile
>> server" (language server?) where the server is always running to avoid the
>> startup penalty, and QtC submits your diffs so that only new code is
>> evaluated, would be the way to go? Maybe this is how it is already done, I
>> don't know...
>>
>>
>>
>>
>>
>> ___
>> Qt-creator mailing list
>> Qt-creator@qt-project.org
>> https://lists.qt-project.org/listinfo/qt-creator
>> ___
>> Qt-creator mailing list
>> Qt-creator@qt-project.org
>> https://lists.qt-project.org/listinfo/qt-creator
>
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Qt creator + Clang model = major annoyance

[NIkolai Marchenko]

Also, sometimes the only way to fix CCM to highlight/react to inputs like
F2 is to restart qt creator.

On Sat, Jan 5, 2019 at 6:19 AM NIkolai Marchenko 
wrote:

> Unfortunately it's not possible because my code is c++14/17 heavy and old
> parser just doesn't work with it.
> If it was an option, I would have done it long ago.
>
> On Sat, Jan 5, 2019 at 6:04 AM Sze Howe Koh  wrote:
>
>> On Sat, 5 Jan 2019 at 09:26, NIkolai Marchenko 
>> wrote:
>> >
>> > Qt creator is rapidly becoming a source of major annoyance ever since
>> clang code model was introduced.
>> >
>> > It's slow, sometimes taking 30+ seconds to react to F2
>> > What's worse, it reacts to it once you gave up and navigated somewhere
>> manually and makes you suddenly type stuff in plces you won't expect.
>> >
>> > It's buggy, fails on boost and fails to produce a highlight on
>> everything that depends on it
>> >
>> > It's too easy to break, A single symbol it doesn't detect breaks
>> highlighting and hint for the whole file chain, whether stuff later down
>> the line requires that symbol or not.
>> >
>> > While I understand the desire to stop reimplementing the wheel with
>> code parser, the Clang Code Model made Qt Creator strictly worse for any
>> complex project to the point I catch myself wanting to use something else
>> on a regular basis. This wasn't the case ever before CCM was introduced.
>>
>> Revert to the old code model by disabling the Clang code model in the
>> Plugins dialog (on Windows, it's "Help > About Plugins... > C++ >
>> ClangCodeModel")
>>
>>
>> Regards,
>> Sze-Howe
>>
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

Re: [Qt-creator] Qt creator + Clang model = major annoyance

[NIkolai Marchenko]

Unfortunately it's not possible because my code is c++14/17 heavy and old
parser just doesn't work with it.
If it was an option, I would have done it long ago.

On Sat, Jan 5, 2019 at 6:04 AM Sze Howe Koh  wrote:

> On Sat, 5 Jan 2019 at 09:26, NIkolai Marchenko 
> wrote:
> >
> > Qt creator is rapidly becoming a source of major annoyance ever since
> clang code model was introduced.
> >
> > It's slow, sometimes taking 30+ seconds to react to F2
> > What's worse, it reacts to it once you gave up and navigated somewhere
> manually and makes you suddenly type stuff in plces you won't expect.
> >
> > It's buggy, fails on boost and fails to produce a highlight on
> everything that depends on it
> >
> > It's too easy to break, A single symbol it doesn't detect breaks
> highlighting and hint for the whole file chain, whether stuff later down
> the line requires that symbol or not.
> >
> > While I understand the desire to stop reimplementing the wheel with code
> parser, the Clang Code Model made Qt Creator strictly worse for any complex
> project to the point I catch myself wanting to use something else on a
> regular basis. This wasn't the case ever before CCM was introduced.
>
> Revert to the old code model by disabling the Clang code model in the
> Plugins dialog (on Windows, it's "Help > About Plugins... > C++ >
> ClangCodeModel")
>
>
> Regards,
> Sze-Howe
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

[Qt-creator] Qt creator + Clang model = major annoyance

[NIkolai Marchenko]

Qt creator is rapidly becoming a source of major annoyance ever since clang
code model was introduced.

It's slow, sometimes taking 30+ seconds to react to F2
What's worse, it reacts to it once you gave up and navigated somewhere
manually and makes you suddenly type stuff in plces you won't expect.

It's buggy, fails on boost and fails to produce a highlight on everything
that depends on it

It's too easy to break, A single symbol it doesn't detect breaks
highlighting and hint for the whole file chain, whether stuff later down
the line requires that symbol or not.

While I understand the desire to stop reimplementing the wheel with code
parser, the Clang Code Model made Qt Creator strictly worse for any complex
project to the point I catch myself wanting to use something else on a
regular basis. This wasn't the case ever before CCM was introduced.
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

[Qt-creator] Nameless return values for debug mode

[NIkolai Marchenko]

Is it possible to modify debug process to let the execution linger in the
debugged function for 1 more step to show the result created by the return
statemenet in the debug view?

This way there will be no need to create temp variables/debug statements to
debug what the actual return statement of the function produces.
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Nameless return values for debug mode

[NIkolai Marchenko]

Here is an example screenshot:
http://s3.postimg.org/rxzh6trub/16_11_2015_14_02_06.png

The result of the return can neither be seen in the locals section, nor
added as an expression.

On Mon, Nov 16, 2015 at 1:55 PM, NIkolai Marchenko <enmarantis...@gmail.com>
wrote:

> locals and expressions only show just that: locals and expressions
> When there is a chain of returns none of which assign to a temporary
> variable it become hard to debug what went wrong and where without modifyng
> code with qdebugs
>
> On Mon, Nov 16, 2015 at 1:47 PM, Orgad Shaneh <org...@gmail.com> wrote:
>
>> On Mon, Nov 16, 2015 at 12:44 PM, NIkolai Marchenko <
>> enmarantis...@gmail.com> wrote:
>>
>>> Is it possible to modify debug process to let the execution linger in
>>> the debugged function for 1 more step to show the result created by the
>>> return statemenet in the debug view?
>>>
>>> This way there will be no need to create temp variables/debug statements
>>> to debug what the actual return statement of the function produces.
>>>
>>
>> When you exit a function with Shift-F11 the return value is displayed in
>> the Locals view.
>>
>> Is this what you're looking for?
>>
>> - Orgad
>>
>
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Nameless return values for debug mode

[NIkolai Marchenko]

locals and expressions only show just that: locals and expressions
When there is a chain of returns none of which assign to a temporary
variable it become hard to debug what went wrong and where without modifyng
code with qdebugs

On Mon, Nov 16, 2015 at 1:47 PM, Orgad Shaneh <org...@gmail.com> wrote:

> On Mon, Nov 16, 2015 at 12:44 PM, NIkolai Marchenko <
> enmarantis...@gmail.com> wrote:
>
>> Is it possible to modify debug process to let the execution linger in the
>> debugged function for 1 more step to show the result created by the return
>> statemenet in the debug view?
>>
>> This way there will be no need to create temp variables/debug statements
>> to debug what the actual return statement of the function produces.
>>
>
> When you exit a function with Shift-F11 the return value is displayed in
> the Locals view.
>
> Is this what you're looking for?
>
> - Orgad
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Please change the postion of the build status indicator

[NIkolai Marchenko]

It would solve the issue if you provided the means to offset build progress
indicator horizontally from the right.
I'd just then offset it so that it is aligned with the left part of the
lower panel instead of the right part.

On Fri, Nov 13, 2015 at 5:39 PM, Tobias Hunger 
wrote:

> Hi Samuel,
>
> On Fri, Nov 13, 2015 at 2:35 PM, Samuel Stirtzel
>  wrote:
> > would it be possible to display the progress bar in the projects view
> > as background of the projects?
> >
> > Crudely painted example:
> >
> https://drive.google.com/file/d/0Bx-m3uk1yDB-cmVlbVV5VlpyQTA/view?usp=sharing
>
> Nice idea, but how do all the people that hide the sidebar see that
> something is in progress then?
>
> Where should progress bars go that are not directly related to any one
> project?
>
> Best Regards,
> Tobias
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Please change the postion of the build status indicator

[NIkolai Marchenko]

Well, you could, theoretically, show it in a popup window so that that it
is above all the other stuff that pops up before it.

Also, which panel do you suggest I move? I am not sure what you mean.
I'd actually perfer it was possible to move the build status panel

What was the problem with the old position anyway? It was perfectly fine
and visible on the left bar of the app.

On Fri, Nov 13, 2015 at 3:38 PM, Tobias Hunger <tobias.hun...@gmail.com>
wrote:

> On Fri, Nov 13, 2015 at 11:51 AM, NIkolai Marchenko
> <enmarantis...@gmail.com> wrote:
> > A while ago build status indicator was moved from the left side to the
> lower
> > right corner.
> > Where it is now, it is, more often than not, hidden behind notifications
> > from messaging applications and it is imposible to see build status and
> if
> > there are errors without either reading aforementioned indications or
> > skipping them, which is severely inconvenient.
> >
> > At least for me, this corner is constantly overlayed by skype + slack +
> > telegram which makes for some frustrating builds.
>
> Obvious work-arounds of course include moving the panel (most UIs
> support that) or making the Qt Creator window smaller.
>
> Where would you suggest to move the progress bar to? We need a spot
> wider than the few pixels in the mode bar, easily visible at all
> times, and we of course do not want to reduce the space dedicated to
> displaying the source code.
>
> Best Regards,
> Tobias
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator