The Qt Contributors Summit [1] is happening Berlin from 16-18 June to discuss
the future of Qt under Open Governance. Many members of the KDE community
will be there either as direct representatives of KDE or on behalf of their
employer. A rough estimate puts our presence at about 10% of the 200-250
attendees.
We would like to co-ordinate our efforts at QtCS to ensure the best possible
outcome for KDE and Qt. To help this we would like all KDE community members
attending to list their name on the KDE at QtCS wiki page [2].
Hi,
KCalendarSystem is a public class with many virtual methods which are
reimplemented in derived classes such as KCalendarSystemGregorian. The
derived classes are not exported or part of the api, only KCalendarSystem is
exposed, but the derived classes are created and returned in a static factory
method.
I'm implementing support for US week numbers, but there's conflicting
information on the great interweb tubes as to what the standard is.
Some sources say the US Standard is Week 1 is from Jan 1 to the first Saturday
of the year (which may be less than 7 days) then each following week starts
from Sunday.
Other sources say Week 1 starts on the first Sunday in the year, with the days
preceeding it being labelled either Week 0 or the last week of the previous
year.
Finally there's some suggestion the US military uses simple week numbering,
i.e.
There's been a short discussion on the GeoClue mailing list related to
resolving the issues we have around their dependencies on gconf and gsettings
and the latest response has been:
Did anything come out from discussions on feature branch naming in git? With
GSoC starting soon we'll be getting a lot of new feature branches and it would
be nice if they were consistantly named to make them easy to find and manage.
See
<a href="" title="">...</a>
for the original meeting notes.
I'd prefer to see the gsoc branches under a common prefix in the main project
repo rather than as personal branches or repos:
origin/gsoc2011/<subproject>/<branchname>
e.g.
I was wondering if we need to define a "New Dependencies" policy, or at least
some guidelines to remind people what to think about when choosing or creating
new dependencies?
Something like:
*
I'll be attending the OpenPrinting Summit [1] to discuss how to complete the
Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for
any feedback people may have about the CPD, and any questions you want me to
ask while I'm there.
The CPD is a common print dialog implementation in Qt and Gtk that gets called
via DBus. The dialog includes a preview image, more user-friendly options,
better driver integration, and settings management.