Re: FileCopyrightText...
On 29 January 2024 12:31:44 GMT, Harald Sitter wrote: > On Mon, Jan 29, 2024 at 10:49 AM Carl Schwan wrote: > > > > On Monday, January 29, 2024 10:43:04 AM CET Harald Sitter wrote: > > > do we really need it? > > > > > > systemd for example only has a spdx license header, resulting in much > > > tidier file headers. > > > > > > I entirely fail to understand why we need to slap a FileCopyrightText > > > on files. The copyright surely applies whether or not I put the > > > FileCopyrightText there. The list is also just about always > > > incomplete, further calling its use into question. Not to mention that > > > it is annoying book keeping of information that is already available > > > in git. > > > > > > Can someone shed some light on this? > > > > The reuse FAQ has an entry about why only keeping the copyright information > > in > > git is a bad idea: https://reuse.software/faq/#vcs-copyright > > Yes, that makes no sense to me. Whether I put my copyright stamp on a > file or not has no impact on whether I actually have copyright. That > is to say when someone doesn't add their stamp they would still be a > copyright holder. Which means that unless everyone who ever touched a > file puts their stamp on it, which is something we didn't and don't > enforce, the list is inherently incomplete and by extension useless > ... So, authorship data is in fact more relevant here because you get > all would-be copyright holders, not just the ones that bothered to put > their stamp on the file. No? ... Obviously the authors list may still > be incomplete but I'm willing to put money on the fact that 9/10 it is > more complete than whatever the license headers proclaim to be the > case. Although copyright only applies to non-trivial changes, so the actual set of copyright holders is likely to lie somewhere between the authors list in the headers and the full list provided from git commits. -- David Jarvie KAlarm author, KDE developer
Re: CI system maintainability
On 28 March 2019 13:33:59 GMT, laurent Montel wrote: > Le jeudi 28 mars 2019, 09:29:22 CET Kevin Ottens a écrit : > > Hello, > > > > On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > > > Please note that the commits in this instance were pushed without > > > review, so restrictions on merge requests wouldn't make a > difference > > > in this case unfortunately. > > > > Maybe it's about time to make reviews mandatory... I know it's > unpopular in > > KDE, and I advocated for "don't force a tool if you can get someone > to look > > at your screen or pair with you" in the past. Clearly this > compromise gets > > somewhat exploited and that's especially bad in the case of a > fragile and > > central component like KDE PIM. > > > > Regards. > > Hi, > > I am against to force mandatory review, as it will create a lot of > lose of > time, and we will not be sure that review is correct (see comment from > Volker > about "transaction lock regression") > > It's necessary to having a big team for doing it. > > Ok a repo was broken, but it was just that fix was created in master > not > 19.04, I didn't see nobody on IRC told us "this package is always > broken", > when I saw it this morning I just cherry pick (2 seconds for fixing > it). > > > For example I works all days on kde (pim or other) when I wake up, or > at noon > after my lunch or the evening, I will not wait several days for a > review > because nobody has time to do it. (we can see a review from zanshin > for > example https://phabricator.kde.org/D16210 we can see that David > waited 2 > months until having an answer...). > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I > don't want > to wait several days/weeks until someone wants to review my patchs) > > I will not lose my time to review some code that I don't understand... > I never > reviewed Akonadi patch as I don't understand this code, and I will > take time > on it just for the pleasure as I prefer fixing bug or adding new > features in > components that I maintain. > > When we have a big team as Qt team it can help but in pim component > where we > don't have any redundant guy, we will lose a lot of time. > > So for each increase version for each package I will wait a review. > For sure > not. > > Each time that I will improve code as coding style I will wait that > someone > wants to review... I agree. Mandatory reviews might work if there is a team of active people working on a project, but if there is only one person with real knowledge of the code, or there is nobody else with much time to spare, who is going to do the review? It is likely to just sit waiting indefinitely. If getting code reviewed is too difficult, the developer may have to give up and abandon the project. Mandatory reviewing could only work if individual projects can decide whether to adopt it or not. -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: Review Request 127629: Fix KDateTime::isValid() for ClockTime values
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127629/ --- (Updated May 5, 2016, 10:17 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Changes --- Submitted with commit af320ed5599cb0737c0601e26126c39e64780de0 by David Jarvie to branch master. Bugs: 336738 https://bugs.kde.org/show_bug.cgi?id=336738 Repository: kdelibs4support Description --- KDateTime::isValid() wrongly returns invalid for an instance which is specified in ClockTime, if the date/time is invalid in the local time zone. This is due to the internal QDateTime value being set to Qt::LocalTime, and unlike in Qt4, QDateTime in Qt5 uses the local time zone to validate the date/time. For ClockTime, there is no associated time zone (and choosing the local time zone to perform validation is purely arbitrary), so it should ignore the local time zone when validating. Diffs - autotests/kdatetimetest.cpp a8e7749 src/kdecore/kdatetime.cpp c530db1 Diff: https://git.reviewboard.kde.org/r/127629/diff/ Testing --- Test added to kdatetimetest, all tests pass. Thanks, David Jarvie
Re: Review Request 127629: Fix KDateTime::isValid() for ClockTime values
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127629/#review95193 --- Can I commit this? - David Jarvie On April 10, 2016, 6:43 p.m., David Jarvie wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127629/ > --- > > (Updated April 10, 2016, 6:43 p.m.) > > > Review request for kdelibs. > > > Bugs: 336738 > https://bugs.kde.org/show_bug.cgi?id=336738 > > > Repository: kdelibs4support > > > Description > --- > > KDateTime::isValid() wrongly returns invalid for an instance which is > specified in ClockTime, if the date/time is invalid in the local time zone. > This is due to the internal QDateTime value being set to Qt::LocalTime, and > unlike in Qt4, QDateTime in Qt5 uses the local time zone to validate the > date/time. For ClockTime, there is no associated time zone (and choosing the > local time zone to perform validation is purely arbitrary), so it should > ignore the local time zone when validating. > > > Diffs > - > > autotests/kdatetimetest.cpp a8e7749 > src/kdecore/kdatetime.cpp c530db1 > > Diff: https://git.reviewboard.kde.org/r/127629/diff/ > > > Testing > --- > > Test added to kdatetimetest, all tests pass. > > > Thanks, > > David Jarvie > >
Review Request 127629: Fix KDateTime::isValid() for ClockTime values
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127629/ --- Review request for kdelibs. Bugs: 336738 https://bugs.kde.org/show_bug.cgi?id=336738 Repository: kdelibs4support Description --- KDateTime::isValid() wrongly returns invalid for an instance which is specified in ClockTime, if the date/time is invalid in the local time zone. This is due to the internal QDateTime value being set to Qt::LocalTime, and unlike in Qt4, QDateTime in Qt5 uses the local time zone to validate the date/time. For ClockTime, there is no associated time zone (and choosing the local time zone to perform validation is purely arbitrary), so it should ignore the local time zone when validating. Diffs - autotests/kdatetimetest.cpp a8e7749 src/kdecore/kdatetime.cpp c530db1 Diff: https://git.reviewboard.kde.org/r/127629/diff/ Testing --- Test added to kdatetimetest, all tests pass. Thanks, David Jarvie
Re: Replacement for KDateTime
On Mon, August 10, 2015 11:31 am, DÄvis MosÄns wrote: 2015-08-10 11:34 GMT+03:00 John Layt j...@layt.net: On 9 August 2015 at 17:26, DÄvis MosÄns davis...@gmail.com wrote: When I implement date/time related things I always use timestamps in UTC everywhere and when need to display to user or pass to some API then convert to respective format and timezone. Any other way makes it only more complicated. That works well when recording the time something occurred at, i.e. in the past, but it just doesn't work for events scheduled in the future when the time zone rules could change for both the source of the event and in any observers location. For example, if I'm in UTC+2 and I schedule a meeting every Monday at 10am for the next 2 years, and the government changes the time zone rule from UTC+2 to UTC+3, if I stored the event time in UTC then my meeting has suddenly changed from 10am to 11am! If someone in the New York office phones in to the meeting, and their time zone rules change relative to UTC then they also get the wrong time. The only workable solution is to store the event in local time zone for the event location (unless they explicitly want UTC), and then convert it to the destination time zone at the last possible moment. Indeed, I hadn't thought about this. Basically there's 2 types of time, one is distinct fixed time point (I've worked only with these) and other is human time which doesn't really represent a distinct time because it might change relative to UTC. So if I set event to see solar eclipse I need to set it in UTC as otherwise it will be wrong when timezone or DST changes. But for meetings and other similar things need it in human time as it doesn't matter that current 10am actually isn't that that same 10am when it was set. Also thinking about this I realized that for human time you don't need timezone but actually a place, location. Because as you said timezone can change and it only depends on location. So to convert time between different locations you need to get current timezones for both locations. Timezone when event was set is useless because it might have changed by now. So basically need to store time in either UTC or with human time and location. Also location should be as precise as possible because theoretically country can split and each part change to different timezone. I think you misunderstand what is meant by time zone as defined by iCalendar and as it is used in the other mails in this thread. It means the set of offsets from UTC used officially in a country or region and when they apply, and how this changes over the years. In many locations, the time zone therefore defines UTC offsets for summer and winter and the dates and times in each year when the transitions between winter and summer time take place. I.e. a time zone is essentially what you refer to as human time. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote: 2015-08-03 15:26 GMT+03:00 David Jarvie djar...@kde.org: On Monday 03 Aug 2015 12:59:59 you wrote: 2015-08-02 21:32 GMT+03:00 David Jarvie djar...@kde.org: Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Sorry for injecting myself, but IMO there's no such thing as Date-only and what you need is something like QDateTimeRange (just made up) where you would have start QDateTime, end QDateTime and it could represent any Event/Interval. Like whole day, part of day or even multiple days. And could also check whether some QDateTime is inside this range. Date-only extends the current QDateTime concept to allow it to represent a single date (which is intrinsically a time range) or a single date-time, without requiring any extra date-time information to be stored - only a boolean flag is required to indicate whether the time component should be ignored. A generalised time range on the other hand requires storing distinct start and end times, and cannot (except for special cases) be represented by a single date or date-time. That sounds like kind of a hack... trying to save few bytes for very minimal use case. As soon as you'll need to represent something outside of that you'll need a proper range. Besides can implement range with QDateTime + qint64 My point is that a QDateTime already contains both a date and a date-time. A date-only option provides the option to select one or the other. QDateTime does not contain a range, so a time range is something different (except for the special case of a single date). Adding a flag to select data which is already there is IMHO different in scope from adding extra data (either another QDateTime or a qint64). -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Monday 03 Aug 2015 18:22:28 you wrote: 2015-08-03 17:33 GMT+03:00 David Jarvie djar...@kde.org: On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote: 2015-08-03 15:26 GMT+03:00 David Jarvie djar...@kde.org: On Monday 03 Aug 2015 12:59:59 you wrote: 2015-08-02 21:32 GMT+03:00 David Jarvie djar...@kde.org: Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Sorry for injecting myself, but IMO there's no such thing as Date-only and what you need is something like QDateTimeRange (just made up) where you would have start QDateTime, end QDateTime and it could represent any Event/Interval. Like whole day, part of day or even multiple days. And could also check whether some QDateTime is inside this range. Date-only extends the current QDateTime concept to allow it to represent a single date (which is intrinsically a time range) or a single date-time, without requiring any extra date-time information to be stored - only a boolean flag is required to indicate whether the time component should be ignored. A generalised time range on the other hand requires storing distinct start and end times, and cannot (except for special cases) be represented by a single date or date-time. That sounds like kind of a hack... trying to save few bytes for very minimal use case. As soon as you'll need to represent something outside of that you'll need a proper range. Besides can implement range with QDateTime + qint64 My point is that a QDateTime already contains both a date and a date-time. A date-only option provides the option to select one or the other. QDateTime does not contain a range, so a time range is something different (except for the special case of a single date). Adding a flag to select data which is already there is IMHO different in scope from adding extra data (either another QDateTime or a qint64). Ok, I don't really understand what's your use case and so I don't see why you would need that. There's QDate and QTime, you can use QDateTime::date() to extract QDate and for other cases you really do need a range. Sounds like you want QDateOrTime (also made up), but I think very few applications would use something like. And IMO that's bad design, because cleaner code would be with method overloads which take either QDate or QTime. There are a number of cases in kdepim where a date-time or a date can be supplied. Using KDateTime makes the code cleaner - there is no need to provide overloads or to track whether it's date-only when calling multiple layers of functions or classes, because the KDateTime value provides that information. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Monday 03 Aug 2015 19:49:52 Thomas Lübking wrote:
On Sonntag, 2. August 2015 20:32:43 CEST, David Jarvie wrote:
Having a date-only attribute in KDateTime is very useful
because it allows both date-time and date-only values to be
encapsulated in a single class. This avoids having to be able to
pass either a QDate or QDateTime or to have a separate flag
everywhere this is used, and it allows date-time values to be
compared to date-only values using class methods.
Sorry, but I don't follow here.
QDateTime *has* a QDate AND a QTime member.
They can independently be null/invalid.
= With a QDateTime with invalid QTime member, you *have* a QDate-only
QDateTime, agreed?
The problem would be that
if (kdt.isValid()) {
if (kdt.isDateOnly())
foo();
else
bar();
}
turns into:
if (qdt.date().isValid()) {
if (!qdt.time().isValid())
foo();
else
bar();
}
right?
Doesn't look that horrible.
-
Now, it however seems to me you'd like to have a flag butIgnoreTheTime that
hints for some client code behavior, ie. you actually want to carry valid
date and time in the object, but in addition have a flag _in_the_object_ to
effectively pass a parameter to a function to do something different with
this object.
Is this actually correct?
= That frankly sounds like a bool trap on steroids.
You've an object flying around that may or not have set this flag for some™
ominous reason in the past for some™ function call and different modules
might have different requirements for this flag for different reasons...
e.
As I understand it, a QDateTime is invalid if either the date or time component
is invalid. People would usually expect that if QDateTime::isValid() returns
false, the object must be invalid. So a date-only value in which only the date
was valid would make the whole object invalid, which is misleading and would
almost certainly lead to mistakes.
--
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Monday 03 Aug 2015 12:59:59 you wrote: 2015-08-02 21:32 GMT+03:00 David Jarvie djar...@kde.org: Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Sorry for injecting myself, but IMO there's no such thing as Date-only and what you need is something like QDateTimeRange (just made up) where you would have start QDateTime, end QDateTime and it could represent any Event/Interval. Like whole day, part of day or even multiple days. And could also check whether some QDateTime is inside this range. Date-only extends the current QDateTime concept to allow it to represent a single date (which is intrinsically a time range) or a single date-time, without requiring any extra date-time information to be stored - only a boolean flag is required to indicate whether the time component should be ignored. A generalised time range on the other hand requires storing distinct start and end times, and cannot (except for special cases) be represented by a single date or date-time. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Sunday 02 Aug 2015 14:26:18 John Layt wrote: On 1 August 2015 at 19:47, Sandro Knauß b...@sandroknauss.de wrote: * dateOnly support is used a lot. In ICAL it differs if you set dateonly or datetime. dateonly events f.ex. lasts a day without timezone info f.ex. New Year is a dateonly event that lasts one day - it everywhere startsat 1. january at 0:00 o'clock and ends at 24:00 o'clock in your current timezome. So it a different UTC time for every place at the world. That's why you can't replace it with a datetime event, that needs a timezone, so it would be wrongly displayed at other timezones. I've been over this before on the PIM list, it's a fundamental mistake to say that 'Date Only' is an attribute of the datetime, it is in fact an attribute of the Event itself, and indeed is in the current API as such. I fail to see why it needs to be in the datetime as well? If there is anywhere using the datetime property instead of the Event property it is doing it wrong, make it check the Event instead. Do not put it back in the datetime. Use the datetime to represent the valid start time or endtime of the all day event, i.e. 00:00 in the time zone of the datetime on which the event starts or finishes. Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Having a date-only attribute in KDateTime is very useful because it allows both date-time and date-only values to be encapsulated in a single class. This avoids having to be able to pass either a QDate or QDateTime or to have a separate flag everywhere this is used, and it allows date-time values to be compared to date-only values using class methods. Without this encapsulation, it would make a significant amount of code more cumbersome. KAlarm for one will certainly need the equivalent of KDateTime even if it has to have its own class, but given its use in kcalcore I think it should be available in a library. Also, do you know that date-only is NOT used elsewhere (apart from kcalcore and KAlarm)? In order to use QDateTime in the representation of date-time or date-only values, the best solution in my opinion would be to have a new date time class which contains a QDateTime member together with a bool member indicating whether it is date-only. For a date-only value, the time component of the QDateTime should be set to 00:00:00, to avoid the problem of what an invalid value indicates. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: KDE Applications Versioning
On Mon, June 8, 2015 11:32 pm, Aleix Pol wrote: On Mon, Jun 8, 2015 at 8:25 PM, Christoph Cullmann cullm...@absint.com wrote: Hi, for frameworks, it is all very nice and automatic, the version in the CMakeLists.txt get auto-updated on each KF 5.x release. It seems to me, for the applications collection, something similar might make sense. E.g. I missed to ever update the Kate version since 5.0 and other applications like Dolphin and Konsole seem to have similar problems. Would it make sense to have some we auto-define some version CMake var to KDE Application release number? For e.g. bug reports that would make all things easier. Or do I miss some magic already in place (e.g. the opensuse packages seems to have patched release numbers, at least for Konsole). Greetings Christoph I'd welcome such feature. I always forget to update my applications' version. Maybe it would be best to ask the release-t...@kde.org? There has been debate about this for frameworks, and there is an argument there (not agreed by everybody) for making all frameworks have the same version, since framework libraries are dependencies for other software. The same arguments don't apply to applications, which in general are not dependencies. Other than convenience for maintainers who forget to update version numbers, I can see no good reason for forcing applications to have a uniform version number. I prefer using the version number to reflect the development status of the application (by use of major, minor and patch version numbers), as in the past. This makes it easier when dealing with bug reports, to know the state of the program at the version in question. For maintainers who want to use some other scheme, that's also fine. The important thing is to leave the choice. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Alternative to QDateTime::isDateOnly ?
On Tue, April 28, 2015 9:32 pm, Christian Mollekopf wrote: On Tue, Apr 28, 2015, at 08:47 PM, John Layt wrote: On 27 April 2015 at 21:17, Christian Mollekopf chrig...@fastmail.fm wrote: Using a QDate in the api is probably not an option for PIM though as it doesn't have a QTimeZone attached which you will certainly always need (and yes, that is a reason for doing it in QDateTime). We don't need a timezone for date-only (AFAIR), but we do need date-time sometimes. There *is* a valid reason for having a time zone for date-only values - it is then possible to determine whether a date-time value falls within that date-only value. For example, 2015-02-27T00:30 in an Australian time zone is during 2015-02-26 for a European time zone; it is earlier than 2015-02-27 in a European time zone. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Another proposal for modernization of our infrastructure
On Sat, January 31, 2015 8:25 pm, Boudewijn Rempt wrote: On Sat, 31 Jan 2015, Christoph Feck wrote: On Saturday 31 January 2015 20:07:42 Eike Hein wrote: [...] Qt is using gerrit and we intend to remain a major stakeholde in Qt development, which means a sizable number of KDE developers need to be familiar with gerrit anyway [...] Excuse me, but if KDE developers will have to follow equivalent steps as described at http://qt-project.org/wiki/Setting-up-Gerrit to contribute, then I predict another big loss of developers. Christoph Feck (kdepepo) Maybe quite a few KDE developers would want to contribute to Qt, and maybe Qt would like more contributors, but KDE is so much bigger -- I'd like to see some numbers, but I seriously doubt that the majority of KDE developers are potential Qt developers. Even if we have to work around Qt bugs quite often. In any case, if Qt wants more contributors out of the KDE developer pool, they'd better ease up their submission process and drop using gerrit. I know that I, and I've been a KDE developer for over a decade, won't do anything for Qt in my spare time as long as they have this gerrit-based workflow. If people are paying me for it, well, that's different, but no way am I going to submit to that process for fun and for for free. In short, Qt uses gerrit is a bogus argument in favor of gerrit. And I am pretty sure that if gerrit becomes a requirement for working on KDE projects, KDE will not just lose a lot of developers, it will lose a lot of projects. +1 I occasionally contributed patches in the past to Qt, but since the current gerrit setup was introduced I've never even contemplated doing so because it looks too much effort to get to grips with. It's far too off-putting for occasional contributors. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: kdepimlibs Coverity Scan Report, Oct 14 2014
On Thu, October 16, 2014 2:06 pm, Gilles Caulier wrote: 2014-10-16 12:29 GMT+02:00 Ben Cooksley bcooks...@kde.org: On Thu, Oct 16, 2014 at 8:53 PM, Gilles Caulier caulier.gil...@gmail.com wrote: Allen, Hi Gilles, Just a workflow question : why to export Coverity report to CSV where you can send automatically a mail to devel mailing list when scan is complete, with a a list of new defect found in code. I use Coverity since more than one year with whole digiKam code, and we have already fixed more than 500 entries detected. The Coverity web interface is really more suitable than a export to CSV. Defect are very well explained in source context, with all conditions used to check implementation. The only constrain is to have an account for each contributors who will fixed entries. I suspect that is why Allen is sending out the HTML/CSV output - because not everyone has access and it is helpful to have this information publicly accessible. All is configurable in Coverity interface. You can invite people and attribute role. Web interface is so far more powerful to use than CSV, and permit a time gain to fix issues. The CSV version doesn't contain line numbers, so it's impossible to know what code some of the issues refer to. I seem to remember that the web interface doesn't have that problem. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: kdecore-ktimezonestest broken
On Tue, June 3, 2014 11:31 pm, Albert Astals Cid wrote: El Dimecres, 4 de juny de 2014, a les 00:27:45, Albert Astals Cid va escriure: Hi, David, this commit to kdelibs http://build.kde.org/view/KDE%20SC%20stable/job/kdelibs_stable/1089/changes broke the ktimezonetests http://build.kde.org/view/KDE%20SC%20stable/job/kdelibs_stable/1089/ Can you please fix them urgently before Thursday. Otherwise we'll either have to delay the release or revert your fix. I'm pretty sure that commit is also the culprit for this failure in testicaltimezones in kdepimlibs http://build.kde.org/view/KDE%20SC%20stable/job/kdepimlibs_stable/888/testReport/ Hi Albert, The commit didn't break ktimezonetests - its fail was already present before the commit. I'll be investigating the testicaltimezones fail tonight and hope to get it fixed. If I have time, I'll try looking at the ktimezonetests fail too, although it seems a relatively unimportant issue. Cheers, David. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated April 16, 2014, 8:25 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated April 14, 2014, 11:48 a.m.) Review request for kdelibs. Changes --- Fix indentation. Note to self: when working on systems with different editor settings, check whitespace settings ;) Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs (updated) - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated April 13, 2014, 10:41 p.m.) Review request for kdelibs. Changes --- Always output error in debug message. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs (updated) - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: KF5: Parsing times with timezone abbreviations
On Mon, March 31, 2014 11:53 am, Kevin Kofler wrote: Thiago Macieira wrote: Time zone abbreviations are useless, since they are not unique. Simply strip them out of your string before passing to QDateTime. Nice theory, but there is no other way to know what time this actually is. Unless you can offer a mapping from latitude and longitude to timezone, or a way to automatically figure it out from place name, country (which is especially fun for those countries that span multiple time zones, because the place name can be a small town somewhere). I do see the problem, e.g. I get EST as the timezone for Sydney, Australia, which is obviously not the same as the US EST. I suppose KDateTime will do the wrong thing for that. :-( Maybe we need a (timezone abbreviation, country) â timezone map (and an API where I can just feed in the time including the abbreviation and the country name and get a correct QDateTime; heck, for most countries, the abbreviation could be ignored entirely, it only matters for huge countries such as the USA or Russia)? They can't just be ignored for small countries, since they may contain a daylight savings time indication. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated March 21, 2014, 2:39 p.m.) Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs (updated) - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated March 21, 2014, 3:10 p.m.) Review request for kdelibs. Changes --- Fix null pointer access. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs (updated) - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116784: Fix incorrect use of KDateTime.toTime_t in kio_http
On March 13, 2014, 5:30 p.m., David Jarvie wrote: The handling of return values from KDateTime::toTime_t() in the existing kio_http code is not correct, because the return value's type is implicitly cast to other types before being checked. For example, in one place it is cast to qint64, which will result in a value of 0x instead of 0x (= -1). This type of error will mask the fact that the error value is being returned. Instead of changing the calling code to detect invalid dates using other methods, it should be fixed to properly cast the uint value returned from KDateTime::toTime_t(). For types other than int, it needs to specifically check for uint(-1) and set the cast value to -1 in that case. For example: uint t = KDateTime::toTime_t(...); // Set the qint64 to be -1 if an error occurred: qint64 result = (t == uint(-1)) ? -1 : t; Note: KDateTime::toTime_t() is *supposed* to return uint(-1) to indicate an error. If it doesn't always do this, *it* should be fixed instead of changing code elsewhere, since kio_http is unlikely to be the only module that will have trouble if that is happening. Dawit Alemayehu wrote: Perhaps it was not clear from the description, but I am not implying nor have I implied there to be a bug in KDateTime. As I have clearly stated the problem is with the assumption the code in kio_http makes about what KDateTime::toTime_t returns for an invalid date. No matter how you see it the toTime_t() function can not and does not return a literal -1, which is exactly what the code in kio_http assumes! Of course that is clearly wrong. Anyhow, this patch is specifically intended to fix that issue and nothing else. Ok, I misinterpreted the description. The KDateTime aspects of the patch look ok apart from one issue mentioned in my detailed comment below. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/#review52897 --- On March 13, 2014, 12:49 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/ --- (Updated March 13, 2014, 12:49 p.m.) Review request for kdelibs, Andreas Hartmetz and David Faure. Repository: kdelibs Description --- The attached patch does the following: - It corrects a mistake in assumption that KDateTime.toTime_t() will return -1 for invalidate dates. It does not. The result is an overflow which is interpreted in kio_http as a timestamp in the distant future which obviously is wrong. See https://bugs.kde.org/show_bug.cgi?id=331774 for example. This assumption also affects the timestamp variables used for cache management. - It converts cache management timestamp variables to 64 bits so they can accomodates dates beyond Feb 7, 2106. Diffs - kioslave/http/http.h dd85622 kioslave/http/http.cpp e4f1eba Diff: https://git.reviewboard.kde.org/r/116784/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 116784: Fix incorrect use of KDateTime.toTime_t in kio_http
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/#review52940 --- kioslave/http/http.cpp https://git.reviewboard.kde.org/r/116784/#comment37258 Need to convert to UTC first, since it will produce the wrong value if it's in some random time zone: dt.toUtc().dateTime() - David Jarvie On March 13, 2014, 12:49 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/ --- (Updated March 13, 2014, 12:49 p.m.) Review request for kdelibs, Andreas Hartmetz and David Faure. Repository: kdelibs Description --- The attached patch does the following: - It corrects a mistake in assumption that KDateTime.toTime_t() will return -1 for invalidate dates. It does not. The result is an overflow which is interpreted in kio_http as a timestamp in the distant future which obviously is wrong. See https://bugs.kde.org/show_bug.cgi?id=331774 for example. This assumption also affects the timestamp variables used for cache management. - It converts cache management timestamp variables to 64 bits so they can accomodates dates beyond Feb 7, 2106. Diffs - kioslave/http/http.h dd85622 kioslave/http/http.cpp e4f1eba Diff: https://git.reviewboard.kde.org/r/116784/diff/ Testing --- Thanks, Dawit Alemayehu
Re: Review Request 116784: Fix incorrect use of KDateTime.toTime_t in kio_http
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/#review52897 --- The handling of return values from KDateTime::toTime_t() in the existing kio_http code is not correct, because the return value's type is implicitly cast to other types before being checked. For example, in one place it is cast to qint64, which will result in a value of 0x instead of 0x (= -1). This type of error will mask the fact that the error value is being returned. Instead of changing the calling code to detect invalid dates using other methods, it should be fixed to properly cast the uint value returned from KDateTime::toTime_t(). For types other than int, it needs to specifically check for uint(-1) and set the cast value to -1 in that case. For example: uint t = KDateTime::toTime_t(...); // Set the qint64 to be -1 if an error occurred: qint64 result = (t == uint(-1)) ? -1 : t; Note: KDateTime::toTime_t() is *supposed* to return uint(-1) to indicate an error. If it doesn't always do this, *it* should be fixed instead of changing code elsewhere, since kio_http is unlikely to be the only module that will have trouble if that is happening. - David Jarvie On March 13, 2014, 12:49 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116784/ --- (Updated March 13, 2014, 12:49 p.m.) Review request for kdelibs, Andreas Hartmetz and David Faure. Repository: kdelibs Description --- The attached patch does the following: - It corrects a mistake in assumption that KDateTime.toTime_t() will return -1 for invalidate dates. It does not. The result is an overflow which is interpreted in kio_http as a timestamp in the distant future which obviously is wrong. See https://bugs.kde.org/show_bug.cgi?id=331774 for example. This assumption also affects the timestamp variables used for cache management. - It converts cache management timestamp variables to 64 bits so they can accomodates dates beyond Feb 7, 2106. Diffs - kioslave/http/http.h dd85622 kioslave/http/http.cpp e4f1eba Diff: https://git.reviewboard.kde.org/r/116784/diff/ Testing --- Thanks, Dawit Alemayehu
Re: KDE/4.11 branched what to do with kde-workspace?
On Monday 15 Jul 2013 09:46:49 Aaron J. Seigo wrote: On Friday, July 12, 2013 17:48:50 David Jarvie wrote: best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. So how can we make that clearer for people and hard for this sort of mistake to be made? Here’s a possible idea: we could make the build fail (along with a relevant message on console) unless a specific env var or a cmake option is passed. If it doesn’t build, you probably won’t end up using it, and hopefullya build failure gets noticed. I think that would answer my concerns. As long as there is clarity (e.g. through the build failing), it doesn't matter too much if a 'non-standard' branch is used instead of master. Best would be to display an explicit message when the build fails, saying that the KDE/4.11 (or whatever) branch is the correct one to use. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: KDE/4.11 branched what to do with kde-workspace?
On Fri, July 12, 2013 4:42 pm, Aaron J. Seigo wrote: * there were 2 main reasons the branched-kdelibs shifted back to master- kdelibis: * people were too stubborn and too (willfully) uninformed to understand why this was a useful thing and just kept pelting it with stop energy at every possible opportunity. That's unnecessarily negative - why do you think that people would willfully remain uninformed? Much more likely is that they would be innocently uninformed due to not having seen announcements. Even for people who saw the announcements, it's still all too easy (even with the best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. On Fri, July 12, 2013 5:08 pm, Michael Jansen wrote: On Friday, July 12, 2013 05:52:02 PM Aaron J. Seigo wrote: On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i'd like to see is a definitive listing of all the places that this should be announced and in what form. since i've gotten this wrong enough times in the past, i'd appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i've tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i'm happy to oblige and make sure all the suggested bases are covered. I personally think there is no combination that will ever work. We have to many part time developers and people with limited resources. And all channels we currently use have to many content so its impossible to catch up after being away for some bigger time. Both Mailing lists and planet kde i mean. I guess we need a dedicated channel for these announcements. Either a smaller blog aggregator / dedicated blog or use a dedicated mailing list for that stuff. But i fear it will never be enough. There are to many people involved that don't know all processes we agree upon. I am quite sure the core devs will do it mostly right. That's why i would prefer convention over announcement. Don't break the expectations of your users. Don't go away from processes that people learned to take for granted unless there is a VERY good reason. Especially if nothing breaks for those thinking the old process is still valid. Example given: Build-tool failed to follow the repository switch of amarok (it was announced. i missed it because of being very busy) and continued to build the old stuff for months without problems. I agree. I'm sure that this must have caught out innocent people more often than willful miscreants. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: KDE/4.11 branched what to do with kde-workspace?
On Wed, July 10, 2013 1:19 pm, Martin Graesslin wrote: On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. For those who don't use kdesrc-build, knowing which branch to use does matter. kdesrc-buildrc and blogging are fine, but there needs to be an simple way later on to know which branch to use, without having to search through config files which you don't have a copy of, or past blogs. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Review Request 108727: ktimezoned: Watch /etc/localtime if it doesn't exist yet.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108727/#review27845 --- Ship it! I'm sorry this has taken so long - I've been incredibly busy recently. The patch looks fine. The only thing which occurs to me is to wonder whether the same scenario could happen with /etc/timezone (used by BSD) - if so, that file's creation should really be checked for as well as /etc/localtime. Without knowing whether that is actually possible, I think it might be worth adding the following comment where the patch sets mLocalIdFile: If under BSD it is possible for /etc/localtime to be missing but created later, we should also watch for its creation. - David Jarvie On Feb. 3, 2013, 4:30 a.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108727/ --- (Updated Feb. 3, 2013, 4:30 a.m.) Review request for KDE Runtime and David Jarvie. Description --- /etc/localtime legitimately might not exist. The default is then UTC. But the file can then be created later, so watch for its creation. If we don't do this, when setting the time zone for the first time using kcm_clock, the initially set time zone will fail to get reloaded and the dialog will unexpectedly jump back to UTC. This problem shows up on Fedora 18, see: https://bugzilla.redhat.com/show_bug.cgi?id=906972 Please note that to test the fix with kcm_clock, you also need the kcm_clock (kde-workspace) fix from: https://git.reviewboard.kde.org/r/108711/ (which is already approved and which I'll push to KDE/4.10 and merge to master as soon as the 4.10.0 tagging freeze is lifted). Diffs - ktimezoned/ktimezoned.cpp 4eafa4e Diff: http://git.reviewboard.kde.org/r/108727/diff/ Testing --- Builds against at least 4.10.0 and 4.9.5. Works at runtime (and appears to fix the bug): https://bugzilla.redhat.com/show_bug.cgi?id=906972#c5 Thanks, Kevin Kofler
Re: What is the git workflow for kdelibs ?
On Tue, October 30, 2012 11:16 am, David Faure wrote: On Sunday 28 October 2012 09:16:56 Alexander Neundorf wrote: Ok, thanks. Is this documented somewhere ? No (I described it in an email some time ago, but it's not on any wiki) If you have an idea for where we could document it, I will then push other module maintainers to also write up the git workflow they want to see, since I myself have the same question in other modules. I think community.kde.org would be the right place (it's internal, it doesn't affect KDE app devels outside of git.kde.org), but all I can see about git is http://community.kde.org/Sysadmin/GitKdeOrgManual which is more about the technical setup. Maybe start a new webpage at the toplevel of community.kde.org? GitWorkflowForEachModule? :-) Wouldn't techbase be more appropriate? It's technical information, plus techbase is where other policies are kept. I must say that the split between community.kde.org and techbase.kde.org isn't very satisfactory because the boundaries are blurred, and it's easy to miss information if it's in the other one from what you expect it to be in. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: [PATCH] kdecore: Fix a bug in KDateTime utc offset string parsing.
On Sunday 07 October 2012 21:23:56 Jon Severinsson wrote: The sign of the UTC offset was ignored, and an offset of -0500 (New York) would be treated at +0500 (Pakistan). This commit also adds a unit test for UTC offset parsing and comparasion. --- Hi When mucking around in the frameworks branch of kdelibs I found a bug in the KDateTime string parsing, which appears to be present in master as well as every branch from 4.0 to 4.10. I have, however, only run the updated unittest using the frameworks branch and Qt5, so someone else should probably test on 4.9, 4.10 and/or master before committing it. Best Regards Jon Severinsson kdecore/date/kdatetime.cpp |2 +- kdecore/tests/kdatetimetest.cpp |7 +++ 2 filer ändrade, 8 tillägg(+), 1 borttagning(-) diff --git a/kdecore/date/kdatetime.cpp b/kdecore/date/kdatetime.cpp index d4f63ff..df1fc3d 100644 --- a/kdecore/date/kdatetime.cpp +++ b/kdecore/date/kdatetime.cpp @@ -2962,7 +2962,7 @@ bool getUTCOffset(const QString string, int offset, bool colon, int result) tzmin += tzhour * 60; if (result != NO_NUMBERresult != tzmin) return false; -result = tzmin; +result = sign * tzmin; return true; } diff --git a/kdecore/tests/kdatetimetest.cpp b/kdecore/tests/kdatetimetest.cpp index e79e9f2..812abc5 100644 --- a/kdecore/tests/kdatetimetest.cpp +++ b/kdecore/tests/kdatetimetest.cpp @@ -3807,6 +3807,13 @@ void KDateTimeTest::strings_format() QVERIFY(!dt.isValid());// too early QVERIFY(dt.outOfRange()); +dtutc = KDateTime::fromString(QLatin1String(2000-01-01T00:00:00.000+), QLatin1String(%Y-%m-%dT%H:%M%:S%:s%z)); +QVERIFY(dtutc.isValid()); +dt = KDateTime::fromString(QLatin1String(2000-01-01T05:00:00.000+0500), QLatin1String(%Y-%m-%dT%H:%M%:S%:s%z)); +QVERIFY(dt.isValid()); +QVERIFY(dtutc == dt); +dt = KDateTime::fromString(QLatin1String(1999-12-31T20:30:00.000-0330), QLatin1String(%Y-%m-%dT%H:%M%:S%:s%z)); +QVERIFY(dtutc == dt); // Restore the original local time zone if (originalZone.isEmpty()) The patches look good to commit. However, can you please move the new tests in kdatetimetest.cpp to start at line 3740, before the existing group of tests for UTC offsets. This will keep related tests grouped together. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: kde-baseapps dependency on kdelibs changed in 4.9 branch?
On Tue, September 11, 2012 4:33 pm, Andreas Pakulat wrote: Hi, On Tue, Sep 11, 2012 at 4:42 PM, Dawit A ada...@kde.org wrote: On Tue, Sep 11, 2012 at 10:08 AM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 11 de setembre de 2012, a les 09:51:22, Dawit A va escriure: On Tue, Sep 11, 2012 at 6:27 AM, Albert Astals Cid aa...@kde.org wrote: It seems that the set(KDE_MIN_VERSION 4.7.97) Was that done intentionally or was it forgotten to be updated for the KDE 4.9 release ? If the former, then have we now started guaranteeing forward compatibility too ? It was done on purpose. Why require newer kdelibs when you don't need them. Because you really don't know that you need them until you actually do ? Like I said bug fixes and regressions sometimes require changes in kdelibs. If we purposefully shackle ourselves to forward compatibility then such bugs and regressions, no matter how bad, cannot be fixed until the next major release. If that is acceptable for the sake of being forward compatible, then that is fine. However, I really do not see the point of it. Why would anyone want to use new version of applications with the older version of the required libraries ? Because upgrading libs is not always easily possible. Thats not so much an issue with kde-baseapps since those are really basic things and probably only few people build those without also building kdelibs. For any other apps people might be using binary packages for the base stuff which are one or even two releases behind current stable and they'd still like to work on apps from master. And I think its important to support these people if possible. So keeping backwards compatibility. Also this is not about being forward compatible, but having apps be backwards compatible with older kdelibs. Forward compatibility of kdelibs is mostly given anyway due to the promises of keeping BC and SC of existing API and only adding (and hopefully also keeping existing behaviour). If someone runs with an older version of kdelibs, they should realise that that version may contain some bugs which are fixed in later versions. So if they build an up-to-date application against that kdelibs, it's at their own risk to some degree. But if it helps some developers to do their work, it is surely a good thing to provide (via #ifdef or whatever) backwards compatibility to applications. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Compiler version
On Monday 02 July 2012 09:09:53 Ivan Cukic wrote: Debian Stable (Squeeze) is also 4.5 by default. Debian Stable (Squeeze) is 4.4.5 by default, with GCC 4.3.5 being provided too. Yes, that is the reason I excluded Debian from the distros to watch in this case. Debian stable will not ship 4.10 in any form, and from my experience, people who use debian on the desktop, and care about having latest kde packages, use testing or sid. (myself included) Not in all cases - I use Debian stable (although I'll probably update to testing quite soon). -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Proposed adjustments to our release cycles
On Mon, June 18, 2012 5:36 am, Martin Gräßlin wrote: On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote: My concerns: * Uncertainity on the current release state. We have people that don't know the current state of the release and commit new features or new strings when we are frozen, and that's with just one release schedule, i can imagine the mess with N different release schedules Always summer in trunk. As long as releases are not created from the master branch it should be fine. On the other hand nobody should commit without a review anyway, so just commit and push without proper communication with the core developer group is so wrong in the first place This may apply to large projects, but KDE contains many smaller applications which don't have large teams - they may only have one or two people - able to independently review commits. New features always carry extra risk of bugs and side effects, even if they are carefully reviewed and tested. If we did feature releases more often, it's difficult to believe that for many KDE components it wouldn't result in a less stable state on average. The current 6 months release cycle seems a sensible stabilisation period for released software. More frequent releases run the danger of upsetting users more, which is something we don't need. * The difficulty of coding for N releases. Since the releases an not aligned anymore, you have to maintain code and #ifdefs for new features that depend on new versions of parts X of the stack that may or might not be used by people compiling the application. We've have some bad experiences with expected versions on the stack so i hope you're understanding this is not a theoretical scenario. Also here: proper Jenkins support. CI needs to scream at you if you commit something which does not compile. Proper Jenkins support would be a minimum requirement before we started releasing different components at different intervals. As Albert says, this has already caused problems even when we release all of KDE SC together. However, simply ensuring that everything compiles is not all - different versions of software components can functionally break things even if they compile cleanly. This has been seen on occasion with Qt in the past, and if we extend it to releasing different parts of kdelibs or kdepimlibs at different intervals, this would exacerbate the potential risks. For application developers dealing with bug reports, this is a really difficult problem - it's already the case that a particular distro can sometimes produce a bug which doesn't occur on other distros, and which the developer using another distro can't reproduce and investigate. So from an application developer's point of view, the fewer variants the better. I'd rather see a rule that we keep to a uniform release schedule, but perhaps allow individual ad-hoc exceptions if there is a really good reason. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Review Request: Define tooltips for kdeui standard actions
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104934/#review13793 --- Good idea! A couple of quick comments follow. kdeui/actions/kstandardaction_p.h http://git.reviewboard.kde.org/r/104934/#comment10944 Discard might be a bit more understandable and less technical term. kdeui/actions/kstandardaction_p.h http://git.reviewboard.kde.org/r/104934/#comment10942 I doubt whether elements will necessarily be understandable to a non-tech user in all circumstances, especially when it's just a block of text. kdeui/actions/kstandardaction_p.h http://git.reviewboard.kde.org/r/104934/#comment10943 Elements is too technical a term to necessarily be understandable to a non-tech user in all circumstances, especially when it just refers to a block of text. - David Jarvie On May 13, 2012, 10:08 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104934/ --- (Updated May 13, 2012, 10:08 p.m.) Review request for kdelibs. Description --- Attached patch tries to define tooltips for most of kdeui standard actions. The goal of this change is to try to bring value to the tooltips of toolbar buttons, instead of simply repeating the button text (I wrote a blog post about this: http://agateau.com/2012/05/11/common-user-interface-mistakes-in-kde-applications-part-5-big-toolbars/ ). I tried to come up with tooltips which would remain generic enough in a wide range of contexts, but couldn't find generic-enough tooltips for every actions. In this case I left the tooltip empty, which cause QToolButton to use the action text as tooltip, as before. If you have suggestions for the missing tooltips or corrections to the tooltips I came up with (I am not a native english speaker), please comment. Diffs - kdeui/actions/kstandardaction.cpp 2312cc1 kdeui/actions/kstandardaction_p.h f6e6ae7 kdeui/actions/ktogglefullscreenaction.cpp 8d03d6e Diff: http://git.reviewboard.kde.org/r/104934/diff/ Testing --- Tested with a few KDE applications: KWrite, Kate, Dolphin, Gwenview. Checked improved tooltips are shown and code still falls back to action text if no tooltip is defined. Thanks, Aurélien Gâteau
Re: Package Dependcies List on Techbase
On Mon, May 7, 2012 4:36 pm, Allen Winter wrote: Howdy, I started putting the list of package dependences (arranged by module) onto Techbase. http://techbase.kde.org/Getting_Started/Build/Requirements The tables on the subpages there are generated by a perl program I wrote. That program reads the CMakeLists.txt files inside a module and generates wiki content I then copy+paste into Techbase. Please review for accuracy. These are really useful pages - thanks for taking the time to do this! 1) One observation is that in some cases, different modules which depend on each other require different versions of the same dependencies. It would be nice if there was some correlation between these. For example, kdelibs requires shared-mime-info = 0.60, while kdepimlibs requires shared-mime-info = 0.30. Since kdepimlibs depends on kdelibs, shared-mime-info = 0.60 is effectively required for kdepimlibs as well, even if its CMakeLists.txt only asks for 0.30. 2) Is QtDeclarative actually REQUIRED for kdepim? Isn't it only required in order to build mobile apps? If so, it should be marked as Optional. Are there any other dependencies which are similarly marked as Required, when in fact they are optional? -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Package Dependcies List on Techbase
On Tue, May 8, 2012 1:07 pm, Allen Winter wrote: On Tuesday 08 May 2012 6:55:01 AM David Jarvie wrote: On Mon, May 7, 2012 4:36 pm, Allen Winter wrote: Howdy, I started putting the list of package dependences (arranged by module) onto Techbase. http://techbase.kde.org/Getting_Started/Build/Requirements The tables on the subpages there are generated by a perl program I wrote. That program reads the CMakeLists.txt files inside a module and generates wiki content I then copy+paste into Techbase. Please review for accuracy. 2) Is QtDeclarative actually REQUIRED for kdepim? Isn't it only required in order to build mobile apps? If so, it should be marked as Optional. Are there any other dependencies which are similarly marked as Required, when in fact they are optional? Well, I'm not planning to write a CMakeLists.txt parser. So I'm not planning to handle CMake conditionals. But I can add hacks as needed. In the case of QtDeclarative, the comment says that it is needed for Mobile. Making sure we have useful comments and descriptions can certainly help too. Yes, the comment says that it is for mobile, but Required is a strong term, and I don't think the comment in its current form makes it clear enough that Required might not actually mean what it says. In this particular example, QtDeclarative will not be needed for someone building for the desktop. This will be the default build option for many people, so I think it needs to be stated more explicitly that Required may actually mean Optional. I can appreciate that you may not have time to write a parser for cmake conditionals. But if conditional dependencies are going to be listed as Required, I think there should be a clear statement at the top of the page that Required doesn't necessarily mean what it says, and may mean optional, depending on what conditional settings are used. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Thu, March 22, 2012 5:47 pm, Chusslove Illich wrote: [: David Jarvie :] I understand from your email that you are only proposing to remove KUIT semantic tags, not KUIT context markers. Can you confirm this? I confirm. They are used much more than tags, and have no problems on their own; they are simply useful whenever present. They would only have no functional effect any more (this means dropping /format modifier too). The original intention of enabling consistent formatting of displayed text via semantic tags seems a very desirable one. Removing the tags seems to imply that KDE would abandon the aim of presenting a consistent interface for such items. If an inconsistent interface is generally considered acceptable, then I can live with it. But if we really want to try to make these interface elements consistent, we shouldn't drop the existing scheme without first considering what might replace it. Removing the functional effects which context markers have, including the /format modifiers, might have a significant effect if this makes everything plain text rather than rich text, so at first sight I'm not too keen on this idea. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Thu, March 22, 2012 10:25 am, Chusslove Illich wrote: Starting with KDE 4.0, i18n() functions act as XML processors under the hood, expecting the strings to be well-formed XML and resolving some tags (KUIT tags) to a target format (HTML or pure text). These KUIT tags include filename, para, emphasis, etc. I would like to drop this support in KDE Frameworks 5.0. There would be a fully automatic conversion script for sources to resolve KUIT tags in existing i18n() calls into appropriate target formats. The reasoning is as follows. Firstly, in the past 4 years, KUIT tags didn't get to be used very much. Only 0.56% of all messages (1144 out of 200,000) contain any. Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances). This means that both original strategic goals were not accomplished: text elements still have different formatting across most of KDE applications (such as whether filenames are singly or doubly quoted, bold, etc.), and translators still have little additional semantic indication of what text placeholders are substituted with. Secondly, XML processing in strings was made somewhat lax, as a compromise between ease of use, mixing with existing markup (Qt rich text), and not changing programming habits. Most conspicuously, string arguments substituted for placeholders are not automatically escaped, e.g. into lt;, which causes silent non-well formedness behind the scene. In the other direction, people also complained about lt; inexpectedly becoming , etc. (i.e. the programmer didn't know about the XML nature of i18n() and doesn't want this at all). Based on these two observations, I myself would drop KUIT and that's it. But there are a few heavy users, and I'd like to know if they would strongly object to this. Among them: KAlarm, Partition Manager, DrKonqi, libkcdraw... One automatic question could be: can we have KUIT as option, default off? In KDE 4 this was not even technically possible, due to one ugly design problem of i18n(), but I plan to deal with this problem in KDE 5; so it should be technically possible. But, given the usage statistics above, I'm not sure if it makes sense spending time on this. (There would also have to be some redesign, making everything stricter, e.g. automatic escaping on substitution and no mixing with Qt rich text. This means that current KUIT users who would like to continue to use it, would have to do some manual checking and modification in existing code.) I understand from your email that you are only proposing to remove KUIT semantic tags, not KUIT context markers. Can you confirm this? -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Bugzilla upgrade.
On Wed, March 14, 2012 9:41 pm, Burkhard Lück wrote: And to have the Additional Comments field above the BR and all comments is like tofu (http://en.wikipedia.org/wiki/Top-posting#Top-posting) There is now a preference setting which lets you choose whether to display the Additional Comments field at the top or the bottom. On Wed, March 14, 2012 7:32 pm, Daniel Nicoletti wrote: I don't think so, I think it has some huge icons but I thought it was my browsers problem, the huge header and footer it's real hard to see the content on my small screen, the new version fews snappier but the theme needs polishing imo. I also renders the footer strange using Chrome, but I hope someone is still working on this... :D Yes, the header fields waste a _lot_ of space. The old theme was far better in that respect. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: DrKonqi improvement idea
On Mon, March 12, 2012 10:36 am, Thomas Zander wrote: On Sunday 11 March 2012 11.26.53 Niko Sams wrote: I'd like to talk about an idea on how DrKonqi [] What software could crashes.kde.org run? I'm not sure, maybe abugzilla installation or somethingcustom written. Or some other bugtracking software. I'd say this is a great idea, mostly because it means a lot more can be automated on lots of ends. I like this idea too. I'd also make your webpage (or site) be mostly dumb in the handling of the data its being sent and then have a continues job on the machine to actually process and handle these crash reports. So if we get loads of requests in, we just store the data to be processed when there is CPU available. The reason is that I think we get much more useful information out of this if we allow it to take more time than a webrequest would allow. And also this will make the site much more responsive and painless. It just scales better ;) There would be an advantage in giving instant feedback to the user if possible, but if that turns out to be impractical, Thomas's suggestion of using background processing on the server could be sensible. I think Niko's proposal points to a deficiency in the current bug reporting system, in that the current system doesn't provide a facility to present the user with a quick summary of actions to take to resolve/work around the bug. True, it does have the 'version fixed in' field for bugs which are fixed, but there's nowhere that the developer can enter workarounds etc. without them being lost in the bug discussion. I'd suggest an extra text field called 'User action summary' at the top of the bug report, under 'version fixed in'. Its purpose would be to give a brief summary of how to avoid the bug (upgrade to version x.y.z / any workarounds / etc.) or what is required from users to investigate it (e.g. a summary of information needed). Reference could be made in the summary to individual comments in the bug report. The user action summary should only be editable by the assignee, to prevent users taking it upon themselves to enter mistaken information. This field could serve two purposes: 1) It would enable users to see at a glance what the status of the bug is, even in a bug report containing long winded discussion or lots of duplicate reports. 2) It could be used when crash reporting, to provide the user-intelligible feedback which Niko is proposing. In this case, of course, there would need to be a link between any crashes.kde.org and bugs.kde.org. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Review Request: Limit KDateComboBox date keywords to the date range set for the widget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104198/ --- Review request for kdelibs and John Layt. Description --- Currently, all configured date keywords are displayed in the date picker popup, including keywords for dates which lie outside the set date range and which are therefore invalid for selection. This patch hides keywords for dates earlier than the minimum date, or later than the maximum date. This is the fix discussed at the KDEPIM meeting. Diffs - kdeui/widgets/kdatecombobox.cpp 74b54f2 Diff: http://git.reviewboard.kde.org/r/104198/diff/ Testing --- Tested using KAlarm for minimum date of today or later. Thanks, David Jarvie
Review Request: Fix KStatusNotifierItem not updating its icon when set by pixmap
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103425/ --- Review request for kdelibs and Marco Martin. Description --- Set the icon for KStatusNotifierItem by setIconByPixmap(), then by setIconByName(). If setIconByPixmap() is called to set the first icon again, the icon doesn't change. The same bug seems likely to happen with other pairs of icon setting methods. This patch fixes this bug. Diffs - kdeui/notifications/kstatusnotifieritem.cpp aecb81c Diff: http://git.reviewboard.kde.org/r/103425/diff/diff Testing --- Tested switching setIconByPixmap()/setIconByName() in KAlarm. Thanks, David Jarvie
Re: Review Request: Fix KDateComboBox shrinking in size after a date is entered
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103133/#review8535 --- Unless there are objections before then, I propose to apply this patch on 30th November to meet the 4.7.4 deadline. - David Jarvie On Nov. 14, 2011, 10:58 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103133/ --- (Updated Nov. 14, 2011, 10:58 p.m.) Review request for kdelibs and John Layt. Description --- After the user enters a date by means of the date picker or by up/down arrows, the edit field in KDateComboBox shrinks so that it is too small to display all the characters in the date. In addition, when first displayed, the widget visibly resizes, which doesn't look particularly good. This patch fixes these issues. Note that the patch is really a workaround for the issue - I haven't managed to find out exactly why the shrinkage occurs. However, it is a simple fix, so unless somebody else comes up with a better way, I think it's good enough. Diffs - kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103133/diff/diff Testing --- Tested successfully in KAlarm's alarm edit dialog. Thanks, David Jarvie
Re: Review Request: Provide extra options for date keyword display in KDateComboBox
On Nov. 20, 2011, 10:07 p.m., Albert Astals Cid wrote: This patch modifies the behaviour, maybe it is better if you change KDateComboBox::NoneKeyword to KDateComboBox::NoNoneKeyword And adapt the if accordingly? This way there is no behaviour change at all and makes old users still work. This class was rushed in at the last moment for KDE 4.7, and I doubt whether this particular behaviour is really right, or that many applications will want it. So although it is a minor change in behaviour, I would see it as rectifying a mistake. The function to select a blank date is already there via the clear button in the edit field anyway, so the change only removes the duplication of a feature. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103103/#review8351 --- On Nov. 10, 2011, 12:36 a.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103103/ --- (Updated Nov. 10, 2011, 12:36 a.m.) Review request for kdelibs and John Layt. Description --- KDateComboBox provides the option to display a list of date keywords with the date picker popup. These keywords currently show dates in the past, present and future, together with a no date item. The no date item is a particular problem since not only is it redundant - since there is already a button in the line edit to clear the date value - but I suspect that many applications will not accept a blank date as valid input. This patch adds two new enum values to allow applications to select which of these date keywords are displayed: one enum value shows the no date item which is now not shown by default, and another enum value hides dates in the past. Currently in KAlarm, which I maintain, the display of date keywords is disabled because dates in the past and blank dates are not valid values to enter, and it would be confusing to users to offer them as options. This patch will make it possible to display only present and future date keywords, which will enable it to make use of date keywords. Diffs - kdeui/widgets/kdatecombobox.h 63bf52f kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103103/diff/diff Testing --- Tested in KAlarm. Thanks, David Jarvie
Review Request: Fix KDateComboBox shrinking in size after a date is entered
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103133/ --- Review request for kdelibs and John Layt. Description --- After the user enters a date by means of the date picker or by up/down arrows, the edit field in KDateComboBox shrinks so that it is too small to display all the characters in the date. In addition, when first displayed, the widget visibly resizes, which doesn't look particularly good. This patch fixes these issues. Note that the patch is really a workaround for the issue - I haven't managed to find out exactly why the shrinkage occurs. However, it is a simple fix, so unless somebody else comes up with a better way, I think it's good enough. Diffs - kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103133/diff/diff Testing --- Tested successfully in KAlarm's alarm edit dialog. Thanks, David Jarvie
Review Request: Provide extra options for date keyword display in KDateComboBox
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103103/ --- Review request for kdelibs and John Layt. Description --- KDateComboBox provides the option to display a list of date keywords with the date picker popup. These keywords currently show dates in the past, present and future, together with a no date item. The no date item is a particular problem since not only is it redundant - since there is already a button in the line edit to clear the date value - but I suspect that many applications will not accept a blank date as valid input. This patch adds two new enum values to allow applications to select which of these date keywords are displayed: one enum value shows the no date item which is now not shown by default, and another enum value hides dates in the past. Currently in KAlarm, which I maintain, the display of date keywords is disabled because dates in the past and blank dates are not valid values to enter, and it would be confusing to users to offer them as options. This patch will make it possible to display only present and future date keywords, which will enable it to make use of date keywords. Diffs - kdeui/widgets/kdatecombobox.h 63bf52f kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103103/diff/diff Testing --- Tested in KAlarm. Thanks, David Jarvie
Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
On Saturday 29 October 2011 00:05:18 Thiago Macieira wrote: On Friday, 28 de October de 2011 17:43:32 Kevin Kofler wrote: Thiago Macieira wrote: Which is quite wrong already. From Qt 4.8 on, this returns empty in all cases, showing that you parsed the URL wrongly. It should be easier to spot where you made the mistake because you don't have to use specially-crafted filenames. Such a change might make sense for 5.0, but not for 4.8! Or if you really want to add the changed API to 4.x, you have to do it with a new name, deprecating (but not removing!) toLocalFile. Let's just say I disagree. This change was for 4.7, but it was reverted and added to 4.8, giving you well over ONE YEAR to adapt. Only for those who knew about it a year ago. Many people will probably only find out when things don't work with 4.8. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: The future of Power Management - together with Activities
On Sunday 02 October 2011 18:47:19 Dario Freddi wrote: On Sunday 02 October 2011 19:34:42 Andreas Pakulat wrote: That leaves out the use-case of not wanting to inhibit all aspects of the current power-save mode, but only a part by switching to a different mode that is similar but differs in one or two aspects. I can think for example for powersave-for-movie mode that dims display (because the movie is shown on a TV) but does not suspend to ram/disk or turn off monitors. Requiring people to create an activity for that even if thats the only one (besides the one they use all the time otherwise) is a regression compared to the current state. Starting from the fact that your video player (if it's a KDE one) is likely to inhibit screen power management, hence making your concern invalid, thanks to the new RandR integration, if you have an external display connected, you can now simply close the lid: the screen will be blanked and the PC will not be suspended. So we are already doing the right thing in this case. Not everybody uses (or should be required to use) a KDE video player in order to make their system work in a reasonable way. I only occasionally watch videos, normally in a browser, and I don't see why I should have to find out how to create and use a special activity (I don't use activities at all so far) just because I can't manually select the presentation profile any more. I want to just click on a link in the browser I already have running, and select presentation mode, not restart the browser in another activity to view the video. Or perhaps I have misunderstood your proposal? -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Review Request: Prevent KMessageBox instances with a parent from being application modal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102246/ --- (Updated Aug. 9, 2011, 8:39 a.m.) Review request for kdelibs. Changes --- The patch has been revised to use the Options parameter to specify window-modal instead, as suggested by Thomas. Summary --- According to the apidocs, KMessageBox instances with a parent widget specified are supposed to be window modal, not application modal. This patch fixes this. Diffs (updated) - kdeui/dialogs/kmessagebox.cpp 939be89 kdeui/dialogs/kmessagebox.h 286880e Diff: http://git.reviewboard.kde.org/r/102246/diff Testing --- Tested warningYesNo(), questionYesNoCancel() with a parent widget - widgets in a different window tree were still able to be used. kmessageboxtest runs ok. Thanks, David
Review Request: Prevent KMessageBox instances with a parent from being application modal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102246/ --- Review request for kdelibs. Summary --- According to the apidocs, KMessageBox instances with a parent widget specified are supposed to be window modal, not application modal. This patch fixes this. Diffs - kdeui/dialogs/kmessagebox.cpp 939be89 Diff: http://git.reviewboard.kde.org/r/102246/diff Testing --- Tested warningYesNo(), questionYesNoCancel() with a parent widget - widgets in a different window tree were still able to be used. kmessageboxtest runs ok. Thanks, David
Re: Formal complaint concerning the use of the name System Settings
On Wed, July 27, 2011 8:33 am, Oswald Buddenhagen wrote: On Tue, Jul 26, 2011 at 11:24:26PM +0200, Ambroz Bizjak wrote: Alternatively, there would be System Settings (KDE desktop configuration) and System Settings (GNOME desktop configuration), possibly the text in parentheses being subscribed instead. This is a little less confusing, but still confusing compared to just System Settings and GNOME System Settings, where System Settings, the native tool, is clearly preferred. i would argue that thomas' solution is better, because it is more explicit. your automatic preference for the desktop's native settings app is counterproductive for the user, because he sees ah, system settings and wtf is this?. he ignores the latter, and is frustrated by the result. in thomas' variant otoh he sees *two* wtf?s, and *has* to research it, understand the underlying problem. this is a requirement of the reality we present him with, so that outcome is *good*. The Ossi solution: the more wtf's the better ;) Seriously, I think you make a good argument - two wtf's are better than one to prompt the user to eventually find the relevant system settings application. In the ideal world, of course, there would be zero wtf's, i.e. the default system settings application would configure all the settings required. Mind you, as Thomas has pointed out, without coordination between translators, Ambroz's scheme could also result in two wtf's in some languages, which rather than being a bad thing, is probably a good thing. (It is impossible to guarantee that all translations will be coordinated - sending an email round translators might help to fix things at the time, but what about future translations (e.g. for new languages) - how could you ensure that they would also be coordinated?) -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Mon, July 25, 2011 8:08 pm, Nicolas Alvarez wrote: David Jarvie wrote: On Mon, July 25, 2011 12:50 pm, Ambroz Bizjak wrote: Hi Mark, have you seen my proposed improvement on your suggestion? http://lists.kde.org/?l=kde-core-develm=131149560119520w=2 I suggest that you consider it, because it would avoid having to update the Freedesktop specification and any DE that doesn't name its programs differently in other DEs (e.g. Xfce). This proposal has the same drawbacks as Mark's - it is aimed at knowledgeable users, not the ordinary user who may not be aware of which desktop a particular application is from. See http://lists.kde.org/?l=kde-core-develm=131159889604990w=2. So what is *your* proposed solution? As you say, the long term solution is to have setting interoperability. The key words there are long term. We can't do that *now*, before the new KDE release and before the new GNOME release. We need a solution *now* to avoid having two entries with the exact same name in the application list. Mark and Ambroz's solutions have the advantage of not requiring months of collaboration and programming, which would be needed for setting interoperability. I don't object to Mark's proposal as a short term solution - it's better than having two identically named applications. I'm just concerned that it isn't ideal from the ordinary user's perspective, and that it should be recognised as being an interim fix. The longer term aim should of course be to share as many as possible of the settings between desktops and therefore make them accessible from both Gnome and KDE System Settings applications. KCMs should be categorised according to whether or not they contain settings which are not shared between desktops, and applications using unshared settings should as a matter of policy be expected to provide direct access to the relevant KCMs, thus avoiding the need for the user to find and run the 'other' System Settings. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Mon, July 25, 2011 12:32 pm, Mark wrote: Hi Ben, Could you read and comment on my proposal: http://lists.kde.org/?l=kde-core-develm=131142514605051w=2 I would like to implement this in the spec, KDE en Gnome, but i need some pointers on where i should make such edits and to get it approved. I think that is the most sane solution that doesn't require multiple desktop files. If you agree on this, what do i need to do next? Just some guesses.. - Propose the updated standard in the freedesktop mailing list (which one?) - Make patched for KDE (which component? where? file?) - Make patches for gnome (which component? where? file?) This proposal is fine for technically literate users, and might provide a short term fix, but, as Friedrich has already pointed out, it is not good for a user who just uses whatever desktop happens to be installed on his/her system, and installs whichever applications seem suitable regardless of what desktop they come from. Such users won't necessarily know whether the application they are using is a KDE one or a Gnome one or something else. Faced with two alternative settings applications, say System Settings and KDE System Settings/Gnome System Settings, that user would not realise the relevance of the Gnome/KDE System Settings, and would likely ignore it even if it happened to be the one needed for the application. The only long term solution for ordinary users is to have interoperability of settings between desktops, so that it won't matter which system settings application they use. Applications with more specialist needs, i.e. settings which aren't (yet) interoperable, would need to provide configuration of those settings from within the application. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Mon, July 25, 2011 12:50 pm, Ambroz Bizjak wrote: Hi Mark, have you seen my proposed improvement on your suggestion? http://lists.kde.org/?l=kde-core-develm=131149560119520w=2 I suggest that you consider it, because it would avoid having to update the Freedesktop specification and any DE that doesn't name its programs differently in other DEs (e.g. Xfce). This proposal has the same drawbacks as Mark's - it is aimed at knowledgeable users, not the ordinary user who may not be aware of which desktop a particular application is from. See http://lists.kde.org/?l=kde-core-develm=131159889604990w=2. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: There is no active policy saying you're supposed to merge. Almost everybody in KDE is still doing cherry-picks. KDevelop is the only KDE project I know that consistently uses forward-merges from the stable branch to master. --- It *would* be good to switch to the new workflow of doing changes in the lowest supported branch and up-merging, but it's not that easy. We need to: - Figure out how to solve the scripty problem. scripty does its own conflicting commits to .desktop files in both branches, and that won't change[1]. We probably need a custom merge tool for .desktop-like files that ignores translations. - Check if there is any change in 4.7 that isn't in master, and if so, see if that's intentional (4.7-specific hack, or the version bumps) or an oversight (never cherry-picked into master). - Do the initial merge from 4.7 to master, solving the conflicts. The more they have diverged, the harder this is. - Get *everyone* to start with the new workflow for that particular repository (see below). Else, if some people keep cherry-picking while others expect merging, the next one to try merging may get conflicts about all the cherry-picks people did since the last merge, and a merge will make commits appear duplicated in the log (as ossi pointed out to me). During the stable branch freeze before a minor version release (such as currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake
On Mon, July 18, 2011 8:48 pm, Alexander Neundorf wrote: On Monday 18 July 2011, David Jarvie wrote: On Wednesday 13 July 2011 20:16:58 Alexander Neundorf wrote: ... What do you think of this ? More wishes ? Should it do it in a different way ? Something else which would be useful would be to output the actual file names (library files, header files etc.) which were checked for but not found when looking for the missing packages. Trying to determine which distro package to install to satisfy the dependency isn't always straightforward, since distro package names aren't always the same as the cmake package names. In these cases, I quite often have to find the cmake module used to locate the package, and then look through the cmake module to work out the files it's looking for, in order to then be able to do a package search for my distro to find which package to install. I agree that this would be useful, but this is just too much to present in the summary. It would have to contain for which files it checked, and in which directories. This is a lot. This should be done in the success/failure message during the cmake run, not in the summary at the end IMO. Yes, outputting it at the point it is found to be missing would be fine. The main thing is to provide an alternative to trawling through the cmake modules for the information. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake
On Wednesday 13 July 2011 20:16:58 Alexander Neundorf wrote: Hi, in KDE we have the file MacroLogFeature.cmake which we use to print a summary of found/missing packages at the end of a cmake run. I added similar functionality later on in 2007 to cmake in the form of FeatureSummary.cmake: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:FeatureSummary Among others due to source compatibility requirements we are still using MacroLogFeature.cmake in KDE, but I'd like to get rid of this and instead use FeatureSummary.cmake from the not yet existing cmake 2.8.6, which means we have some time to improve it so it does what we need. The plan is to get this into cmake 2.8.6, so once we have the binary break (and minor source compat. break) with Qt5 and KDE frameworks, to make the switch here too. - What is missing in FeatureSummary.cmake compared to MacroLogFeature.cmake: - * the REQUIRED keyword, to make the cmake run error out at the end if one of the packages marked with this keyword have not been found - What has FeatureSummary.cmake that MacroLogFeature.cmake does not have: - * more flexible output, to a file, to stdout * should be faster, since it stores the results in a cmake property and not in a file (cmake properties did not exist back then when I write MacroLogFeature.cmake initially) * it can separate between packages and features, i.e. you can also add feature documentation to the log at the end, e.g. for enabled or disabled options * it's in cmake, so no extra stuff for us to maintain - What I'd like to have additionally in FeatureSummary.cmake - * the ability to report runtime dependencies, i.e. packages which have been checked for at build time, but which are actually not used at build time, but only at runtime. So the build will be successful if they are missing, but the result will not run properly * the ability to set not only a description of a package, but also one or more usages/purposes. How I imagine this is the following, e.g. for FindLibXml2.cmake: inside FindLibXml2.cmake: find_path(...) find_library(...) ... set_package_info(LibXml2 XML processing library. http://xmlsoft.org/;) and then in a project using LibXml2, let's assume koffice: find_package(LibXml2) set_package_properties(LibXml2 PROPERTIES PURPOSE Required for exporting spreadsheets to odt format in kspread) and in some other part of the project: set_package_properties(LibXml2 PROPERTIES PURPOSE Required for importing html files in kword) find_package(DBus) set_package_properties(DBus PROPERTIES TYPE RUNTIME PURPOSE Required to disable the screensaver via kpresenter) - which should then produce something like: -- Found packages: LibXml2, XML processing library., http://xmlsoft.org * Required for exporting spreadsheets to odt format in kspread * Required for importing html files in kword ... -- Missing RUNTIME packages: DBus, A desktop IPC bus, http://dbus.freedesktop.org * Required to disable the screensaver via kpresenter What do you think of this ? More wishes ? Should it do it in a different way ? Something else which would be useful would be to output the actual file names (library files, header files etc.) which were checked for but not found when looking for the missing packages. Trying to determine which distro package to install to satisfy the dependency isn't always straightforward, since distro package names aren't always the same as the cmake package names. In these cases, I quite often have to find the cmake module used to locate the package, and then look through the cmake module to work out the files it's looking for, in order to then be able to do a package search for my distro to find which package to install. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Date/Time in KF5 / Qt5
On Wednesday 06 July 2011 18:26:16 Sean Harmer wrote: Hi, On 29/06/2011 20:54, John Layt wrote: Duration: A number of Qt community members have a merge request for this already, but I feel it needs some clean-up. It would be great if an experienced KDE eye could look at this as it is likely to end up in Qt5. Lars Knoll has now given some more feedback on this MR which we are now trying to address. Hopefully it will be up to scratch for inclusion shortly. Can you provide a URL for this? Duration should allow for daylight savings time changes when it is specified in terms of days. Even if the Qt class doesn't do this itself, it needs to make the appropriate methods virtual to allow us to override them. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: Date/Time in KF5 / Qt5
On Wednesday 06 July 2011 19:52:50 Thiago Macieira wrote: Em Wednesday, 6 de July de 2011, às 18:54:37, David Jarvie escreveu: On Wednesday 06 July 2011 18:26:16 Sean Harmer wrote: Hi, On 29/06/2011 20:54, John Layt wrote: Duration: A number of Qt community members have a merge request for this already, but I feel it needs some clean-up. It would be great if an experienced KDE eye could look at this as it is likely to end up in Qt5. Lars Knoll has now given some more feedback on this MR which we are now trying to address. Hopefully it will be up to scratch for inclusion shortly. Can you provide a URL for this? Duration should allow for daylight savings time changes when it is specified in terms of days. Even if the Qt class doesn't do this itself, it needs to make the appropriate methods virtual to allow us to override them. There will be no virtuals in date-time or timespan classes. You don't need to override anything. It's not like you will ever need to extend the concept of date, time or timespan: dates are the same for all applications. Duration is simply the number of seconds or milliseconds between two dates, appropriately given in their universal time. So duration is not affected by daylight savings. Duration must record whether it was specified in terms of hours/minutes/seconds, or days/weeks/whatever so that daylight savings changes can be taken into account when calculating the end time of a duration, given a start time. If the duration class provides methods to calculate the end time, given a start time, then it must take account of daylight savings changes. See kdepimlibs/kcalcore/duration.h for example. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: Date/Time in KF5 / Qt5
On Wednesday 29 June 2011 20:54:48 John Layt wrote: Hi, This is the second email in the series of three looking at KLocale in Frameworks 5. This email covers Date/Time, so I have also cc'ed the PIM mailing list for their input. As with QLocale, the lack of features in QDateTime has forced KDE to create our own solutions such as KDateTime, KLocalizedDate and KCalendarSystem at the cost of interoperability with pure-Qt code. In KF5/Qt5 I want to work to resolve this problem by implementing full support for our required features in Qt. The discussions held at QtCS were very promising on being able to achieve this. You can find the notes at http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/QDateTime Time Zones: A feature everyone wants but no-one seems to have the expertise or time to do. The general consensus was that a new QTimeZone class was required to be embedded in QDateTime with an api based around the Unix/Olsen time zones, but using the host platform time zone system in the background. This is the same concept as KTimeZone so should meet our requirements. I'll be trying to co-ordinate this, but I need people to step up and take on the implementation. Ideally the authors of our time zone support will be willing to port their own code over, or at least review other peoples code submissions. If not all the most advanced time zone features of KDateTime are accepted we can probably put them into a support class. Hi John, Sorry for not replying sooner. I don't have time to take on the work of implementing this, but in any case, I don't think that I'd want to contribute significant new code to Qt unless the licence was purely (L)GPL, or unless (and I wouldn't have time even in that case) I was paid for it. I would be willing to review other people's code, though. Cheers, -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: Intended organization of KDE Frameworks
On Sunday 03 July 2011 03:31:07 Nicolás Alvarez wrote: On 6/26/11, Ingo Klöcker kloec...@kde.org wrote: On Tuesday 07 June 2011, Albert Astals Cid wrote: A Tuesday, June 07, 2011, Kevin Ottens va escriure: On Tuesday 7 June 2011 01:26:17 Albert Astals Cid wrote: A Tuesday, June 07, 2011, Kevin Ottens va escriure: Well, obviously a Tier 1 framework would have to use tr() instead of i18n() for its translation needs. Are we still going to use .po or you plan on us moving to Qt translation files? Well, I honestly don't know what awesome magic you used for libsolid, so for me it's the same recipe. Note that it'll happen mostly for Tier 1 frameworks though. Unfortunately that is not possible. Right now Solid is translated using .po but that only works in KDE applications because you have a KGlobal+KLocale around that loads .mo files (compiled .po), hijacks Qt calls and maps them to the .mo contents. Without a KGlobal+KLocale around that will not work. This means that if you want Tier 1 frameworks to be translatable you need either to teach Qt to understand gettext files natively or to make Tier 1 frameworks use pure based Qt/Linguist solutions which does not fit either in what scripty is able to do neither in what our translators are used to. AFAICS, Tier 1 frameworks don't provide any UI. IMHO they shouldn't provide any user visible texts either. Just like UI this should be outsourced to Tier 2 or 3 if necessary at all. Many classes that one may reasonably think that use no translations, like KPluginLoader, contain many user-visible strings. The class reports errors via an errorString that the host app may then display to the user. Perhaps some of these classes could return error codes instead in order to qualify for Tier 1, and an additional Tier 2 class could provide the message texts which relate to the error codes. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: KDE git workflow
On Wed, June 8, 2011 6:03 pm, Cornelius Schumacher wrote: As you already know, we have discussed the git workflow for KDE at the Platform 11 sprint, and have come up with a recommendation. Please find the full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow The core ideas are that: * master is always kept in a stable state that is ready to be used for starting a release * development is happening in feature branches * for larger projects integration branches will be used for further stabilization and wider testing * changes going into master are going through a review process * releases are coming from release branches Please read the full text before commenting to get all details. This workflow will be adopted by some core modules, and is recommended for all KDE modules. It's flexible enough to be used by modules of different sizes and different requirements in terms of stability, so we hope it to be a reasonable fit for as many people as possible. Obviously we'll have to see how well it works and adapt it, if necessary, but it should be a good start. One side effect of using integration branches in what used to be kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely tested until later in the development cycle than previously. While they are in integration branches, only people who are particularly interested in those areas are likely to use them, and it's only once they eventually reach master that they will be widely used by developers. In one way, that's a good thing, since there should be less bugs encountered by those not directly involved. But the overall effect could be to slow down bug fixing of new features. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: KDE git workflow
On Thu, June 9, 2011 5:22 pm, Cornelius Schumacher wrote: On Thursday 09 June 2011 Maksim Orlovich wrote: And what if there are multiple branches on the same module at the same time? Which one of these branches, or master (or release?) is going to get testing coverage? The idea is that, if there are multiple feature branches, the integration branch is used to collect them and get testing coverage and review there. In order to get good testing coverage, there should normally only be one integration branch per git module. Otherwise, testing coverage will be split between the competing integration branches. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Review Request: Fix KAuth::Action::execute() not returning error description string
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101314/ --- Review request for kdelibs and Dario Freddi. Summary --- KAuth::Action::execute() doesn't return the error description string contained in KAuth::ActionReply. The reason is that the errorDescription() is not serialized by operator() or operator(). This patch adds the description string to the (de)serialization. Diffs - kdecore/auth/kauthactionreply.cpp 9c89d17 Diff: http://git.reviewboard.kde.org/r/101314/diff Testing --- The patch fixes the problem when used with a new feature in KAlarm. Thanks, David
Re: Deploying new kdelibs classes
On Sat, April 23, 2011 10:22 pm, Jaroslaw Staniek wrote: Aurélien, I am writing regarding http://agateau.wordpress.com/2011/04/21/kde-ux-2011/ One thing, about deploying the kmessagewidget (and similar things) in kdelibs. If it's part of kdelibs 4.7 or something, apps that support kdelibs 4.7 would have to fork it (unless distro backports given classes to previous kdelibs but this it very bad idea and technically and coordination-wise). How to solve that? I am thinking about releasing additions to kdelibs as separate libraries like kdelibs47.so etc. and then merging only in 5.0. Perhaps there's already solution I am not aware of. I'm not aware of any policy in the past to prevent new classes being added to kdelibs. It's something that third party apps have always had to cope with. Are you perhaps thinking of the rule in kdepim which says that it must build against the previous version of kdepimlibs? -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Minor Point Relase Policy
On Monday 07 March 2011 23:04:01 David Faure wrote: On Sunday 27 February 2011, Albert Astals Cid wrote: Hi, the release-team has written a minor point release policy for KDE main modules. You can find it at http://techbase.kde.org/Policies/Minor_Point_Release_Policy As far as we know it covers what we already do, just makes it a bit more official and standarized. Almost. Before, I was adding new API in the stable branch when necessary for a bugfix, without thinking much about it. Now I'll make a review request, for good measure :-) It says that API changes to public libraries must be approved by kde-core-devel. Shouldn't kdepimlibs changes be approved on the kde-pim list instead? -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: A Qt replacement for KGlobal::ref and deref
On Wed, February 16, 2011 1:44 am, Aaron J. Seigo wrote: On Tuesday, February 15, 2011, Stephen Kelly wrote: http://steveire.com/kdelibs-modular.png * It's broad at the base - Qt developers can pick and choose what they want. There are less interdependencies - you can use the itemviews stuff without also pulling in KLocale KConfig etc. If you're happy with QSettings and QLocale (and Qt developers are happy with those), then you don't use them. * All the platformy stuff is at the top instead of at the bottom. * KDE applications know no difference. The platformy stuff is provided to them still. what's interesting is that we aren't as far from your desired diagram already. your what it looks like now to a qt developer diagram is as much a matter of perspective as it is of the reality. yes, we have modularization to do (the item views, for instance, perhaps being a good example; kdeui has several such things in it), but libkdecore is not such a big issue imho. don't want kconfig? don't use it. splitting it out to its own library is likely to be more burdone that benefit. There would be a major benefit from splitting KConfig etc out of kdecore: Qt developers could use the stripped down library confident in the knowledge that they could use any class in it without having to worry about whether they might accidentally introduce a dependence on platformy stuff. Having all the kdecore classes mixed together in a single library, as now, would mean that Qt developers have to check all the time which classes are safe to use and which aren't - and currently, that isn't even documented clearly. That puts up a big barrier to others using our library. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Moving stuff upstream (was: A Qt replacement for KGlobal::ref and deref)
On Wed, February 16, 2011 11:57 am, John Layt wrote: The thing is, most of what is in kdecore date classes really does belong in the Qt classes, these are standard things on all platforms that Qt just hasn't implemented. QLocale is bizarrely incomplete in places. Why wouldn't Qt want to handle timezones correctly in this global internet age? Why wouldn't they want to format dates correctly? Why wouldn't Qt want to support what the system localisation settings actually are? Some of this can actually be fixed in Qt 4.x, we just need to convince Qt to accept the patches. KLocale is something that we need to take a step back from and ask why we have it and if there isn't a better more standard way to achieve those things. We have it so our users can customise their locale settings, to add some non- standard settings, and so apps can change the settings temporarily to do clever things. I've some ideas on how we can do those better. Remove KLocale and the date classes from the core (non-ui) stack and a lot of problems disappear, including their dependency on KConfig. KConfig is going to be the big problem, fortunately not one I deal with :-) Perhaps a KConfig backend to read/write from QSettings files would remove most Qt-only objections to using it in things like kimap? I'd hate to see us have to ifdef support for two config systems in such libraries. Anyway, I've started a page to document such things at http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there. David Jarvie, could you add something to the KDateTime entry? Done. I hope it contains enough explanation - if you think it needs more, please say so. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Usage of pull rebasing and merges
On Tue, February 8, 2011 9:08 am, Ben Cooksley wrote: On Tue, Feb 8, 2011 at 9:49 PM, Sebastian Trüg tr...@kde.org wrote: Hi Ben, could you please elaborate on this. I do not understand the problem at all. What is so bad about rebasing and what is wrong with the commit you mention? Cheers, Sebastian Hi Sebastian, The problem in this case isn't rebasing itself, but doing a pull rebase after doing a merge. If you do a pull rebase after a merge, then *all* the commits you just merged in will be rebased as part of that process. This will cause new commits to be created which has the effect of: - Increasing the repository size - Causing the commit hooks to run for those commits, repeating any keyword actions in the process The commit I pointed to was wrong because it was a commit which had been rebased from elsewhere, yet was unchanged other than it's metadata. I'd already come to the conclusion myself that merging before pull rebase wasn't a good idea because of the likely conflicts which result, unlike when the merge is done after the pull. But I don't understand any part of your explanation above - why would it increase the repository size? don't commit hooks run on EVERY commit anyway? what's wrong with the example wrong commit, which did change one source line (not just metadata)? -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Merge or Cherry-Pick?
On Wed, February 2, 2011 11:38 am, John Tapsell wrote: On 2 February 2011 07:27, Dawit A ada...@kde.org wrote: Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push... And then one day you do git checkout . by mistake and lose all your local uncommitted changes that you just spent a week working on .. I'd recommend maintaining a local 'master' branch which always mirrors the remote repository. Never do development in your local 'master' branch - always do your work in other local branches, and only merge/cherry-pick changes from them into the local 'master' once you are ready to push to the remote. That way, your local master always mirrors the remote, and you can choose exactly when and which commits to push. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Merge or Cherry-Pick?
On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote: I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Then let's solve the problem by not having anything specific to 4.6. If it belongs in the stable release, it belongs in the next stable release too. That's not always true. Some changes *will* be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Action icons in menus
On Tue, December 14, 2010 2:52 pm, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. I doubt if many inexperienced users will know about Settings-Configure Shortcuts. Personally, I rely on menus to provide me with the information when I want to learn a new shortcut - I wouldn't normally go to the bother of looking in Settings unless I felt very motivated. So yes, I think this is a significant problem, since it raises the barrier to inexperienced users learning shortcuts. Note that this proposal addresses common actions only, so the fact that some shortcuts are not documented in menus isn't really relevant. A third argument against is that people using the menu will most likely continue doing so. So for them the shortcut is totally irrelevant. In fact, it's superfluous information that clutters the menu. And for those that are really interested in the shortcut it's also superfluous information as soon as they have learned the shortcut. As I mention above, I don't think they necessarily will ever learn the shortcut if they first have to discover a Settings page, and then open it up each time they want to find a new shortcut. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Review Request: KDateEdit moving into kdelibs
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6014/#review9054 --- The code is based on an old version of KDateEdit - the feature in the libkdepim version to set a minimum and/or maximum date is missing. This needs to be added, or it will break things. /trunk/KDE/kdelibs/kdeui/widgets/kdateedit.h http://svn.reviewboard.kde.org/r/6014/#comment9847 Please update my email to djar...@kde.org (here and in other places) - David On 2010-11-29 22:11:34, Kevin Ottens wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6014/ --- (Updated 2010-11-29 22:11:34) Review request for kdelibs and KDE PIM. Summary --- For a very long time now there's been a KDateEdit widget cooking up in kdepim. It's in fact a popular one, and I'm aware of around half a dozen (sometimes modified) copies of that widget. One of the most advanced fork is in Skrooge ATM. During the latest KDE Hacking Session in Toulouse, I sat down with the Skrooge maintainer and produced a refactored version of KDateEdit which also cover their needs. This patch is about introducing this widget in kdeui. It basically comes with three new classes: - KDateEdit itself; - KDatePickerPopup used by KDateEdit to popup a calendar picker; - KDateValidator used by KDateEdit to validate the input, it's made public as some of the fixup behavior can be tuned. Note that KDateTable already exposed a class named KDateValidator (much less advanced), so I took care of copying the extra method the former KDateValidator was exposing for BC reasons. I'm aiming for inclusion in 4.6, so a prompt review would be welcome. Thanks in advance. ;-) Diffs - /trunk/KDE/kdelibs/includes/CMakeLists.txt 1201925 /trunk/KDE/kdelibs/includes/KDateEdit PRE-CREATION /trunk/KDE/kdelibs/includes/KDatePickerPopup PRE-CREATION /trunk/KDE/kdelibs/includes/KDateValidator 1201925 /trunk/KDE/kdelibs/kdeui/CMakeLists.txt 1201925 /trunk/KDE/kdelibs/kdeui/widgets/kdateedit.h PRE-CREATION /trunk/KDE/kdelibs/kdeui/widgets/kdateedit.cpp PRE-CREATION /trunk/KDE/kdelibs/kdeui/widgets/kdatepickerpopup.h PRE-CREATION /trunk/KDE/kdelibs/kdeui/widgets/kdatepickerpopup.cpp PRE-CREATION /trunk/KDE/kdelibs/kdeui/widgets/kdatetable.h 1201925 /trunk/KDE/kdelibs/kdeui/widgets/kdatetable.cpp 1201925 /trunk/KDE/kdelibs/kdeui/widgets/kdatevalidator.h PRE-CREATION /trunk/KDE/kdelibs/kdeui/widgets/kdatevalidator.cpp PRE-CREATION /trunk/KDE/kdelibs/kdeui/widgets/kdatevalidator_p.h PRE-CREATION Diff: http://svn.reviewboard.kde.org/r/6014/diff Testing --- Thanks, Kevin
Re: Review Request: Four simple patches for kdecore
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5775/#review8523 --- /trunk/KDE/kdelibs/kdecore/date/ktimezone.cpp http://svn.reviewboard.kde.org/r/5775/#comment8884 The patch is wrong. 'refCount' holds the number of KTimeZoneBackend instances use the KTimeZonePrivate instance as a d-pointer. Changing the contents of a KTimeZonePrivate instance by means of operator=() doesn't affect how many references to it are held, so refCount must remain unchanged. - David On 2010-11-06 13:01:55, Jaime Torres wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5775/ --- (Updated 2010-11-06 13:01:55) Review request for kdelibs. Summary --- As I do not know if that kind of patches are allowed in the freeze period, I ask for them together. I'll submit them individually. 1. ktimezone. Include the initialization of refcount in the = operator. 2. klocale_kde. From 469 queries to paths.end() to 1 (from 0.01% to 0% in callgrind) 3. netsupp. Remove a memory leak. 4. ksharedDataCache. Change the obsolete usleep (since 2001 or before) to nanosleep. Diffs - /trunk/KDE/kdelibs/kdecore/date/ktimezone.cpp 1193582 /trunk/KDE/kdelibs/kdecore/localization/klocale_kde.cpp 1193582 /trunk/KDE/kdelibs/kdecore/network/netsupp.cpp 1193582 /trunk/KDE/kdelibs/kdecore/util/kshareddatacache.cpp 1193582 Diff: http://svn.reviewboard.kde.org/r/5775/diff Testing --- No regressions in the unit tests. Working with them. Thanks, Jaime
