Re: -Wunused-but-set-variable warnings
On Mon, Jul 4, 2011 at 5:05 PM, Matthias Fuchs ma...@gmx.net wrote: Am Montag 04 Juli 2011, 20:07:20 schrieb Albert Astals Cid: A Monday, July 04, 2011, Dawit A va escriure: The following files all contain set but unused variables: snip Unlike the -Wunused-parameter fixing this warning messages requires context because the variable may be set and unused due to a mistake that can potentially be causing a bug. As such can kdelibs cmake file be changed to error out, -Werror=unused-but-set-variable, for such warnings ? You really want to make kdelibs uncompilable? Albert Indeed. IIRC in some cases the public API has unused members. Removing them could lead to ABI problems. I was not talking about unused members, but unused-but-set variables. There is a difference. Most importantly though the compiler does not throw any warnings for public member variables. I know cause I do not get any such warnings for one of the classes I wrote eons ago, KIO::Auth.
Re: -Wunused-but-set-variable warnings
On Mon, Jul 4, 2011 at 2:07 PM, Albert Astals Cid aa...@kde.org wrote: A Monday, July 04, 2011, Dawit A va escriure: The following files all contain set but unused variables: snip Unlike the -Wunused-parameter fixing this warning messages requires context because the variable may be set and unused due to a mistake that can potentially be causing a bug. As such can kdelibs cmake file be changed to error out, -Werror=unused-but-set-variable, for such warnings ? You really want to make kdelibs uncompilable? Why would that make it uncompilable again ? I am not asking the change to be done without first addressing the existing issues. That does not make any sense. In fact, I went through and fixed almost all of the -Wunused-paramter warnings, which I have yet to post for review. However, I cannot do the same for this particular warning for the reasons I already stated above. If I was going to do it, it would have to be agreed that we will turn such warnings into errors going forward or it would be a useless endavor since someone else down the line would break it again!
Re: Bug#199209
Hi Steven; On Mon, Jul 4, 2011 at 12:59 AM, Steven Sroka sroka.ste...@gmail.comwrote: I hate asking this, but can someone with some free time take at look at #199209? It's bug that affects openSUSE and it's been unassigned for two years now. I'm only asking now because we are in the bug fixing stage for KDE 4.7. Some people believes this to be a bug but I'd disagree, you should use xdg-su -c command instead. Regards, ismail
Re: Translation in Qt5
On Tue, Jul 05, 2011 at 12:57:27AM +0200, Chusslove Illich wrote: [: Oswald Buddenhagen :] because everyone is complaining about the extra contexts, including our qml team. I would be interested at what the concrete complaints were. - the class names cause many messages to be duplicated - class names are not meaningful in qml additionally, from the lupdate pov, the parsing of class names (and namespaces) is unreliable in the face of #ifdefs and other preprocessor magic. On that it depends whether those who complained would want to compensate. sure they do - even if they don't know yet. the contexts were trying to automate disambiguation. while they did a somewhat poor job with quite some collateral damage, they still served a purpose. If they would, then @-markers do not automatically mean they would also want semantic markup. And if there is no markup, then @-markers are indeed pure convention, adding them equals adding one section to documentation. correct. and in fact, nobody asked for semantic markup. so i asked you why you added it, and what changed since. kde libs continuing to have a separate i18n system will immediately cut half of their value as qt addons. I do not understand this. [...] I could even conjecture an advantage in having two separate translation systems [...] - it's yet another library. who wants to link kdecore (or maybe ki18n if we went for such absurdly fine granularity) for just translations, especially given that they are usually an afterthought? - the ongoing basic feature duplication puts kde into a bad light - it fragments the qt ecosystem regarding translations. the communities translating qt and addons would have to deal with two systems. - it deprives qt essentials themselves and addons apps which want to depend only on the essentials from having a reasonable translation system. Then you can market Qt translation system as seamlessly fitting with the translation industry practices, reducing costs of translation services -- I think this is by far the most important feature you can have. optimize for crap. no way. if somebody cares, he can make *that* an addon.
Re: Translation in Qt5
[: Oswald Buddenhagen :] because everyone is complaining about the extra contexts, including our qml team. [: Chusslove Illich :] I would be interested at what the concrete complaints were. [: Oswald Buddenhagen :] - class names are not meaningful in qml additionally, from the lupdate pov, the parsing of class names (and namespaces) is unreliable in the face of #ifdefs and other preprocessor magic. These are rock-solid reasons, and the ones I would have been against such an automatic approach in the first place. Contexts should be manual. Automatic should be extracted comments (that's PO terminology, #. comments). Since they are comments, all sorts of parsing unreliability is totally fine, so long as the overal effect is clearly benefitial. - the class names cause many messages to be duplicated This is exactly the reason I was afraid someone had put out :) It basically reveals that they care zero about context. It shows you... [: Chusslove Illich :] On that it depends whether those who complained would want to compensate. [: Oswald Buddenhagen :] sure they do - even if they don't know yet. the contexts were trying to automate disambiguation.[...] ...that they weren't seriously thinking about disambiguation at all. in fact, nobody asked for semantic markup. so i asked you why you added it, and what changed since. As expected. I'll get to that one in an another reply. - it's yet another library. who wants to link kdecore (or maybe ki18n if we went for such absurdly fine granularity) for just translations, especially given that they are usually an afterthought? I really would like it to be a library on its own, precisely so that I could use it and recommend it out of KDE (as in KDE project/community) and Qt apps. In fact, the hardest thing about that library is designing how it should interface and behave. Implementation is much easier, assuming all pieces listed in footnote 3 in my previous message are available. I would be more than happy if someone were to port it to, say, Glib and whatever. I am primarily a translator, and therefore I want as wide adoption of the advanced concepts that KDE currently offers, rather than stop at our framework offers the best i18n. - the ongoing basic feature duplication puts kde into a bad light There is already Linguist and raw Gettext. That already makes for duplication, unless Qt switches to raw Gettext, or Qt and Gettext meet half- way (absurd). KDE i18n library would be, as it is, a layer atop Gettext, so it does not add to duplication as such (runtime MO parsing would be duplicated, but that's internal and trivial). - it fragments the qt ecosystem regarding translations. the communities translating qt and addons would have to deal with two systems. Not entirely. Though I shudder from Scripty, I will personally go in and hack it to do the TS-PO-TS roundabout, so that KDE (as in KDE Translation Project) translators do not feel Linguist workflow. There would only be lack of advanced features (scripting, etc.) but that is no news, since we already translate pure text, documentation, and hopefully other custom formats in the future (all over PO of course). - it deprives qt essentials themselves and addons apps which want to depend only on the essentials from having a reasonable translation system. Linguist is a *reasonable* translation system. It is better than anything other than raw Gettext/PO. When TS-PO-TS roundabout is present, they become equivalent[1]. KDE i18n atop Gettext is *martial arts* of translation (but such that willing translators can steadily improve with it, rather than being thrown into the breach at first encounter). [1] Just please add per-file plural formulas. They can be optional, with fallback to hardcoded default if missing. [: Chusslove Illich :] Then you can market Qt translation system as seamlessly fitting with the translation industry practices, reducing costs of translation services -- I think this is by far the most important feature you can have. [: Oswald Buddenhagen :] optimize for crap. no way. if somebody cares, he can make *that* an addon. I bet even money you would say this out loud :) From the rational business point of view, I hold by my advice and estimate. It's also not mere crap, both approaches are Pareto-optimal (efficiency vs. quality). But I totally understand your sentiment, I can't stand it either. -- Chusslove Illich (Часлав Илић) 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: -Wunused-but-set-variable warnings
Em Monday, 4 de July de 2011, às 12:02:47, Dawit A escreveu: Unlike the -Wunused-parameter fixing this warning messages requires context because the variable may be set and unused due to a mistake that can potentially be causing a bug. As such can kdelibs cmake file be changed to error out, -Werror=unused-but-set-variable, for such warnings ? Don't forget the case where the variable is set as a result of a function call that has side-effects. If that's the case, you may remove the variable, but you cannot remove the function call. We caused a couple of regressions in Qt due to this mistake. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Translation in Qt5
[: Oswald Buddenhagen :] right, now i remember that we talked about that. auto-escaping is the only reasonable option. suppression should be done on a per-placeholder basis (which brings us to rich formats again). though i wonder how often you'd actually want to substitute a pre-quoted string? i'd expect this to happen in cases where regular concatenation is actually an option. counter- examples? Me confused (but see below). one could also use a different syntax for the markup, think gmake macros: foo $(filename %1) or maybe qmake? foo $$filename(%1) of course either would require some escaping stunts, etc. I thought about a markup less verbose than XML, but I would rather not risk it. XML also has defined syntax for attributes, escapes, it is well-known to both programmers and translators, parsers available on every corner (e.g. when writing translation checker tools), syntax highlighting, etc. if one defines that KUIT is a superset of qt rich text, there is not even a theoretical problem with it. But KUIT is supposed to be transformable into different target formats, of which Qt rich text is one? (The other currently is plain text, and I've reserved a slot for shell color sequences.) what i'd expect now would be an actual use case for this stuff. you indicated yourself that this is no high priority for you. why? did it turn out less useful than anticipated? or too problematic (despite the above answers)? The use case was simply that some people got fed up with thinking every time whether to wrap, say, a file name with single quotes, double quotes, i, b, etc. So they wanted a system by which they can just say this is a filename and then it gets formatted according to that and to output destination. Really, the standard argument for semantic markup. At first, the idea was to make such indications from the outside (e.g. a .subs() method overloaded on QFile, QUrl, etc.), but that quickly spiraled out of control (you can check the thread KDE 4 proposal: Paths in i18n strings, July 2006). As an alternative, a bit later, I came up with semantic markup directly in text. This had the benefit of giving extra information to translators, and enabling translators to use the markup themselves. Three problems cropped up. First, some people really didn't like that semantic markup was thrown onto everyone, without possibility to disable it. This was mostly due to need to care about escaping. So they wanted it other way around, that it needs to be enabled by those who want it -- but this is not easy to provide (there is a wider fundamental problem in the background). The second problem is escaping and substitution. I tried briefly with auto- escaping, got regression reports in about a month, had to disable it. But substition also has issues related to how the output format is chosen: QString problem = i18n(@item:intext, filename%1filename got deleted., filename) # ...this formats as plain text because that is the default for @item:intext... i18nc(@info, A problem happened: %1, problem) # ...while this is rich text because that is default for @info, # but due to the above the filename still ends up with plain text formt. The third problem I was aware of from the beginning, but thought let's give it a try. When you have fixed semantic markup, there is the problem of set of tags. If it is a small set, then people will miss special tags for their special things in their applications. If it is a large set, people will still miss some, and worse, they will be blocked thinking what to use from that large set (this is sapping the life out of Docbook, for example). So I went with a small set, and even myself am now not very happy at the choices I made. In summary, whether due to these problems or because simply not many people cares about it, semantic markup didn't really take off. So I hoped it is not big deal to drop it. (Note that this does not include @-context markers, they have no problems on their own and are much more used than markup.) But then there comes along an i18n bug like this: https://bugs.kde.org/show_bug.cgi?id=267439 . In the code, it looks like: importantHighlight(i18n(Uses of) + ) + nodes[1] + importantHighlight( + i18n(from) + ) + nodes[0] + hr; Here the programmer did some semantic markup on his own, not thinking of i18n rules. But if he had thought of i18n rules, what could he have done? Nothing -- except drop the markup. (This markup resolves into colors, and there are other *Highlight() wrapper functions, all neatly defined in a standalone file: typeHighlight, propertyHighlight, commentHighlight...) I too was in a similar position as this guy, in a Python code I maintain; it is shell-only, but needs output coloring dependent on destination (shell sequences, HTML, none). Therefore I badly needed some sort of markup, and having in mind the problems listed above, I thought about (and partly implemented) an uprated markup system.
Enviroment variables and KAuth
Is it a bug or feature that no enviroment variables (most notably $PATH) are set for DBus-activated KAuth helpers? Manually launching the helper from a shell doesn't lead to this behaviour: enviroment variables are properly set. Konstantinos Smanis
Re: Review Request: [KIO] AccessManager: the missing piece to go with 1bf9737.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101859/#review4415 --- Unnecessary because a job is NOT created in either of those case and as such the state of that flag is of no consequence. - Dawit On July 5, 2011, 8:32 p.m., Pierre Rossi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101859/ --- (Updated July 5, 2011, 8:32 p.m.) Review request for kdelibs and Dawit Alemayehu. Summary --- Bonus question: should this go in 4.7 or master ? Diffs - kio/kio/accessmanager.cpp ef9b8ef Diff: http://git.reviewboard.kde.org/r/101859/diff Testing --- Thanks, Pierre
Re: Review Request: [KIO] AccessManager: the missing piece to go with 1bf9737.
On July 5, 2011, 9:47 p.m., Dawit Alemayehu wrote: Unnecessary because a job is NOT created in either of those case and as such the state of that flag is of no consequence. Pierre Rossi wrote: ok, then if the parent is not necessary either, we should probably drop it too. I just didn't like the fact that a pointer was given for a bool. Oops. You are correct. I missed that. So please go ahead and commit and yes it needs to go into 4.7 and cherry picked into master. Thanks. - Dawit --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101859/#review4415 --- On July 5, 2011, 8:32 p.m., Pierre Rossi wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101859/ --- (Updated July 5, 2011, 8:32 p.m.) Review request for kdelibs and Dawit Alemayehu. Summary --- Bonus question: should this go in 4.7 or master ? Diffs - kio/kio/accessmanager.cpp ef9b8ef Diff: http://git.reviewboard.kde.org/r/101859/diff Testing --- Thanks, Pierre
