Re: [Development] ChangeLogs

[Koehne Kai]

> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Thursday, January 17, 2013 4:49 PM
> To: development@qt-project.org
> Subject: Re: [Development] ChangeLogs
> 
> > [...]
> > first a bit of historical background: in The Good Old Trolltech Days
> > ™,
> > *every* developer was compelled to write changelog fragments for their
> > own commits before the release.
> > this was assisted by a somewhat primitive commit log browser with a
> > checkbox next to each entry, which created a prototypical changelog
> > entry for each checked commit.
> 
> I don't think it did that. The checkbox was only an aid to let you know
> whether you had reviewed everything. And for the release manager to know
> whom to bug about not having done their changelogs.

Anyway, most Qt committers were working full-time in one company. Times are 
different now, we're many more, a lot not working full time on Qt, so just 
asking all the committers to fix the log before a release doesn't really work 
out any more, even if we had a tool like above for git.

> > we introduce a new footer ("ChangeLog:") to commit messages. this
> > would shift the burden to the contributor, and it could be properly
> reviewed.
> > the generation the logs could be fully automated, and only minimal
> > redactional work would be necessary.
> > a (somewhat minor) downside would be some redundancy in the commit
> > messages.
> > don't suggest to change the style of the commit summaries to be
> > ready-made changelog entries - this would be neither without
> > disadvantages (different target audience), nor would it fully solve
> > the problem (selection of commits for the changelog).
> 
> I don't like writing it in the commit message because it clutters the message
> with redundant information. Maybe we should consider git notes -- if Gerrit
> can propagate them.

If git notes would be seamlessly integrated that might work out indeed. But 
honestly speaking I don't think an additional line in some important commits 
does hurt too much either ... Often enough the commit message might actually be 
!= the changelog entry != the JIRA task, because all of them have different 
audiences & purposes.

Anyway, if I understood Ossi's second mail right the message would in a final 
system not even be part of the git log any more.

> > an alternative would be auto-generating the changelog from jira tasks.
> > consequently, if you consider something important enough for a
> > changelog entry, you need to create a task for it if there is none
> > yet. i guess some metrics guys would love that idea, too. for
> > developers, it's of course additional work.
> 
> But not by much. This would be acceptable, provided that generating such a
> draft changelog isn't too difficult.

I personally wouldn't go the JIRA route. I consider changing the title and the 
text of a user's bug report by myself impolite, and asking the original 
reporter to fix it , split things into different tasks etc just for the sake of 
a clean commit log is also not very appealing. 

So I'd go for adding a 'Commit-log:' message to the git, with the potential 
extension of extracting it in gerrit later on.

Regards

Kai


> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Eskil Abrahamsen Blomfeldt]

On 01/17/2013 04:05 PM, Oswald Buddenhagen wrote:
> we introduce a new footer ("ChangeLog:") to commit messages. this would
> shift the burden to the contributor, and it could be properly reviewed.
> the generation the logs could be fully automated, and only minimal
> redactional work would be necessary.
> a (somewhat minor) downside would be some redundancy in the commit
> messages.
> don't suggest to change the style of the commit summaries to be
> ready-made changelog entries - this would be neither without
> disadvantages (different target audience), nor would it fully solve the
> problem (selection of commits for the changelog).
>
> an alternative would be auto-generating the changelog from jira tasks.
> consequently, if you consider something important enough for a changelog
> entry, you need to create a task for it if there is none yet. i guess
> some metrics guys would love that idea, too. for developers, it's of
> course additional work.

I'd prefer adding it to the commit message. There are times when we want 
to link a commit to a task number without having it appear in a commit 
log, e.g. when fixing a regression which was never released or adding 
some internal enablers which would only clutter the changelog and not 
provide any extra value to users. Thus we would either have to add a lot 
of logic to interpret the Jira tasks and try to determine whether it 
should be included in the log or not, or we would have to add the 
possibility of manually overriding it. It just seems like a lot of extra 
potential for committers to break the system.

Having it as part of the commit message seems a lot less complex to me, 
and I don't think it would do any harm to an extra line of 
meta-information in the bottom section with the change-id and 
task-number where there's already lots of clutter.

-- Eskil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Jedrzej Nowacki]

On Thursday 17. January 2013 18.25.29 Oswald Buddenhagen wrote:
> On Thu, Jan 17, 2013 at 04:05:40PM +0100, Oswald Buddenhagen wrote:
> > two more approaches have been previously proposed:
> hjk suggested yet another approach: use gerrit itself to collect the
> changelog entries. after some thinking, i came up with this process:
> - add a ChangeLog: line to the commit message as in the previous
>   proposal
> - the commit-msg hook extracts and removes that line; the post-commit
>   hook re-adds that line via git-notes
> - change is pushed as usual - with git-gpush (which gets extended to
>   push the notes as well)
> - gerrit receives the commit and notes, creates a change, and attaches
>   the changelog entry as an additional attribute to it
> - up to now, everything was an optional extension - to save the
>   contributor opening the gerrit page to add a changelog entry
> - but of course, it would be possible to edit the changelog entry in the
>   gui
> - the changelog entry would be approved together with the actual change.
>   whether this would happen in a separate review category, with the
>   stage/submit button, or something yet different, i don't know.
> - the system would require explicit action to approve the lack of a
>   changelog entry
> - for final storage, changelogs would be probably re-added as git
>   notes again
> - automated entry collection at release time would follow as with
>   in-commit-message ChangeLog: entries
> 
> the advantages of the system:
> - there is no "media break" like with a wiki or jira, as we use git and
>   gerrit anyway
> - the commit messages themselves are not "polluted"
> - the changelog entries can be modified without amending and re-pushing
>   the commit, thus not invalidating the actual review
> - it would be also possible to let the reviewers write the changelog
>   entry (which would then have to be approved by the contributor or
>   another reviewer in turn)
> - we could seamlessly switch from the in-commit-message ChangeLog:
>   variant, as nothing would change in the manual steps at commit
>   creation time (provided the notes-for-submission stuff would be
>   implemented right away)
> the downside is rather obvious:
> - this needs to be implemented in gerrit (unless somebody already did
>   something similar)
> 
> this is just a "step 2". it is in so far relevant, as the possibility of
> adding this later may be considered an endorsement for the original
> ChangeLog: variant.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

I like the approach, I'm just afraid that nobody will work on patching gerrit. 
It means that in real live we will end-up with the original ChangeLog variant. 
It seems that it is the best solution anyway. 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Thiago Macieira]

On sexta-feira, 18 de janeiro de 2013 09.54.37, Eskil Abrahamsen Blomfeldt 
wrote:
> Having it as part of the commit message seems a lot less complex to me, 
> and I don't think it would do any harm to an extra line of 
> meta-information in the bottom section with the change-id and 
> task-number where there's already lots of clutter.

It's not always just one line. We're talking about a paragraph.

Here's what a commit message would look like, if I had used that for the 
commit I've just pushed:

===
Clear the current thread data for the main thread

This avoids crashes accessing deleted memory when creating a QObject
after the last QObject had been deleted, like a qDebug() in global
destructors.

==41000== Invalid read of size 4
==41000==at 0x5F01ED5: bool QBasicAtomicOps<4>::ref(int&) 
(qatomic_x86.h:208)
==41000==by 0x5F01309: QBasicAtomicInteger::ref() 
(qbasicatomic.h:147)
==41000==by 0x5F24051: QThreadData::ref() (qthread.cpp:100)
==41000==by 0x614A984: QObject::QObject(QObject*) (qobject.cpp:681)
==41000==  Address 0x6ee73f0 is 0 bytes inside a block of size 152 free'd
==41000==at 0x4A0736C: operator delete(void*) (vg_replace_malloc.c:480)
==41000==by 0x5F240BF: QThreadData::deref() (qthread.cpp:109)
==41000==by 0x6113F6B: QCoreApplicationData::~QCoreApplicationData() 
(qcoreapplication.cpp:268)

ChangeLog: Fixed a crash that would cause the QObject constructor to crash if 
it was run during application shut down (that is, in global destructors).

Change-Id: I0dba895b041fe6cf81e6f8939ca85035cd00aad1
===

Note how it's repeating information that was already present in the commit 
message (it's redundant), just in a different way. Also note how the change log 
is not a line, but a longer sentence.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Oswald Buddenhagen]

On Thu, Jan 17, 2013 at 11:48:50PM +0800, Thiago Macieira wrote:
> On quinta-feira, 17 de janeiro de 2013 16.05.40, Oswald Buddenhagen wrote:
> > 5.0.0 is one of the poorest qt changelogs seen in a while.
> 
> Qt 5.0.0 is also one of the most major releases seen in a while -- 7.5
> years to be precise. The major release deserves special treatment: we
> agreed on listing what was important for the porting effort.
> 
that's for the "source incompatible changes" section.
but the "mostly source compatible" also implies that in many aspects it
is just like a regular minor version, so the "screw the changelog,
everything is totally different now anyway" mentality applied to
previous major versions just doesn't seem appropriate.

On Fri, Jan 18, 2013 at 05:23:24PM +0800, Thiago Macieira wrote:
> ChangeLog: Fixed a crash that would cause the QObject constructor to crash if 
> it was run during application shut down (that is, in global destructors).
> 
> Change-Id: I0dba895b041fe6cf81e6f8939ca85035cd00aad1
> ===
> 
> Note how it's repeating information that was already present in the commit 
> message (it's redundant), just in a different way. Also note how the change 
> log 
> is not a line, but a longer sentence.
>
yes, and the purist in me agrees. but as both kai and eskil pointed out,
this isn't so much *additional* clutter, so whatever - i kind of don't
see the change-id lines when i browse logs anyway.

an additional upside of doing this while creating the commit is that one
may be more thorough with the message and the whole commit, as one is
forced to consider it from an additional angle. so it plays in the same
league as "needlessly" insisting on commit atomicity and other "process
stuff".
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] Orgad Shaneh is maintainer of ClearCase plugin in Qt Creator now

[Tobias Hunger]

Hello everybody!

I proposed Orgad Shaneh for maintainer in November already, so everybody 
had enough time to speak up even with christmas holidays and the Qt 5 
release. I just asked Ossi to add him into the maintainers group on 
Gerrit as well as added him to the maintainers wiki page, so he is 
officially a maintainer now.

Congratulations to Orgad for his outstanding work!

He is now responsible for the ClearCase plugin to Qt Creator.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] editing jira tasks (Re: ChangeLogs)

[Oswald Buddenhagen]

On Fri, Jan 18, 2013 at 08:03:38AM +, Koehne Kai wrote:
> I consider changing the title and the text of a user's bug report by myself 
> impolite,
>
this is a bit unreasonable. a bug report is no work of art (well, most
aren't ^^). it's a tool - your tool - so hack away on the reports as you
like.
specifically, fixes of formatting and language are a no-brainer.
adjusting the summary to reflect the actual problem is often almost
mandatory.
adjusting the content of the description should be done with a little
more care, but i have no qualms about it when the original description
is useless or even misleading. in case of doubt ask the reporter to
verify your rewrite.

> asking the original reporter to [...] split things into different tasks
>
you are supposed to do that anyway. the same atomicity rules as for
commits apply.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Thiago Macieira]

On sexta-feira, 18 de janeiro de 2013 11.49.12, Oswald Buddenhagen wrote:
> yes, and the purist in me agrees. but as both kai and eskil pointed out,
> this isn't so much additional clutter, so whatever - i kind of don't
> see the change-id lines when i browse logs anyway.

The Change-Id is not redundant information. It's new information, not present 
elsewhere.

> an additional upside of doing this while creating the commit is that one
> may be more thorough with the message and the whole commit, as one is
> forced to consider it from an additional angle. so it plays in the same
> league as "needlessly" insisting on commit atomicity and other "process
> stuff".

And that leads to another downside: what if two or more commits were necessary 
to fix a bug? Then the ChangeLog line would be referring to changes that are 
not found in that commit, which could be confusing later on.

I don't buy the "be more thorough" argument. If the commit message was written 
properly, the ChangeLog line is redundant because it's rephrasing what has 
already been said before, except that it's less detailed and is written in the 
past tense (as opposed to the imperative that most people seem to prefer).

If we're going to do this, then let's agree that it must always be the 
*second* paragraph of the commit message -- that is, the first paragraph of the 
body -- and it must go with the flow.

I'd rewrite my commit message to be:


Clear the current thread data for the main thread

ChangeLog: Fixed a crash that would cause the QObject constructor to crash if 
it was run during application shut down (that is, in global destructors).

A common case of QObjects being created on shutdown are qDebug or qWarning 
calls in destructors (due to QTextStream's device close notification QObject).

==41000== Invalid read of size 4
==41000==at 0x5F01ED5: bool QBasicAtomicOps<4>::ref(int&) 
(qatomic_x86.h:208)
==41000==by 0x5F01309: QBasicAtomicInteger::ref() 
(qbasicatomic.h:147)
==41000==by 0x5F24051: QThreadData::ref() (qthread.cpp:100)
==41000==by 0x614A984: QObject::QObject(QObject*) (qobject.cpp:681)
==41000==by 0x605E562: QDeviceClosedNotifier::QDeviceClosedNotifier() 
(qtextstream.cpp:324)
==41000==by 0x6057E90: 
QTextStreamPrivate::QTextStreamPrivate(QTextStream*) (qtextstream.cpp:441)
==41000==by 0x605935D: QTextStream::QTextStream(QString*, 
QFlags) (qtextstream.cpp:1059)
==41000==by 0x5F19B4B: QDebug::Stream::Stream(QtMsgType) (in 
/home/thiago/obj/qt/qt5/qtbase/lib/libQt5Core.so.5.0.1)
==41000==  Address 0x6ee73f0 is 0 bytes inside a block of size 152 free'd
==41000==at 0x4A0736C: operator delete(void*) (vg_replace_malloc.c:480)
==41000==by 0x5F240BF: QThreadData::deref() (qthread.cpp:109)
==41000==by 0x6113F6B: QCoreApplicationData::~QCoreApplicationData() 
(qcoreapplication.cpp:268)

Change-Id: I0dba895b041fe6cf81e6f8939ca85035cd00aad1
===

Note how the change log line is a relevant part of the explanation of the 
problem, and is followed by more detail that doesn't need to be part of the 
changelog.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Sylvain Pointeau]

>
>
>
> And that leads to another downside: what if two or more commits were
> necessary
> to fix a bug? Then the ChangeLog line would be referring to changes that
> are
> not found in that commit, which could be confusing later on.
>
>
 And additionally what if you solve multiple bugs in one commit?

Normally you should indicate which bugs you are trying to solve with a
commit
And a reviewer should close the bug in the bug tracker.

Then the right way is to use the bug tracking tool to generate a change log.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Oswald Buddenhagen]

On Fri, Jan 18, 2013 at 07:49:41PM +0800, Thiago Macieira wrote:
> On sexta-feira, 18 de janeiro de 2013 11.49.12, Oswald Buddenhagen wrote:
> > yes, and the purist in me agrees. but as both kai and eskil pointed out,
> > this isn't so much additional clutter, so whatever - i kind of don't
> > see the change-id lines when i browse logs anyway.
> 
> The Change-Id is not redundant information. It's new information, not present 
> elsewhere.
> 
that wasn't the point. for the human reader, the change-id is noise most
of the time. still, it's necessary for the system. the same could be
said about the new footer, in a slightly different way.

> > an additional upside of doing this while creating the commit is that one
> > may be more thorough with the message and the whole commit, as one is
> > forced to consider it from an additional angle. so it plays in the same
> > league as "needlessly" insisting on commit atomicity and other "process
> > stuff".
> 
> And that leads to another downside: what if two or more commits were 
> necessary 
> to fix a bug? Then the ChangeLog line would be referring to changes that are 
> not found in that commit, which could be confusing later on.
> 
the actual, final bug fix should be in the last commit. if multiple
"terminal" commits refer to the same bug, i'd venture the assertion that
something is wrong with the definition of the bug (atomicity). and if the
same type of bug is fixed in multiple places, the placement of the
changelog footer is arbitrary (provided no reference to the specific
function is deemed necessary. otherwise the lines need duplication, and
can be manually merged at log generation time (the automatic log
extractor can be made clever enough to pre-group similar entries to ease
this)).

> I don't buy the "be more thorough" argument. If the commit message was 
> written 
> properly, the ChangeLog line is redundant because it's rephrasing what has 
> already been said before, except that it's less detailed and is written in 
> the 
> past tense (as opposed to the imperative that most people seem to prefer).
> 
the point is that the commit message is often *not* written properly,
because people have a too focused mindset at the time of writing (or are
just too lazy, but that's another topic ;). bringing in the additional
aspect to consider is exactly what may help addressing this problem to
some degree.
and yes, i know that *your* commit messages are (usually) already as
perfect as it gets. but let's face it: you are the exception.

> If we're going to do this, then let's agree that it must always be the 
> *second* paragraph of the commit message -- that is, the first paragraph of 
> the 
> body -- and it must go with the flow.
> 
i'd already add an exception to that: if the description is a
grammatical continuation of the summary, shift one down:


don't do foobar when bazbaking terzknolfs and some other stuff

... because otherwise frudings will crash in yHa().

ChangeLog: oh, well

you know, things happen ...


the point is that it gets arbitrarily complex, and adding more rules
won't help. of course we can endorse a particular style to reduce
redundancy, but it's technically not necessary and can be left to the
discretion of the contributor (and his reviewers).

what is much more important is that the ChangeLog entries need to be
"tagged", so they can be automatically sorted into the right categories:

ChangeLog: Core: SIC: renamed brokenName() to usefulName()

i.e., what many people do with commit message summaries (which i find
just plain annoying, because it adds noise and doesn't really solve the
problem it supposedly tries to address (the one we are discussing now)).

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Thiago Macieira]

On sexta-feira, 18 de janeiro de 2013 13.57.02, Sylvain Pointeau wrote:
> > And that leads to another downside: what if two or more commits were
> > necessary
> > to fix a bug? Then the ChangeLog line would be referring to changes that
> > are
> > not found in that commit, which could be confusing later on.
> 
>  And additionally what if you solve multiple bugs in one commit?
> 
> Normally you should indicate which bugs you are trying to solve with a
> commit
> And a reviewer should close the bug in the bug tracker.
> 
> Then the right way is to use the bug tracking tool to generate a change log.

If they are part of one single change, then it's likely we can word the 
changelog such that it explains both bug fixes.

If they are not part of the same change, then you should split in two commits 
anyway.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Thiago Macieira]

On sexta-feira, 18 de janeiro de 2013 14.03.18, Oswald Buddenhagen wrote:
> what is much more important is that the ChangeLog entries need to be
> "tagged", so they can be automatically sorted into the right categories:
> 
> ChangeLog: Core: SIC: renamed brokenName() to usefulName()
> 
> i.e., what many people do with commit message summaries (which i find
> just plain annoying, because it adds noise and doesn't really solve the
> problem it supposedly tries to address (the one we are discussing now)).

You raise another good point: how are we going to sort the changelog entries? 
We don't have the class name, module name or the major section of the file 
(Important behaviour changes, etc.)

Is this going to be a manual process?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.0.1 -- Release Testing

[Motyka Rafal]

Hello,

Qt 5.0.1 release testing has been started. We would like to kindly ask the Qt 
Community for help by testing the new packages.

  1.  Installer packages are available here: 
http://releases.qt-project.org/digia/5.0.1/backups/2013-01-18-412/

  2.  Qt bug reports should be reported in JIRA: 
https://bugreports.qt-project.org/

Thank you.

Best regards,

/Rafal




Rafal Motyka
QE Engineer
Digia, Qt



Email: rafal.mot...@digia.com
Mobile: +47 95005389
http://qt.digia.com
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qt
Qt Twitter: www.twitter.com/qtcommercial


--

PRIVACY AND CONFIDENTIALITY NOTICE

This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. Digia Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.

-

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ChangeLogs

[Oswald Buddenhagen]

On Fri, Jan 18, 2013 at 09:38:05PM +0800, Thiago Macieira wrote:
> On sexta-feira, 18 de janeiro de 2013 14.03.18, Oswald Buddenhagen wrote:
> > what is much more important is that the ChangeLog entries need to be
> > "tagged", so they can be automatically sorted into the right categories:
> > 
> > ChangeLog: Core: SIC: renamed brokenName() to usefulName()
> > 
> 
> You raise another good point: how are we going to sort the changelog entries? 
> We don't have the class name, module name or the major section of the file 
> (Important behaviour changes, etc.)
> 
i think we need a manually maintained set of valid tags, and have the
sanity bot complain about incorrect tagging. the correct set of tags can
be deduced from the structure of existing changelogs (assuming we
consider it sane).
when this is done right and used consistently, the actual generation of
the prototypical changelog can be fully automated. 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWindowsExtras

[Laszlo Papp]

On Thu, Jan 17, 2013 at 8:58 PM, Jake Thomas Petroules <
jake.petrou...@petroules.com> wrote:

> As we have a QtMacExtras and QtX11Extras, could someone please create a
> QtWindowsExtras as well?
>

Could you please elaborate about the use case?

Laszlo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWindowsExtras

[Jake Thomas Petroules]

As many OS/WM utility methods were removed from Qt 5, we need to reimplement 
their functionality in the QtWindowsExtras, QtMacExtras, and QtX11Extras 
libraries.

For example, in QtMacExtras we have a unified toolbar implementation that 
replaces setUnifiedTitleAndToolbar(), and converter functions to replace 
QPixmap::toMacCGImageRef(), QPixmap::fromMacCGImageRef() as well as other type 
conversions, etc. Morten also has some clipboard functionality pending as well 
as a utility function to set the dock menu to a QMenu, native widgets, and some 
other stuff. Similarly, QtX11Extras has QX11Info ported from Qt 4 and I imagine 
may have more functionality in the future..

Windows is no different, and there is a lot that could fit into such a library, 
including but not limited to:

* Replacements for native API converter functions (QPixmap::toWinHBITMAP(), 
QPixmap::fromWinHBITMAP(), QPixmap::toWinHICON(), QPixmap::fromWinHICON()... I 
think there was also a QMenu::wceMenu() that gave an HMENU and a similar 
function for Windows itself (not CE) would be great)
* Taskbar functionality for Windows 7/8 (jump lists, overlay icons, progress 
indicators, thumbnail toolbars, thumbnail tab previews)
* DWM interaction (enable/disable composition, extend frame into client area)

This is important functionality usable by a large number of Windows apps, 
clearly evidenced by the former presence of some of this functionality in Qt 4. 
I have a decent amount of code implementing much of this functionality already, 
just awaiting contribution...

I'm sure there is more I haven't thought of as well. Perhaps some Windows 8 
APIs?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Jan 18, 2013, at 12:16 PM, Laszlo Papp  wrote:

> On Thu, Jan 17, 2013 at 8:58 PM, Jake Thomas Petroules 
>  wrote:
> As we have a QtMacExtras and QtX11Extras, could someone please create a 
> QtWindowsExtras as well?
> 
> Could you please elaborate about the use case?
> 
> Laszlo

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development