Re: [Qt-creator] : CMake and multiple targets in CMakeLists.txt

2009-10-27 Thread Gena
On Tuesday 27 October 2009 19:38:04 Daniel Teske wrote:
> On Tuesday 27 October 2009 16:58:46 ext Gena Cid wrote:
> > Hello!
> >
> > I've found a tiny bug when tried Qt-creator on subj. Everything is just
> >  fine, but build steps contains two target: my custom target and 'all'
> >  (looks like 'make all '). After uncheck and check
> > again  in the Targets list 'all' disappeared and
> > everything is works as expected.
> >
> > P.S. Use qt-creator-linux-x86_64-opensource-1.2.90
> 
> I think I already fixed that.

Oops! Sorry, need to check latest snapshot first..

|-
Гена.

___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] plugin_qtestlib

2009-10-27 Thread Bravo.Alex
That make sense to me. Thanks guys for your responses.

-Original Message-
From: qt-creator-boun...@trolltech.com 
[mailto:qt-creator-boun...@trolltech.com] On Behalf Of Eike Ziller
Sent: Tuesday, October 27, 2009 9:54 AM
To: qt-creator@trolltech.com
Subject: Re: [Qt-creator] plugin_qtestlib

On Oct 27, 2009, at 5:15 PM, ext Bravo.Alex wrote:

>> When you run your tests, you'd have the whole application debug log  
>> in
> the application output pane, and a collection of the issues in the
> "issues" pane.
>
> In order to easily parse QTestLib output, it's better to have it in  
> XML format.
> But then outputting XML in Application Output is not going to be  
> very useful.
>
> In my opinion it's strange to present some info in one pane and  
> other info in another.
>
> What's wrong with taking the whole XML output and presenting it in  
> one consistent way in one place?

Well, I can't talk much about how QTestLib XML output works, because  
I've no idea. I suppose that tests could produce qDebug output, or  
qWarnings originating from Qt, and whatever dumped information, that  
are not only "Test XYZ failed at location foo" (or succeeded).

What's the principal difference to compilation? There we have the full  
output of the compile process in one pane (Compile Output, allowing to  
inspect the inner workings to track down problems) and the collection  
of parsed issues in another (Build Issues, for easy interaction).

++ Eike

> -Original Message-
> From: qt-creator-boun...@trolltech.com 
> [mailto:qt-creator-boun...@trolltech.com 
> ] On Behalf Of Eike Ziller
> Sent: Tuesday, October 27, 2009 3:48 AM
> To: qt-creator@trolltech.com
> Subject: Re: [Qt-creator] plugin_qtestlib
>
>
> On Oct 26, 2009, at 8:39 PM, ext Coda Highland wrote:
>
>> Honestly I don't know if I want to set the precedent of allowing
>> plugins to just arbitrarily add new tabs there.
>>
>> I think Build Issues would be a valid output target, though; it's
>> already intended for jumping to the relevant places in the code and
>> one could argue that failing a unit test is a build issue.
>
> One option is to put the test issues into what now is the "build
> issues" pane:
>
> When you build a program, you have the whole build log in the compile
> output pane, and a collection of the issues in the "issues" pane.
> When you build your tests, you'd have the whole build log in the
> compile output pane, and a collection of the issues in the "issues"
> pane.
> When you run your tests, you'd have the whole application debug log in
> the application output pane, and a collection of the issues in the
> "issues" pane.
> This could be extended to also put issues when running other Qt
> programs into the "issues" pane, like Qt warnings (connect failed,
> etc, etc).
> It would definitely make no sense to call it "build issues" then, but
> anyhow, it's just a label.
> And it would definitely make no sense to add yet another tab for
> warnings when running Qt programs :)
>
> Another option is to extend the application output pane with clickable
> links for Qt warnings, test result lines, and more.
>
> ++ Eike
>
>>
>> /s/ Adam
>>
>> On Mon, Oct 26, 2009 at 2:18 PM, Robert Caldecott
>>  wrote:
>>>
>>> I like the idea of a dedicated QTest output pane - will you be able
>>> to double-click on failures to jump directly to the code?  That
>>> would be brilliant.
>>>
>>> 2009/10/26 Bravo.Alex 

> Plus that it's not so high in the list of things to do.



 If you are talking about qtcrea...@nokia team, it makes a lot of
 sense.

 But that's why you guys opened development to outside world, right?

 So that we can help you improve already great product.





 So, back to qtestlibplugin:

 After bringing it back from the dead, I realized that the
 architecture of this plugin might need adjustment:

 Right now it has its own type of output "Test Results" (just like
 "Build Issues", "Application Output" and 2 more).

 But, as this picture shows, there's not much space for different
 types of output:



 Besides it doesn't make much sense to "pollute" IDE's screen with
 "Test Results" button and list entry

 for applications that have nothing to do with QTestLib.



 It looks like there should be as little presence for this plugin
 as possible in the IDE's GUI.

 Ideally, this plugin should show itself only if output of a
 program is in QTestLib format.



 Thus this plugin really provides a different format of
 "Application Output", not a different output pane.



 So proposed adjustment to this plugin is to be able to have
 several formats of "Application Output".

 By default it's "raw" output, with the ability to switch to a
 different format.

 In case of qtestlibplugin it can be "test results" and "benchmark
 results"

Re: [Qt-creator] plugin_qtestlib

2009-10-27 Thread Eike Ziller
On Oct 27, 2009, at 5:15 PM, ext Bravo.Alex wrote:

>> When you run your tests, you'd have the whole application debug log  
>> in
> the application output pane, and a collection of the issues in the
> "issues" pane.
>
> In order to easily parse QTestLib output, it's better to have it in  
> XML format.
> But then outputting XML in Application Output is not going to be  
> very useful.
>
> In my opinion it's strange to present some info in one pane and  
> other info in another.
>
> What's wrong with taking the whole XML output and presenting it in  
> one consistent way in one place?

Well, I can't talk much about how QTestLib XML output works, because  
I've no idea. I suppose that tests could produce qDebug output, or  
qWarnings originating from Qt, and whatever dumped information, that  
are not only "Test XYZ failed at location foo" (or succeeded).

What's the principal difference to compilation? There we have the full  
output of the compile process in one pane (Compile Output, allowing to  
inspect the inner workings to track down problems) and the collection  
of parsed issues in another (Build Issues, for easy interaction).

++ Eike

> -Original Message-
> From: qt-creator-boun...@trolltech.com 
> [mailto:qt-creator-boun...@trolltech.com 
> ] On Behalf Of Eike Ziller
> Sent: Tuesday, October 27, 2009 3:48 AM
> To: qt-creator@trolltech.com
> Subject: Re: [Qt-creator] plugin_qtestlib
>
>
> On Oct 26, 2009, at 8:39 PM, ext Coda Highland wrote:
>
>> Honestly I don't know if I want to set the precedent of allowing
>> plugins to just arbitrarily add new tabs there.
>>
>> I think Build Issues would be a valid output target, though; it's
>> already intended for jumping to the relevant places in the code and
>> one could argue that failing a unit test is a build issue.
>
> One option is to put the test issues into what now is the "build
> issues" pane:
>
> When you build a program, you have the whole build log in the compile
> output pane, and a collection of the issues in the "issues" pane.
> When you build your tests, you'd have the whole build log in the
> compile output pane, and a collection of the issues in the "issues"
> pane.
> When you run your tests, you'd have the whole application debug log in
> the application output pane, and a collection of the issues in the
> "issues" pane.
> This could be extended to also put issues when running other Qt
> programs into the "issues" pane, like Qt warnings (connect failed,
> etc, etc).
> It would definitely make no sense to call it "build issues" then, but
> anyhow, it's just a label.
> And it would definitely make no sense to add yet another tab for
> warnings when running Qt programs :)
>
> Another option is to extend the application output pane with clickable
> links for Qt warnings, test result lines, and more.
>
> ++ Eike
>
>>
>> /s/ Adam
>>
>> On Mon, Oct 26, 2009 at 2:18 PM, Robert Caldecott
>>  wrote:
>>>
>>> I like the idea of a dedicated QTest output pane - will you be able
>>> to double-click on failures to jump directly to the code?  That
>>> would be brilliant.
>>>
>>> 2009/10/26 Bravo.Alex 

> Plus that it's not so high in the list of things to do.



 If you are talking about qtcrea...@nokia team, it makes a lot of
 sense.

 But that's why you guys opened development to outside world, right?

 So that we can help you improve already great product.





 So, back to qtestlibplugin:

 After bringing it back from the dead, I realized that the
 architecture of this plugin might need adjustment:

 Right now it has its own type of output "Test Results" (just like
 "Build Issues", "Application Output" and 2 more).

 But, as this picture shows, there's not much space for different
 types of output:



 Besides it doesn't make much sense to "pollute" IDE's screen with
 "Test Results" button and list entry

 for applications that have nothing to do with QTestLib.



 It looks like there should be as little presence for this plugin
 as possible in the IDE's GUI.

 Ideally, this plugin should show itself only if output of a
 program is in QTestLib format.



 Thus this plugin really provides a different format of
 "Application Output", not a different output pane.



 So proposed adjustment to this plugin is to be able to have
 several formats of "Application Output".

 By default it's "raw" output, with the ability to switch to a
 different format.

 In case of qtestlibplugin it can be "test results" and "benchmark
 results" formats.

 Other plugins could have/add their own formats.



 What do you guys think?



 Alex





 -Original Message-
 From: qt-creator-boun...@trolltech.com 
 [mailto:qt-creator-boun...@trolltech.com
 ] On Behalf 

Re: [Qt-creator] : CMake and multiple targets in CMakeLists.txt

2009-10-27 Thread Daniel Teske
On Tuesday 27 October 2009 16:58:46 ext Gena Cid wrote:
> Hello!
> 
> I've found a tiny bug when tried Qt-creator on subj. Everything is just
>  fine, but build steps contains two target: my custom target and 'all'
>  (looks like 'make all '). After uncheck and check again
>   in the Targets list 'all' disappeared and everything is
>  works as expected.
> 
> P.S. Use qt-creator-linux-x86_64-opensource-1.2.90

I think I already fixed that.

daniel
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


[Qt-creator] Copy, paste commands on right click?

2009-10-27 Thread Daniel Grubbs
Ok, this is annoying.

I'm using 1.2.92 on Linux and the popup menu when you right-click text no
longer has the standard copy and paste commands.

Dan Grubbs
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] plugin_qtestlib

2009-10-27 Thread Bravo.Alex
> When you run your tests, you'd have the whole application debug log in  
the application output pane, and a collection of the issues in the  
"issues" pane.

In order to easily parse QTestLib output, it's better to have it in XML format.
But then outputting XML in Application Output is not going to be very useful.

In my opinion it's strange to present some info in one pane and other info in 
another.

What's wrong with taking the whole XML output and presenting it in one 
consistent way in one place?


-Original Message-
From: qt-creator-boun...@trolltech.com 
[mailto:qt-creator-boun...@trolltech.com] On Behalf Of Eike Ziller
Sent: Tuesday, October 27, 2009 3:48 AM
To: qt-creator@trolltech.com
Subject: Re: [Qt-creator] plugin_qtestlib


On Oct 26, 2009, at 8:39 PM, ext Coda Highland wrote:

> Honestly I don't know if I want to set the precedent of allowing
> plugins to just arbitrarily add new tabs there.
>
> I think Build Issues would be a valid output target, though; it's
> already intended for jumping to the relevant places in the code and
> one could argue that failing a unit test is a build issue.

One option is to put the test issues into what now is the "build  
issues" pane:

When you build a program, you have the whole build log in the compile  
output pane, and a collection of the issues in the "issues" pane.
When you build your tests, you'd have the whole build log in the  
compile output pane, and a collection of the issues in the "issues"  
pane.
When you run your tests, you'd have the whole application debug log in  
the application output pane, and a collection of the issues in the  
"issues" pane.
This could be extended to also put issues when running other Qt  
programs into the "issues" pane, like Qt warnings (connect failed,  
etc, etc).
It would definitely make no sense to call it "build issues" then, but  
anyhow, it's just a label.
And it would definitely make no sense to add yet another tab for  
warnings when running Qt programs :)

Another option is to extend the application output pane with clickable  
links for Qt warnings, test result lines, and more.

++ Eike

>
> /s/ Adam
>
> On Mon, Oct 26, 2009 at 2:18 PM, Robert Caldecott
>  wrote:
>>
>> I like the idea of a dedicated QTest output pane - will you be able  
>> to double-click on failures to jump directly to the code?  That  
>> would be brilliant.
>>
>> 2009/10/26 Bravo.Alex 
>>>
 Plus that it's not so high in the list of things to do.
>>>
>>>
>>>
>>> If you are talking about qtcrea...@nokia team, it makes a lot of  
>>> sense.
>>>
>>> But that's why you guys opened development to outside world, right?
>>>
>>> So that we can help you improve already great product.
>>>
>>>
>>>
>>>
>>>
>>> So, back to qtestlibplugin:
>>>
>>> After bringing it back from the dead, I realized that the  
>>> architecture of this plugin might need adjustment:
>>>
>>> Right now it has its own type of output "Test Results" (just like  
>>> "Build Issues", "Application Output" and 2 more).
>>>
>>> But, as this picture shows, there's not much space for different  
>>> types of output:
>>>
>>>
>>>
>>> Besides it doesn't make much sense to "pollute" IDE's screen with  
>>> "Test Results" button and list entry
>>>
>>> for applications that have nothing to do with QTestLib.
>>>
>>>
>>>
>>> It looks like there should be as little presence for this plugin  
>>> as possible in the IDE's GUI.
>>>
>>> Ideally, this plugin should show itself only if output of a  
>>> program is in QTestLib format.
>>>
>>>
>>>
>>> Thus this plugin really provides a different format of  
>>> "Application Output", not a different output pane.
>>>
>>>
>>>
>>> So proposed adjustment to this plugin is to be able to have  
>>> several formats of "Application Output".
>>>
>>> By default it's "raw" output, with the ability to switch to a  
>>> different format.
>>>
>>> In case of qtestlibplugin it can be "test results" and "benchmark  
>>> results" formats.
>>>
>>> Other plugins could have/add their own formats.
>>>
>>>
>>>
>>> What do you guys think?
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: qt-creator-boun...@trolltech.com 
>>> [mailto:qt-creator-boun...@trolltech.com 
>>> ] On Behalf Of Eike Ziller
>>> Sent: Monday, October 26, 2009 4:00 AM
>>> To: qt-creator@trolltech.com
>>> Subject: Re: [Qt-creator] plugin_qtestlib
>>>
>>>
>>>
>>>
>>>
>>> On Oct 20, 2009, at 7:24 PM, ext Bravo.Alex wrote:
>>>
>>>
>>>
 Why is it dead:
>>>
 a)  it's obsolete, we now have a new XYZ plugin supporting
>>>
 QTestLib in Qt Creator
>>>
 b)  the author is working on something else and doesn't have
>>>
 time/interest to work on it
>>>
 c)   it didn't do much, so it's not worth maintaining
>>>
 d)  nobody needs it, we are satisfied with running tests  
 through
>>>
 test.pl
>>>
>>>
>>>
>>> I suppose it's b) and c). Plus that it's not so high in the list of
>>>
>>> things to do.
>>>
>>> The only "maybe" s

[Qt-creator] : CMake and multiple targets i n CMakeLists.txt

2009-10-27 Thread Gena Cid
Hello!

I've found a tiny bug when tried Qt-creator on subj. Everything is just fine, 
but build steps contains two target: my custom target and 'all' (looks like 
'make all '). After uncheck and check again  
in the Targets list 'all' disappeared and everything is works as expected.

P.S. Use qt-creator-linux-x86_64-opensource-1.2.90

-|-
Гена.

___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] plugin_qtestlib

2009-10-27 Thread Coda Highland
> This could be extended to also put issues when running other Qt
> programs into the "issues" pane, like Qt warnings (connect failed,
> etc, etc).

I like the way you think.

/s/ Adam
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] feature request - add html page to qtcreator help system

2009-10-27 Thread Jens Frederich
Hi Karsten,

On Tue, Oct 27, 2009 at 2:11 PM, Karsten Heimrich <
karsten.heimr...@nokia.com> wrote:

> Hi Jens,
>
> ext Jens Frederich schrieb:
> > Hi list,
> >
> > I want to add an external html page to qtcreator's help system, so that
> > I can integrate other API documentations.
> > As a result it could also be possible to search through the external
> > documentation and to use F1 to jump to the
> > description of methods and classes outside of Qt4 API.
>
> If you are generating your documentation using doxygen, it is
> possible to let it output a help file for Qt Creator too. Theres
> already a blog about it here:
>
> http://blog.dixo.net/2009/05/20/using-doxygen-help-in-qtcreator
>
> Please note the patch mentioned there is already included the
> latest doxygen source.
>
>
That's fine, but I don't create the help files. I've an existing .chm from
intel and want to add this to qtcreator.

Regards,
Jens
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] CMake + Multiple Build configuration

2009-10-27 Thread Daniel Teske
On Wednesday 21 October 2009 16:37:16 ext Hari Sundar wrote:
> How can I specify multiple build configurations with CMake, so that it is
>  available within Creator. I am using v1.2.92
> 
> When I use CMake to generate Visual Studio projects, I get 4 build
>  configurations, release, debug, minsizedrelease, releasewithdebuginfo
> 
> How do I get these within Creator ?

It's a little bit more complicated (and also a little bit more flexible.)

To use multiple different build configurations, I would strongly recommend a 
different build directory per build configuration.

By default no parameters are passed to cmake, thus the default is (IIRC) 
RelWithDebInfo (which is Release with Debug Information).

To create additional buildconfigurations switch to the projects pane and choose 
"Add" next to the "Edit BuildConfiguration" label, choose create, choose a 
different build directory and on the second wizard page enter, one of:
-DCMAKE_BUILD_TYPE=None
-DCMAKE_BUILD_TYPE=Debug
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_BUILD_TYPE=MinSizeRel
into the arguments line edit. 

That should work.

daniel
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] feature request - add html page to qtcreator help system

2009-10-27 Thread Karsten Heimrich
Hi Jens,

ext Jens Frederich schrieb:
> Hi list,
> 
> I want to add an external html page to qtcreator's help system, so that 
> I can integrate other API documentations.
> As a result it could also be possible to search through the external 
> documentation and to use F1 to jump to the 
> description of methods and classes outside of Qt4 API. 

If you are generating your documentation using doxygen, it is 
possible to let it output a help file for Qt Creator too. Theres 
already a blog about it here:

http://blog.dixo.net/2009/05/20/using-doxygen-help-in-qtcreator

Please note the patch mentioned there is already included the 
latest doxygen source.

> Is it already possible to use external HTML pages in the help system

Yes, but they need to be put into a qt help file.

> how can I convert them to a QCH-file?

The documentation can be found here:

http://doc.trolltech.com/4.5/qthelpproject.html
http://doc.trolltech.com/4.5/qthelp.html#qt-help-collection-project


Regargs,
Karsten
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] feature request - add html page to qtcreator help system

2009-10-27 Thread Daniel Teske
On Tuesday 27 October 2009 09:09:39 ext Jens Frederich wrote:
> Hi list,
> 
> I want to add an external html page to qtcreator's help system, so that I
>  can integrate other API documentations. As a result it could also be
>  possible to search through the external documentation and to use F1 to
>  jump to the description of methods and classes outside of Qt4 API.
> Is it already possible to use external HTML pages in the help system or how
>  can I convert them to a QCH-file?

Theoretically it should be possible, though I'm not sure anyone has done that 
yet. I'd be interested if it works, too.
See http://doc.trolltech.com/4.5/qthelp.html#qt-help-collection-project on how 
to generate Qt Compressed Help files. (Ignore the help collection stuff, that's 
not needed for Creator.) Then register that documentation in Creator under 
Tools/Options.

The code in Creator actually showing the F1 help is in void 
CppHoverHandler::updateHelpIdAndTooltip() which does call 
QHelpEngine::linksForIdentifier(m_helpId) at the end. 

You might want to add a qDebug()

Re: [Qt-creator] plugin_qtestlib

2009-10-27 Thread Eike Ziller

On Oct 26, 2009, at 8:39 PM, ext Coda Highland wrote:

> Honestly I don't know if I want to set the precedent of allowing
> plugins to just arbitrarily add new tabs there.
>
> I think Build Issues would be a valid output target, though; it's
> already intended for jumping to the relevant places in the code and
> one could argue that failing a unit test is a build issue.

One option is to put the test issues into what now is the "build  
issues" pane:

When you build a program, you have the whole build log in the compile  
output pane, and a collection of the issues in the "issues" pane.
When you build your tests, you'd have the whole build log in the  
compile output pane, and a collection of the issues in the "issues"  
pane.
When you run your tests, you'd have the whole application debug log in  
the application output pane, and a collection of the issues in the  
"issues" pane.
This could be extended to also put issues when running other Qt  
programs into the "issues" pane, like Qt warnings (connect failed,  
etc, etc).
It would definitely make no sense to call it "build issues" then, but  
anyhow, it's just a label.
And it would definitely make no sense to add yet another tab for  
warnings when running Qt programs :)

Another option is to extend the application output pane with clickable  
links for Qt warnings, test result lines, and more.

++ Eike

>
> /s/ Adam
>
> On Mon, Oct 26, 2009 at 2:18 PM, Robert Caldecott
>  wrote:
>>
>> I like the idea of a dedicated QTest output pane - will you be able  
>> to double-click on failures to jump directly to the code?  That  
>> would be brilliant.
>>
>> 2009/10/26 Bravo.Alex 
>>>
 Plus that it's not so high in the list of things to do.
>>>
>>>
>>>
>>> If you are talking about qtcrea...@nokia team, it makes a lot of  
>>> sense.
>>>
>>> But that's why you guys opened development to outside world, right?
>>>
>>> So that we can help you improve already great product.
>>>
>>>
>>>
>>>
>>>
>>> So, back to qtestlibplugin:
>>>
>>> After bringing it back from the dead, I realized that the  
>>> architecture of this plugin might need adjustment:
>>>
>>> Right now it has its own type of output “Test Results” (just like  
>>> “Build Issues”, “Application Output” and 2 more).
>>>
>>> But, as this picture shows, there’s not much space for different  
>>> types of output:
>>>
>>>
>>>
>>> Besides it doesn’t make much sense to “pollute” IDE’s screen with  
>>> “Test Results” button and list entry
>>>
>>> for applications that have nothing to do with QTestLib.
>>>
>>>
>>>
>>> It looks like there should be as little presence for this plugin  
>>> as possible in the IDE’s GUI.
>>>
>>> Ideally, this plugin should show itself only if output of a  
>>> program is in QTestLib format.
>>>
>>>
>>>
>>> Thus this plugin really provides a different format of  
>>> “Application Output”, not a different output pane.
>>>
>>>
>>>
>>> So proposed adjustment to this plugin is to be able to have  
>>> several formats of “Application Output”.
>>>
>>> By default it’s “raw” output, with the ability to switch to a  
>>> different format.
>>>
>>> In case of qtestlibplugin it can be “test results” and “benchmark  
>>> results” formats.
>>>
>>> Other plugins could have/add their own formats.
>>>
>>>
>>>
>>> What do you guys think?
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: qt-creator-boun...@trolltech.com 
>>> [mailto:qt-creator-boun...@trolltech.com 
>>> ] On Behalf Of Eike Ziller
>>> Sent: Monday, October 26, 2009 4:00 AM
>>> To: qt-creator@trolltech.com
>>> Subject: Re: [Qt-creator] plugin_qtestlib
>>>
>>>
>>>
>>>
>>>
>>> On Oct 20, 2009, at 7:24 PM, ext Bravo.Alex wrote:
>>>
>>>
>>>
 Why is it dead:
>>>
 a)  it’s obsolete, we now have a new XYZ plugin supporting
>>>
 QTestLib in Qt Creator
>>>
 b)  the author is working on something else and doesn’t have
>>>
 time/interest to work on it
>>>
 c)   it didn’t do much, so it’s not worth maintaining
>>>
 d)  nobody needs it, we are satisfied with running tests  
 through
>>>
 test.pl
>>>
>>>
>>>
>>> I suppose it's b) and c). Plus that it's not so high in the list of
>>>
>>> things to do.
>>>
>>> The only "maybe" still useful parts of the code in the plugin is
>>>
>>> probably the interaction/parsing of the QTestLib output.
>>>
>>>
>>>
>>> ++ Eike
>>>
>>>
>>>
   Alex
>>>

>>>
 On Tuesday 20 October 2009 17:47:42 ext Bravo.Alex wrote:
>>>
> I'm not very successful in finding any info about plugin_qtestlib.
>>>
> There's not many comments in the source code either.
>>>
>
>>>
> plugins.pro says this:
>>>
> plugin_qtestlib \ # this seems to be dead
>>>
>
>>>
> The source tree on gitorious.org is missing
>>>
 QTestLibPlugin.pluginspec for
>>>
>   it.
>>>
>
>>>
> Does anybody know what it was supposed to do?
>>>
 It's dead and the code probably is not very useful anymore either.
>>>

>>>
 daniel

Re: [Qt-creator] Breakpoint Problem

2009-10-27 Thread Robert Caldecott
Just downloaded the latest Windows snapshot and breakpoints are now
working correctly!

Thanks very much for getting this fixed.
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


[Qt-creator] feature request - add html page to qtcreator help system

2009-10-27 Thread Jens Frederich
Hi list,

I want to add an external html page to qtcreator's help system, so that I
can integrate other API documentations.
As a result it could also be possible to search through the external
documentation and to use F1 to jump to the
description of methods and classes outside of Qt4 API.
Is it already possible to use external HTML pages in the help system or how
can I convert them to a QCH-file?

Cheers,
Jens


-- 
Jens Frederich
Senior Software Engineer
freder...@volumegraphics.com
+49-6221-73920-75
-
Volume Graphics GmbH, Firmensitz: 69123 Heidelberg, Deutschland
Geschäftsführer: Christof Reinhart, Christoph Poliwoda, Thomas Günther
Amtsgericht Heidelberg, HRB 335703, USt-ID: DE187252420
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator


Re: [Qt-creator] Huge memory consumtion

2009-10-27 Thread Guenter Schwann
On Saturday 24 October 2009, you wrote:
> I think the problem was the excessive use of backtracking when parsing  
> ambiguous id-expressions (simple-names vs template-ids).
> Now we are doing a better job when parsing those ambiguous names so I  
> expect better numbers.
> 
> please try again with today's snapshot or pull and recompile the 1.3  
> branch (our master branch on gitorious is a bit outdated, it doesn't  
> have all the fixes yet).

I just testet the current snapshot, and the memory consumption is at about 
200MB :-)
I'm a happy hacker again :-P

> Thanks for your very detailed report

Just to clarify for the mailinglist, roberto got some more information 
"privately"...

Thanks
-- 
Guenter Schwann 

GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator