Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Tobias Hunger]

Hi Danny!

Thanks for sending the broken project. I'll look into it later today.

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@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] printf() with Qt Creator?

[Eike Ziller]

On Apr 24, 2010, at 11:51 PM, ext Danny Price wrote:

> 
> On 24 Apr 2010, at 22:22, Robert Hairgrove wrote:
>>> 
>> 
>> This is also an issue in non-Qt apps. Just change this line:
>>  std::cout << "test";
>> to this:
>>  std::cout << "test" << std::endl;
>> 
>> On some platforms (*nix, I think) you need to do this in order to keep 
>> the next output from overwriting the line "test".
> 
> Thanks it now works! The CONFIG += console line appears to have no effect on 
> OSX either way. I suppose it's really for Windows?

http://doc.qt.nokia.com/4.6/qmake-variable-reference.html#config

> I've not been able to get printf to work though, even with a '\n'.
> 
>> ___
>> Qt-creator mailing list
>> Qt-creator@trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-creator
> 
> 

-- 
Eike Ziller
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@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Tobias Hunger]

Hi Danny!

Sorry, I really do not see anything to fix in creator for the following 
reasons:

  * No variable is ignored. DESTDIR is relative to the build directory, 
so it is set and used correctly (but points to a location where the 
stuff it is looking for is not found).

  * No build pathes are changed. Everything is put exactly where specified.

  * Creator does not interfere with anything set in the .pro-file.



Your example project layout is basically three separate projects, tied 
together using relative pathes so that the libraries are found. That 
does indeed break in the presence of shadow building (or even more minor 
changes like the user checking out these three projects into separate 
directories, renaming some directory, etc.). I do not know your project 
requirements and there is probably a good reason for doing things the 
way you did, but I would really suggest making the build system more robust.

The preferred way is of course (as you already suggested) to bundle the 
libraries and the application using them together into one SUBDIRS 
project. That way you do get dependency tracking and the libraries will 
get automatically rebuild when they are changed. This further should 
ease packaging of the complete thing.

If you are reusing the same libraries together with several applications 
you can of course have several top-level SUBDIRS project files (one for 
each application, referencing the application itself and all libraries 
used by it).

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@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Danny Price]

On Mon, Apr 26, 2010 at 11:13 AM, Tobias Hunger wrote:

> Hi Danny!
>
> Sorry, I really do not see anything to fix in creator for the following
> reasons:
>
>  * No variable is ignored. DESTDIR is relative to the build directory,
> so it is set and used correctly (but points to a location where the
> stuff it is looking for is not found).
>
>  * No build pathes are changed. Everything is put exactly where specified.
>
>  * Creator does not interfere with anything set in the .pro-file.
>
>
> Your example project layout is basically three separate projects, tied
> together using relative pathes so that the libraries are found. That
> does indeed break in the presence of shadow building (or even more minor
> changes like the user checking out these three projects into separate
> directories, renaming some directory, etc.). I do not know your project
> requirements and there is probably a good reason for doing things the
> way you did, but I would really suggest making the build system more
> robust.
>

Ah so you can explain how I should modify the sample projects to do just
that? I assume that relative paths from the shadow build directories are
also a bad idea?


> The preferred way is of course (as you already suggested) to bundle the
> libraries and the application using them together into one SUBDIRS
> project. That way you do get dependency tracking and the libraries will
> get automatically rebuild when they are changed. This further should
> ease packaging of the complete thing.
>

Now this I find interesting as it seems to contradict Nokia's previous
advice on the subject - that is to use sessions...

I've had very mixed results with SUBDIRS in creator. I have to be setup
manually, require the use of undocumented qmake features and don't always
link together properly when dependants change. And until recently, you had
to rebuild the until tree for a single dependant change to be picked up.

But even if I use a subdir, won't I have the same issues? SUBDIRS allow me
to specify the build order but not link dependencies for which I need
PRE_TARGETDEPS. So I have to specify a path. What path do I specify?


>
> If you are reusing the same libraries together with several applications
> you can of course have several top-level SUBDIRS project files (one for
> each application, referencing the application itself and all libraries
> used by it).
>

Thanks I might try that.


>
> 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@trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Tobias Hunger]

Hi Danny!

On 26.04.2010 13:14, ext Danny Price wrote:
> Ah so you can explain how I should modify the sample projects to do just
> that? I assume that relative paths from the shadow build directories are
> also a bad idea?

Yeap:-)

If the libraries hardly ever change then you could install them (or put 
them into a absolute path somewhere). That is *ugly* as hell, but it 
will work woth bpth shadow building and in source building. I really 
suggest using the SUBDIRS approach.

> Now this I find interesting as it seems to contradict Nokia's previous
> advice on the subject - that is to use sessions...

Please do not confuse my rumblings here with "Nokia's advice"! I am just 
one developer and in no way willing or able to speak for Nokia as a whole.

> I've had very mixed results with SUBDIRS in creator. I have to be setup
> manually, require the use of undocumented qmake features and don't
> always link together properly when dependants change.

Yes, documentation for qmake could be improved.

> And until
> recently, you had to rebuild the until tree for a single dependant
> change to be picked up.

That can indeed happen occasionally. Touching the files in question 
should do the trick though.

> But even if I use a subdir, won't I have the same issues? SUBDIRS allow
> me to specify the build order but not link dependencies for which I need
> PRE_TARGETDEPS. So I have to specify a path. What path do I specify?

Qt Creator has quite a bit of dependency setup in src/plugins. Maybe you 
can get some inspiration from there?

We are of course aware that there are issues with shadow building. Most 
of them are centered around resource usage (text files, pictures, etc.). 
The shadow build application will have trouble finding those if it tries 
to find them relative to its own location and they were shipped in the 
source tree.

-- 
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@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator Crash under RHEL5 (Code Syntax Related?)

[roberto.raggi]

Hi Victor,

I think that crash was fixed in 5a7858f5ec36f01036bf36f5d60425a6c0ceef33

http://bugreports.qt.nokia.com/browse/QTCREATORBUG-673?page=com.googlecode.jira-suite-utilities:transitions-summary-tabpanel

ciao robe



On Apr 25, 2010, at 6:23 AM, ext Victor Sardina wrote:

Fellows:

I don't know if this would help fix the problem, but find below some
more information on the crash. For more detailed information I would
have to recompiled QtCreator in debug mode, but the output below hints
(I hope) to the source/location of the crash, namely:

Program received signal SIGSEGV, Segmentation fault.
0x2ce72432 in CPlusPlus::BackwardsScanner::mid ()
  from
/usr/local/Trolltech/Qt-4.7.0/qtcreator/lib/qtcreator/plugins/Nokia/../.
./libCPlusPlus.so.1

Victor

===
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/local/Trolltech/Qt-4.7.0/qtcreator/bin/qtcreator.bin
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0x2b90c93f4390 (LWP 7117)]
[New Thread 0x41df5940 (LWP 7123)]
[Thread 0x41df5940 (LWP 7123) exited]
[New Thread 0x41df5940 (LWP 7128)]
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
QColor::setNamedColor: Unknown color name ''
[New Thread 0x427fa940 (LWP 7129)]
Detaching after fork from child process 7130.
[New Thread 0x431fb940 (LWP 7135)]
[New Thread 0x43bfc940 (LWP 7136)]
Detaching after fork from child process 7137.
Detaching after fork from child process 7138.
Detaching after fork from child process 7139.
Detaching after fork from child process 7140.
Detaching after fork from child process 7141.
Detaching after fork from child process 7142.
Detaching after fork from child process 7143.
Detaching after fork from child process 7144.
[New Thread 0x445fd940 (LWP 7145)]
[New Thread 0x44ffe940 (LWP 7146)]
[New Thread 0x459ff940 (LWP 7147)]
[Thread 0x445fd940 (LWP 7145) exited]
[New Thread 0x445fd940 (LWP 7148)]
[New Thread 0x46400940 (LWP 7149)]
[Thread 0x44ffe940 (LWP 7146) exited]
[Thread 0x459ff940 (LWP 7147) exited]
[New Thread 0x459ff940 (LWP 7150)]
Detaching after fork from child process 7153.
Detaching after fork from child process 7155.
[New Thread 0x44ffe940 (LWP 7157)]
[New Thread 0x46e01940 (LWP 7158)]
[Thread 0x46400940 (LWP 7149) exited]

Program received signal SIGSEGV, Segmentation fault.
0x2ce72432 in CPlusPlus::BackwardsScanner::mid ()
  from
/usr/local/Trolltech/Qt-4.7.0/qtcreator/lib/qtcreator/plugins/Nokia/../.
./libCPlusPlus.so.1


Victor Sardina wrote:
Fellows:

I happened to come across a rather unusual crash of QtCreator under
RHEL5. I will try to explain the steps to reproduce the crash:

1) Go to a function implementation line, like:

int FooClass::FooFunction(int const& i, int const& j,
  int const& k, int const& h)
{  ...
   ...
}

and  break it down like so:

int FooClass::FooFunction
  (int const& i, int const& j,
   int const& k, int const& h)
{  ...
   ...
}

2) Then go to the end of the first line of arguments, erased the "," and
try writing it back...

I get an instant crash each time I try to do this under RedHat 5. At
first I thought that it had something to do with the FakeVim plugin, but
no, it happens even when not using the FakeVim plugin. This appear to
indicate that for some reason the Editor can't cope with the parsing of
code written in that manner, maybe something to do with the handling of
the scope operator "::"? Whatever the reason, this happens each time you
follow 1) and 2) above. I will try it under Mac tomorrow and see what
happens.

Has anyone seen this behaviour before?

Victor
___
Qt-creator mailing list
Qt-creator@trolltech.com

Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Eike Ziller]

On Apr 26, 2010, at 1:14 PM, ext Danny Price wrote:

> 
> On Mon, Apr 26, 2010 at 11:13 AM, Tobias Hunger  
> wrote:
>> Hi Danny!
>> 
>> Sorry, I really do not see anything to fix in creator for the following
>> reasons:
>> 
>>  * No variable is ignored. DESTDIR is relative to the build directory,
>> so it is set and used correctly (but points to a location where the
>> stuff it is looking for is not found).
>> 
>>  * No build pathes are changed. Everything is put exactly where specified.
>> 
>>  * Creator does not interfere with anything set in the .pro-file.
>> 
>> 
>> Your example project layout is basically three separate projects, tied
>> together using relative pathes so that the libraries are found. That
>> does indeed break in the presence of shadow building (or even more minor
>> changes like the user checking out these three projects into separate
>> directories, renaming some directory, etc.). I do not know your project
>> requirements and there is probably a good reason for doing things the
>> way you did, but I would really suggest making the build system more robust.
>> 
> Ah so you can explain how I should modify the sample projects to do just 
> that? I assume that relative paths from the shadow build directories are also 
> a bad idea?
>  
>> The preferred way is of course (as you already suggested) to bundle the
>> libraries and the application using them together into one SUBDIRS
>> project. That way you do get dependency tracking and the libraries will
>> get automatically rebuild when they are changed. This further should
>> ease packaging of the complete thing.
>> 
> Now this I find interesting as it seems to contradict Nokia's previous advice 
> on the subject - that is to use sessions... 

We (as in "a bunch of Qt Creator developers") have been promoting the use of 
subdirs pro files a lot as well on this mailing list. Because both sessions and 
special setups in Qt Creator's project settings are special Qt Creator setups. 
So relying on these is no use in mixed environments.

> I've had very mixed results with SUBDIRS in creator. I have to be setup 
> manually, require the use of undocumented qmake features and don't always 
> link together properly when dependants change. And until recently, you had to 
> rebuild the until tree for a single dependant change to be picked up.
> 
> But even if I use a subdir, won't I have the same issues? SUBDIRS allow me to 
> specify the build order but not link dependencies for which I need 
> PRE_TARGETDEPS. So I have to specify a path. What path do I specify?

Since you would open the SUBDIRS project in Qt Creator, you end up with a 
single project in Qt Creator,
and therefore with a single shadow build directory for your whole, multi-part 
project. So you can use relative paths for mapping between the sub-projects.
Like when opening qtcreator.pro.
The thing that is not clear to me (haven't tried), though, is how qmake 
actually maps the paths to a shadow build directory if you use SUBDIRS that 
refer to sub projects via ../ (ie. if your sub projects are not in a sub-path 
of the SUBDIRS project).

> 
>> If you are reusing the same libraries together with several applications
>> you can of course have several top-level SUBDIRS project files (one for
>> each application, referencing the application itself and all libraries
>> used by it).
>> 
> Thanks I might try that.
>  
> 

Br, Eike

-- 
Eike Ziller
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@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Danny Price]

On Mon, Apr 26, 2010 at 1:12 PM, Eike Ziller  wrote:

>
> On Apr 26, 2010, at 1:14 PM, ext Danny Price wrote:
>
> >
> > On Mon, Apr 26, 2010 at 11:13 AM, Tobias Hunger 
> wrote:
> >> Hi Danny!
> >>
> >> Sorry, I really do not see anything to fix in creator for the following
> >> reasons:
> >>
> >>  * No variable is ignored. DESTDIR is relative to the build directory,
> >> so it is set and used correctly (but points to a location where the
> >> stuff it is looking for is not found).
> >>
> >>  * No build pathes are changed. Everything is put exactly where
> specified.
> >>
> >>  * Creator does not interfere with anything set in the .pro-file.
> >>
> >>
> >> Your example project layout is basically three separate projects, tied
> >> together using relative pathes so that the libraries are found. That
> >> does indeed break in the presence of shadow building (or even more minor
> >> changes like the user checking out these three projects into separate
> >> directories, renaming some directory, etc.). I do not know your project
> >> requirements and there is probably a good reason for doing things the
> >> way you did, but I would really suggest making the build system more
> robust.
> >>
> > Ah so you can explain how I should modify the sample projects to do just
> that? I assume that relative paths from the shadow build directories are
> also a bad idea?
> >
> >> The preferred way is of course (as you already suggested) to bundle the
> >> libraries and the application using them together into one SUBDIRS
> >> project. That way you do get dependency tracking and the libraries will
> >> get automatically rebuild when they are changed. This further should
> >> ease packaging of the complete thing.
> >>
> > Now this I find interesting as it seems to contradict Nokia's previous
> advice on the subject - that is to use sessions...
>
> We (as in "a bunch of Qt Creator developers") have been promoting the use
> of subdirs pro files a lot as well on this mailing list. Because both
> sessions and special setups in Qt Creator's project settings are special Qt
> Creator setups. So relying on these is no use in mixed environments.
>
> > I've had very mixed results with SUBDIRS in creator. I have to be setup
> manually, require the use of undocumented qmake features and don't always
> link together properly when dependants change. And until recently, you had
> to rebuild the until tree for a single dependant change to be picked up.
> >
> > But even if I use a subdir, won't I have the same issues? SUBDIRS allow
> me to specify the build order but not link dependencies for which I need
> PRE_TARGETDEPS. So I have to specify a path. What path do I specify?
>
> Since you would open the SUBDIRS project in Qt Creator, you end up with a
> single project in Qt Creator,
> and therefore with a single shadow build directory for your whole,
> multi-part project. So you can use relative paths for mapping between the
> sub-projects.
> Like when opening qtcreator.pro.
> The thing that is not clear to me (haven't tried), though, is how qmake
> actually maps the paths to a shadow build directory if you use SUBDIRS that
> refer to sub projects via ../ (ie. if your sub projects are not in a
> sub-path of the SUBDIRS project).
>
>
Thanks for the clarification. So if you're going to be pushing shadow builds
from now on, and SUBDIRs are the most compatible form of project
organization, can we expect to see improved support for SUBDIRs in Creator
any time soon?


>
> >> If you are reusing the same libraries together with several applications
> >> you can of course have several top-level SUBDIRS project files (one for
> >> each application, referencing the application itself and all libraries
> >> used by it).
> >>
> > Thanks I might try that.
> >
> >
>
> Br, Eike
>
> --
> Eike Ziller
> 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@trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator

Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer

[Coda Highland]

Qxt is a SUBDIRS project and I haven't had a problem with it in
Creator... um... ever. What problems are you describing?

On Mon, Apr 26, 2010 at 7:54 AM, Danny Price  wrote:
>
>
> On Mon, Apr 26, 2010 at 1:12 PM, Eike Ziller  wrote:
>>
>> On Apr 26, 2010, at 1:14 PM, ext Danny Price wrote:
>>
>> >
>> > On Mon, Apr 26, 2010 at 11:13 AM, Tobias Hunger
>> >  wrote:
>> >> Hi Danny!
>> >>
>> >> Sorry, I really do not see anything to fix in creator for the following
>> >> reasons:
>> >>
>> >>  * No variable is ignored. DESTDIR is relative to the build directory,
>> >> so it is set and used correctly (but points to a location where the
>> >> stuff it is looking for is not found).
>> >>
>> >>  * No build pathes are changed. Everything is put exactly where
>> >> specified.
>> >>
>> >>  * Creator does not interfere with anything set in the .pro-file.
>> >>
>> >>
>> >> Your example project layout is basically three separate projects, tied
>> >> together using relative pathes so that the libraries are found. That
>> >> does indeed break in the presence of shadow building (or even more
>> >> minor
>> >> changes like the user checking out these three projects into separate
>> >> directories, renaming some directory, etc.). I do not know your project
>> >> requirements and there is probably a good reason for doing things the
>> >> way you did, but I would really suggest making the build system more
>> >> robust.
>> >>
>> > Ah so you can explain how I should modify the sample projects to do just
>> > that? I assume that relative paths from the shadow build directories are
>> > also a bad idea?
>> >
>> >> The preferred way is of course (as you already suggested) to bundle the
>> >> libraries and the application using them together into one SUBDIRS
>> >> project. That way you do get dependency tracking and the libraries will
>> >> get automatically rebuild when they are changed. This further should
>> >> ease packaging of the complete thing.
>> >>
>> > Now this I find interesting as it seems to contradict Nokia's previous
>> > advice on the subject - that is to use sessions...
>>
>> We (as in "a bunch of Qt Creator developers") have been promoting the use
>> of subdirs pro files a lot as well on this mailing list. Because both
>> sessions and special setups in Qt Creator's project settings are special Qt
>> Creator setups. So relying on these is no use in mixed environments.
>>
>> > I've had very mixed results with SUBDIRS in creator. I have to be setup
>> > manually, require the use of undocumented qmake features and don't always
>> > link together properly when dependants change. And until recently, you had
>> > to rebuild the until tree for a single dependant change to be picked up.
>> >
>> > But even if I use a subdir, won't I have the same issues? SUBDIRS allow
>> > me to specify the build order but not link dependencies for which I need
>> > PRE_TARGETDEPS. So I have to specify a path. What path do I specify?
>>
>> Since you would open the SUBDIRS project in Qt Creator, you end up with a
>> single project in Qt Creator,
>> and therefore with a single shadow build directory for your whole,
>> multi-part project. So you can use relative paths for mapping between the
>> sub-projects.
>> Like when opening qtcreator.pro.
>> The thing that is not clear to me (haven't tried), though, is how qmake
>> actually maps the paths to a shadow build directory if you use SUBDIRS that
>> refer to sub projects via ../ (ie. if your sub projects are not in a
>> sub-path of the SUBDIRS project).
>>
>
> Thanks for the clarification. So if you're going to be pushing shadow builds
> from now on, and SUBDIRs are the most compatible form of project
> organization, can we expect to see improved support for SUBDIRs in Creator
> any time soon?
>
>> >
>> >> If you are reusing the same libraries together with several
>> >> applications
>> >> you can of course have several top-level SUBDIRS project files (one for
>> >> each application, referencing the application itself and all libraries
>> >> used by it).
>> >>
>> > Thanks I might try that.
>> >
>> >
>>
>> Br, Eike
>>
>> --
>> Eike Ziller
>> 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@trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-creator
>
>
> ___
> Qt-creator mailing list
> Qt-creator@trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>
>

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

Re: [Qt-creator] provide solution, how to link video to maemo5 sdk window

[Awadhesh Kumar]

Hi ,
Thanks for your feddback.
I know about Phonon.
But i want to use my own way.

Thanks,
Awadhesh

2010/4/23 Thorbjørn Lindeijer 

> On 04/23/2010 04:04 PM, ext Awadhesh Kumar wrote:
> >
> > Hi all,
> >
> > Any one help me.
> >
> > How to add video in Maemo5 SDK scrachbox using Qt and gstreamer.
> >
> > Please provide some hints and links.
> >
> > i am try this code for link video to maemo5 sdk window.
> > videosink : created video sink using gstreamer pipeline.
> >
> > QWidget w;
> > QApplication :: syncX ();
> > gst_x_overlay_set_xwindow_id (GST_X_OVERLAY (videosink), w.winId ());
>
> This is not a Qt Creator related question, rather about how to use Qt
> and gstreamer together. So you may want to try asking about this on the
> qt-interest mailing list, or try out Forum Nokia support [1].
>
> Note that with Qt 4.7, new QtMultimedia API is being added for video
> playback. Maybe you should check whether this can make your life easier.
> I don't know how far they are with supporting this on Maemo though.
> Another option may be to use Phonon.
>
> Regards,
> Bjørn
>



>
> [1]
>
> http://www.forum.nokia.com/I_Want_To/Develop_Mobile_Applications/Technical_Support/
>
> --
> Thorbjørn Lindeijer
> Software Engineer
> Nokia, Qt Development Frameworks
> ___
> Qt-creator mailing list
> Qt-creator@trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator