Mailing List Archive: MythTV: Dev

[ANNOUNCE] merging Qt4 branch to trunk

1 2

View All

Index | Next | Previous | View Threaded

janne-mythtv at grunau

Mar 15, 2008, 6:45 PM

Post #1 of 42 (6699 views)
Permalink

[ANNOUNCE] merging Qt4 branch to trunk

This email is being sent to serve as a warning to users that we will
start porting MythTV to Qt4 in trunk monday or tuesday next week (March
17th or 18th, 2008).

Due to the low-level of the changes it is not feasible to do the port in
a branch. This and the huge amount of changes will most likely cause
some instabilities in the coming weeks.

It is recommended to switch productive systems to release-0-21-fixes.
Not updating for some time would work too but it will miss bugfixes
committed to the release branch.

The required Qt version will be Qt 4.3.

Janne
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

arnonm at gmail

Mar 16, 2008, 2:57 AM

Post #2 of 42 (6600 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Great news.

With Eclipse's support for QT4, this can provide us with a multi-platform
gui environment for design and development

Arnon

stuart at tase

Mar 16, 2008, 3:12 AM

Post #3 of 42 (6592 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Sunday 16 March 2008 09:57:04 Arnon Meshoulam wrote:
> Great news.
>
> With Eclipse's support for QT4, this can provide us with a multi-platform
> gui environment for design and development

We already have a multi-platform GUI environment, it's called mythui.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuart at tase

Mar 16, 2008, 3:16 AM

Post #4 of 42 (6605 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Sunday 16 March 2008 10:12:32 Stuart Morgan wrote:
> On Sunday 16 March 2008 09:57:04 Arnon Meshoulam wrote:
> > Great news.
> >
> > With Eclipse's support for QT4, this can provide us with a multi-platform
> > gui environment for design and development
>
> We already have a multi-platform GUI environment, it's called mythui.

Sorry, sorry! I didn't get any sleep last night and I completely mis-read your
email!

Yeah, Eclipse will be a nice prospect for those wanting to work on MythTV.
Though I still prefer KDevelop ;)

--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

pebender at san

Mar 17, 2008, 10:52 AM

Post #5 of 42 (6575 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Janne Grunau wrote:
> This email is being sent to serve as a warning to users that we will
> start porting MythTV to Qt4 in trunk monday or tuesday next week (March
> 17th or 18th, 2008).
>
> Due to the low-level of the changes it is not feasible to do the port in
> a branch. This and the huge amount of changes will most likely cause
> some instabilities in the coming weeks.
>
> It is recommended to switch productive systems to release-0-21-fixes.
> Not updating for some time would work too but it will miss bugfixes
> committed to the release branch.
>
> The required Qt version will be Qt 4.3.
>
> Janne

Is there a compelling reason for requiring Qt 4.3 rather than Qt 4.2?

I ask this because RHEL 5.1 and therefore CentOS 5.1 come with Qt 4.2.1.
Many people (including myself) use RHEL/CentOS for their backend so that
they can stay off the OS upgrade treadmill. As of now, the next minor
RHEL (5.2) release does not ugrade Qt. Therefore, Qt 4.3 would require
custom RPMs. It would be unfortunate to require custom Qt RPMs in order
to upgrade MythTV.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

janne-mythtv at grunau

Mar 17, 2008, 12:08 PM

Post #6 of 42 (6584 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Monday 17 March 2008 18:52:25 Paul Bender wrote:
> Janne Grunau wrote:
> >
> > The required Qt version will be Qt 4.3.
>
> Is there a compelling reason for requiring Qt 4.3 rather than Qt 4.2?

I was considering even requiring the unreleased qt4.4 for qtwebkit. So
4.3 was natural other choice. I didn't spent much thought about the
version since qt4.3 is a year old. My main reason for choosing 4.3 are
the difficulties of bumping a required version later.

There a thoughts of using qtscript for extended theming.

Janne
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

pebender at san

Mar 17, 2008, 2:42 PM

Post #7 of 42 (6581 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Janne Grunau wrote:
> On Monday 17 March 2008 18:52:25 Paul Bender wrote:
>> Janne Grunau wrote:
>>> The required Qt version will be Qt 4.3.
>> Is there a compelling reason for requiring Qt 4.3 rather than Qt 4.2?
>
> I was considering even requiring the unreleased qt4.4 for qtwebkit. So
> 4.3 was natural other choice. I didn't spent much thought about the
> version since qt4.3 is a year old. My main reason for choosing 4.3 are
> the difficulties of bumping a required version later.

When considering a stable OS, a year is not that long a time.

There was considerable discussion surrounding bumping the minimum
versions for MySQL and PHP version requirements. The big concern was
around which distributions and distribution versions it would obsolete.
The choice in Qt version has the same issues. Did I miss the discussion?

For the user community, the difficulty in bumping the minimum required
version of a package is more about how new the version is rather than
how often it is bumped. If the version is too new, then it causes the
problem that will be caused by using Qt 4.3 or 4.4: people will have to
build custom Qt packages that are not part of their distributions.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

masterclc at gmail

Mar 17, 2008, 3:54 PM

Post #8 of 42 (6573 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Mon, Mar 17, 2008 at 3:42 PM, Paul Bender <pebender [at] san> wrote:

> For the user community, the difficulty in bumping the minimum required
> version of a package is more about how new the version is rather than
> how often it is bumped. If the version is too new, then it causes the
> problem that will be caused by using Qt 4.3 or 4.4: people will have to
> build custom Qt packages that are not part of their distributions.

Wouldn't the exact same reasoning apply to the reverse logic though?
If you build for half of the distros, which "half" do you pick? My
guess would be that you would pick the camp with the newer packages
since eventually the newer ones will have prebuilt pacakges available
in the newer version whereas if you build for the older group you
essentially require everyone at some point to continue using older
packages or 'custom' built ones. Building ahead, to me, makes more
sense.

-Chad
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

pebender at san

Mar 17, 2008, 4:25 PM

Post #9 of 42 (6580 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Chad wrote:
> On Mon, Mar 17, 2008 at 3:42 PM, Paul Bender <pebender [at] san> wrote:
>
>> For the user community, the difficulty in bumping the minimum required
>> version of a package is more about how new the version is rather than
>> how often it is bumped. If the version is too new, then it causes the
>> problem that will be caused by using Qt 4.3 or 4.4: people will have to
>> build custom Qt packages that are not part of their distributions.
>
> Wouldn't the exact same reasoning apply to the reverse logic though?
> If you build for half of the distros, which "half" do you pick?

The short answer is:

no.

The long answer is:

It only applies when a newer version of the library obsoletes APIs from
an older version. Usually, libraries only do this with major releases of
the library. Minor releases usually add additional APIs without removing
existing APIs. In fact, minor releases are typically binary compatible.

The move from Qt 3 to Qt 4 was required because Qt 3 was EOL and not API
compatible with Qt 4.

However, my understanding is the Qt 4.3 is source and binary compatible
with Qt 4.2. That is, anything written for Qt 4.2 will compile on Qt 4.3
and anything compiled against Qt 4.2 will run on Qt 4.3. However,
because new APIs were introduced in Qt 4.3 any software that uses the
new APIs will not compile or run on Qt 4.2.

Therefore, unless the software needs functionality in Qt 4.3 it is
better to write it for Qt 4.2. Given that MythTV was currently compiles
on Qt 3.3, it is unlikely that it requires anything Qt 4.3. New features
in Qt 4.3 and Qt 4.4 might make things somewhat nicer, but I would doubt
that they are required.

Therefore, in this case, I think that it is better to make the minimum
required version no greater than Qt 4.2.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

skd5aner at gmail

Mar 17, 2008, 4:42 PM

Post #10 of 42 (6574 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Mon, Mar 17, 2008 at 5:42 PM, Paul Bender <pebender [at] san> wrote:
> Janne Grunau wrote:
> > On Monday 17 March 2008 18:52:25 Paul Bender wrote:
> >> Janne Grunau wrote:
> >>> The required Qt version will be Qt 4.3.
> >> Is there a compelling reason for requiring Qt 4.3 rather than Qt 4.2?
> >
> > I was considering even requiring the unreleased qt4.4 for qtwebkit. So
> > 4.3 was natural other choice. I didn't spent much thought about the
> > version since qt4.3 is a year old. My main reason for choosing 4.3 are
> > the difficulties of bumping a required version later.
>
> When considering a stable OS, a year is not that long a time.
>
> There was considerable discussion surrounding bumping the minimum
> versions for MySQL and PHP version requirements. The big concern was
> around which distributions and distribution versions it would obsolete.
> The choice in Qt version has the same issues. Did I miss the discussion?
>
> For the user community, the difficulty in bumping the minimum required
> version of a package is more about how new the version is rather than
> how often it is bumped. If the version is too new, then it causes the
> problem that will be caused by using Qt 4.3 or 4.4: people will have to
> build custom Qt packages that are not part of their distributions.
>

If you don't want to upgrade your distro, why upgrade myth? Keep it
as it is, a stable environment. If you want the latest and greatest,
then you're going to have to sacrafice a little in order to prevent
stagnation and killing innovation.

Someone's going to lose out either way... I vote for increased
functionality than legacy support.

Thanks!
Matt S
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Mar 17, 2008, 4:59 PM

Post #11 of 42 (6564 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On 03/17/2008 07:42 PM, Matt S. wrote:
> On Mon, Mar 17, 2008 at 5:42 PM, Paul Bender <pebender [at] san> wrote:
>
>> Janne Grunau wrote:
>>
>>> On Monday 17 March 2008 18:52:25 Paul Bender wrote:
>>>
>>>> Janne Grunau wrote:
>>>>
>>>>> The required Qt version will be Qt 4.3.
>>>>>
>>>> Is there a compelling reason for requiring Qt 4.3 rather than Qt 4.2?
>>>>
>>> I was considering even requiring the unreleased qt4.4 for qtwebkit. So
>>> 4.3 was natural other choice. I didn't spent much thought about the
>>> version since qt4.3 is a year old. My main reason for choosing 4.3 are
>>> the difficulties of bumping a required version later.
>>>
>> When considering a stable OS, a year is not that long a time.
> If you don't want to upgrade your distro, why upgrade myth? Keep it
> as it is, a stable environment. If you want the latest and greatest,
> then you're going to have to sacrafice a little in order to prevent
> stagnation and killing innovation.
>
> Someone's going to lose out either way... I vote for increased
> functionality than legacy support.

Besides, who's to say what the stable distros will be using when 0.22
with QT4 support is released, anyway? Perhaps they'll be on QT6.2 by
then. ;)

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

kormoc at gmail

Mar 17, 2008, 5:00 PM

Post #12 of 42 (6549 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Mon, Mar 17, 2008 at 4:25 PM, Paul Bender <pebender [at] san> wrote:
> Therefore, unless the software needs functionality in Qt 4.3 it is
> better to write it for Qt 4.2. Given that MythTV was currently compiles
> on Qt 3.3, it is unlikely that it requires anything Qt 4.3. New features
> in Qt 4.3 and Qt 4.4 might make things somewhat nicer, but I would doubt
> that they are required.
>
> Therefore, in this case, I think that it is better to make the minimum
> required version no greater than Qt 4.2.

That's easy to say when you're not the one doing the work...
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

pebender at san

Mar 17, 2008, 5:05 PM

Post #13 of 42 (6565 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Matt S. wrote:
> On Mon, Mar 17, 2008 at 5:42 PM, Paul Bender <pebender [at] san> wrote:

> If you don't want to upgrade your distro, why upgrade myth?

Your statement is equivalent to "If you don't want to buy a new house,
why buy new window drapes."

Many people's backends act as servers for many other services. Upgrading
MythTV is relatively benign compared to upgrading the entire OS.
Therefore, I get a stable server while being able to upgrade MythTV.

Also, if I do not upgrade then I provide new MiniMyth releass.

> Keep it
> as it is, a stable environment. If you want the latest and greatest,
> then you're going to have to sacrafice a little in order to prevent
> stagnation and killing innovation.

This is a nice generality. However, can you point to specific things in
Qt 4.3 and not in Qt 4.2 that will enable innovation in MythTV? If not,
then the statement does not apply to this instance.

> Someone's going to lose out either way... I vote for increased
> functionality than legacy support.

That is why I asked about what the need for 4.3 over 4.2 was. You are
assuming increased functionality. As stated "[the] main reason for
choosing 4.3 are the difficulties of bumping a required version later.",
not new functionality. If there is no new functionality because of using
4.3 over 4.2, then all there is additional work for many others.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

pebender at san

Mar 17, 2008, 5:10 PM

Post #14 of 42 (6568 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Michael T. Dean wrote:
> On 03/17/2008 07:42 PM, Matt S. wrote:
>> On Mon, Mar 17, 2008 at 5:42 PM, Paul Bender <pebender [at] san> wrote:
>>
>>> Janne Grunau wrote:
>>>
>>>> On Monday 17 March 2008 18:52:25 Paul Bender wrote:
>>>>
>>>>> Janne Grunau wrote:
>>>>>
>>>>>> The required Qt version will be Qt 4.3.
>>>>>>
>>>>> Is there a compelling reason for requiring Qt 4.3 rather than Qt 4.2?
>>>>>
>>>> I was considering even requiring the unreleased qt4.4 for qtwebkit. So
>>>> 4.3 was natural other choice. I didn't spent much thought about the
>>>> version since qt4.3 is a year old. My main reason for choosing 4.3 are
>>>> the difficulties of bumping a required version later.
>>>>
>>> When considering a stable OS, a year is not that long a time.
>> If you don't want to upgrade your distro, why upgrade myth? Keep it
>> as it is, a stable environment. If you want the latest and greatest,
>> then you're going to have to sacrafice a little in order to prevent
>> stagnation and killing innovation.
>>
>> Someone's going to lose out either way... I vote for increased
>> functionality than legacy support.
>
> Besides, who's to say what the stable distros will be using when 0.22
> with QT4 support is released, anyway? Perhaps they'll be on QT6.2 by
> then. ;)

QT 3 : released 10/2001
QT 4 : released 06/2005
QT 5 : ???
QT 6 : ???

I release that there was a somewhat long time between 0.20 and 0.21, but
I was hoping that the time between 0.21 and 0.22 would be less not
much more. ;)
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

pebender at san

Mar 17, 2008, 5:12 PM

Post #15 of 42 (6575 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Rob Smith wrote:
> On Mon, Mar 17, 2008 at 4:25 PM, Paul Bender <pebender [at] san> wrote:
>> Therefore, unless the software needs functionality in Qt 4.3 it is
>> better to write it for Qt 4.2. Given that MythTV was currently compiles
>> on Qt 3.3, it is unlikely that it requires anything Qt 4.3. New features
>> in Qt 4.3 and Qt 4.4 might make things somewhat nicer, but I would doubt
>> that they are required.
>>
>> Therefore, in this case, I think that it is better to make the minimum
>> required version no greater than Qt 4.2.
>
> That's easy to say when you're not the one doing the work...

Why do you think I asked the original question? Did you read it?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jaymode at gmail

Mar 17, 2008, 5:24 PM

Post #16 of 42 (6573 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

> That is why I asked about what the need for 4.3 over 4.2 was. You are
> assuming increased functionality. As stated "[the] main reason for
> choosing 4.3 are the difficulties of bumping a required version later.",
> not new functionality. If there is no new functionality because of using
> 4.3 over 4.2, then all there is additional work for many others.

Alot of work has been put into the Win32 version for MinGW/Msys. After
reading this, I decided to look at the 4.3.0 changelog:
http://trolltech.com/developer/notes/changes/changes-4.3.0/

- [121629] Added support for the MinGW/MSYS platform.

One change that is very important is the support for this MinGW/Msys
platform so that the windows port can continue.

jaymode at gmail

Mar 17, 2008, 5:27 PM

Post #17 of 42 (6558 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

> Alot of work has been put into the Win32 version for MinGW/Msys. After
> reading this, I decided to look at the 4.3.0 changelog:
> http://trolltech.com/developer/notes/changes/changes-4.3.0/
>
> - [121629] Added support for the MinGW/MSYS platform.
>
> One change that is very important is the support for this MinGW/Msys platform so that the windows port can continue.
>
>
Also, here is the "task tracker" link for this bug to see that this is only
fixed in version 4.3.0 and above:
http://trolltech.com/developer/task-tracker/index_html?id=121629&method=entry

dean.harding at dload

Mar 17, 2008, 5:39 PM

Post #18 of 42 (6559 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

Jay Modi wrote:
>
> Alot of work has been put into the Win32 version for MinGW/Msys.
> After reading this, I decided to look at the 4.3.0 changelog:
> http://trolltech.com/developer/notes/changes/changes-4.3.0/
>
> - [121629] Added support for the MinGW/MSYS platform.
>
> One change that is very important is the support for this MinGW/Msys platform so that the windows port can continue.
>
>
> Also, here is the "task tracker" link for this bug to see that this is
> only fixed in version 4.3.0 and above:
> http://trolltech.com/developer/task-tracker/index_html?id=121629&method=entry
> <http://trolltech.com/developer/task-tracker/index_html?id=121629&method=entry>

Do you actually *need* msys support, though? I mean, Qt has supported
Windows since version 3.3.something (I think) - the ticket you reference
is only for making Qt play nice with msys (which basically allows you to
use GNU automake/autoconf and stuff like that on Windows, which Myth
doesn't use anyway, does it?)

Dean.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jmodi at vt

Mar 17, 2008, 5:54 PM

Post #19 of 42 (6557 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

> Do you actually *need* msys support, though? I mean, Qt has supported
> Windows since version 3.3.something (I think) - the ticket you reference
> is only for making Qt play nice with msys (which basically allows you to
> use GNU automake/autoconf and stuff like that on Windows, which Myth
> doesn't use anyway, does it?)

AFAIK, automake/autoconf is not used. There really does not seem to a be a
great description of what that ticket means by "adding support for
MinGW/MSYS platform". I know QT can be used on Windows with MSVC, but
currently MythTV needs MinGW/MSYS and by the wording in the changelog, I
think one would want full support for this platform.

I am copying Andrei Tanas and David Buzz on this email to make sure this is
brought to their attention as they have done a good portion of the Win32
work and may know more about this issue.

mrand at pobox

Mar 17, 2008, 6:20 PM

Post #20 of 42 (6563 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Mon, Mar 17, 2008 at 7:27 PM, Jay Modi <jaymode [at] gmail> wrote:
> > Alot of work has been put into the Win32 version for MinGW/Msys. After
> reading this, I decided to look at the 4.3.0 changelog:
> > http://trolltech.com/developer/notes/changes/changes-4.3.0/
> > - [121629] Added support for the MinGW/MSYS platform.
> >
> > One change that is very important is the support for this MinGW/Msys
> platform so that the windows port can continue.
> >
>
> Also, here is the "task tracker" link for this bug to see that this is only
> fixed in version 4.3.0 and above:
> http://trolltech.com/developer/task-tracker/index_html?id=121629&method=entry

But designing MythTV to 4.2 specs would still allow the use of 4.3 for
Windows. Can any other reasons be identified for requiring 4.3?

Marc

Marc
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jmodi at vt

Mar 17, 2008, 6:28 PM

Post #21 of 42 (6567 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

> AFAIK, automake/autoconf is not used. There really does not seem to a be a
> great description of what that ticket means by "adding support for
> MinGW/MSYS platform". I know QT can be used on Windows with MSVC, but
> currently MythTV needs MinGW/MSYS and by the wording in the changelog, I
> think one would want full support for this platform.
>

Just doing a little more research on the issue, and I have found this
information from another project:
http://qwt.sourceforge.net/qwtinstall.html

The items of note are:

C2) MSYS Shell Qt >= 4.3.0

Support for the MSYS Shell has been improved in Qt 4.3.0.
Now building Qwt from the MSYS Shell works exactly like UNIX or in the
Windows Shell.

C3) MSYS Shell Qt < 4.3.0

For Qt < 4.3.0 you have to set the MINGW_IN_SHELL variable.
make will run into errors with the subdirs target, that can be
ignored (make -i).

export MINGW_IN_SHELL=1;

qmake
make -i
make -i install

So it seems as though it does play better with MSYS platform in general,
especially in compilation. Although, this is for a different project I feel
that this should be considered when debating which version of QT to use.
Also seems as though qmake was changed in 4.3.0:
http://lists.trolltech.com/qt-interest/2007-06/thread00366-0.html

But designing MythTV to 4.2 specs would still allow the use of 4.3 for
> Windows
>

That is correct, so I guess we can just require QT 4.3 for Windows at least.

kormoc at gmail

Mar 17, 2008, 6:39 PM

Post #22 of 42 (6570 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On Mon, Mar 17, 2008 at 6:20 PM, Marc Randolph <mrand [at] pobox> wrote:
> But designing MythTV to 4.2 specs would still allow the use of 4.3 for
> Windows. Can any other reasons be identified for requiring 4.3?

There's already been mention of using qt's webkit rather then kde's
for mythbrowser, but this would require qt 4.4 which isn't quite out
yet.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Mar 17, 2008, 6:56 PM

Post #23 of 42 (6559 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

On 03/17/2008 09:39 PM, Rob Smith wrote:
> On Mon, Mar 17, 2008 at 6:20 PM, Marc Randolph <mrand [at] pobox> wrote:
>
>> But designing MythTV to 4.2 specs would still allow the use of 4.3 for
>> Windows. Can any other reasons be identified for requiring 4.3?
>>
> There's already been mention of using qt's webkit rather then kde's
> for mythbrowser, but this would require qt 4.4 which isn't quite out
> yet.

http://www.gossamer-threads.com/lists/mythtv/dev/323733#323733
http://doc.trolltech.com/4.3/qt4-3-intro.html#qtscript-application-scripting-with-ecmascript

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jaymode at gmail

Mar 17, 2008, 7:02 PM

Post #24 of 42 (6577 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

> But designing MythTV to 4.2 specs would still allow the use of 4.3 for
> Windows. Can any other reasons be identified for requiring 4.3?

Well here are some features that stick out to me and seem like they could be
applied to MythTV:

QtScript:
http://doc.trolltech.com/4.3/qtscript.html

Improved Graphics Support:
"To improve graphics performance on Windows, this release includes an
experimental Direct3D paint engine to provide native hardware acceleration
on Windows systems with suitable graphics hardware ... The OpenGL paint
engine has been heavily improved to take advantage of new features in modern
graphics hardware. Through the extensive usage of fragment programs, users
with suitable graphics hardware can expect to experience much faster and
higher quality rendering when OpenGL is used. Support for an additional
anti-aliasing mode for OpenGL allows developers to choose between high
quality rendering or speed when older or less-capable hardware is used."

Desktop Integration:
"A platform-independent way to notify users about activity in a window is
provided by the
QApplication::alert<http://doc.trolltech.com/4.3/qapplication.html#alert>()
function. This alerts the user by using the appropriate notification
mechanism for their chosen platform and environment."

Infrastructure:
"Qt's threading has been enhanced to include support for timed try-locks in
QMutex <http://doc.trolltech.com/4.3/qmutex.html>,
QReadWriteLock<http://doc.trolltech.com/4.3/qreadwritelock.html>and
QSemaphore <http://doc.trolltech.com/4.3/qsemaphore.html>. Additionally, a
BlockingQueuedConnection<http://doc.trolltech.com/4.3/qt.html#ConnectionType-enum>connection
type has been introduced to complement
DirectConnection <http://doc.trolltech.com/4.3/qt.html#ConnectionType-enum>and
QueuedConnection
<http://doc.trolltech.com/4.3/qt.html#ConnectionType-enum>.QThread<http://doc.trolltech.com/4.3/qthread.html>has
been updated to provide an
idealThreadCount()<http://doc.trolltech.com/4.3/qthread.html#idealThreadCount>function.
This takes various system-specific factors into account to
determine the optimal number of threads that can be run on a given system.
The event system has been
extended<http://doc.trolltech.com/4.3/qcoreapplication.html#postEvent>to
allow events to be posted with specific priorities, enabling
applications
to prioritize certain types of event depending on the activities they are
performing. QDir <http://doc.trolltech.com/4.3/qdir.html> has been enhanced
with the addSearchPath()<http://doc.trolltech.com/4.3/qdir.html#addSearchPath>function
to provide an extensible mechanism, allowing search paths to be
added at run time to Qt's resource
system<http://doc.trolltech.com/4.3/resources.html>.
The new QDirIterator <http://doc.trolltech.com/4.3/qdiriterator.html> class
provides a convenient and less resource-intensive way to traverse large
directory structures."

All of these items were pulled from:
http://doc.trolltech.com/4.3/qt4-3-intro.html

andrei at tanas

Mar 17, 2008, 7:59 PM

Post #25 of 42 (6572 views)
Permalink

Re: [ANNOUNCE] merging Qt4 branch to trunk [In reply to]

<47DEAFD9.1010604 [at] san>
<200803172008.44388.janne-mythtv [at] grunau>
<47DEE5D7.7020400 [at] san>
<dd6abff40803171642v6e00d2a1ucb145d98f9709381 [at] mail>
<47DF073A.8040001 [at] san>
<6664ae760803171724gc776fadr51c052ec3eaed40f [at] mail>
<6664ae760803171727l66c096f2y2ab41c5617f3d8ca [at] mail>
<d38b16d80803171820t1903b1dehc29e80f6520a931d [at] mail> <6664ae760803171902u6911dd89t80328752dc61b393 [at] mail>
Message-ID: <84d09423e142bb771ee5e3813420feb1 [at] localhos>
X-Sender: andrei [at] tanas
Received: from 192.168.1.201 [192.168.1.201] via vhost.unchanged.net
[206.248.136.31] with HTTP/1.0 (POST); Mon, 17 Mar 2008 22:59:10
-0400
User-Agent: RoundCube Webmail/0.1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

On Mon, 17 Mar 2008 22:02:38 -0400, "Jay Modi" <jaymode [at] gmail> wrote:
>> But designing MythTV to 4.2 specs would still allow the use of 4.3 for
>> Windows. Can any other reasons be identified for requiring 4.3?
>
>
> Well here are some features that stick out to me and seem like they could
....

Jay, read the above (and the previos messages on this topic) carefully: if
QT 4.2 will be _minimal_ required version, there will be nothing to stop
anyone from using 4.3. I think this is perfectly fine.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads