Re: Setting up a Quality Team within KDE
On Thursday 12 April 2012 21.01.53 Alexander Neundorf wrote: We use Squish at work and it works well. I've been on many projects and often the project manager thinks they need squish, but in the end it just doesn't have any positive impact on the product or the quality. The most recent project I was on for almost a year had a whole testing team and they have tried to get our Qt app to be tested using squish, this is a project that followed very specific UI specifications so its a dream to have the squish kind of testing for it. In the end it was hardly used for mostly technical reasons, and we never got to a point where we had a positive report of a regression. And we certainly had regressions ;) The tool just never found them. Its not squish itself thats a problem per sé, its the concept of testing the way the application looks which is broken by design. I think it would be good to avoid spending resources on this. -- Thomas Zander
Re: Question about unittesting
On Sunday 08 April 2012 22.57.05 Thomas Lübking wrote: I think he wants a macro to execute a branch only in debug compilation mode, ie. he's probably looking for Q_ASSERT(deleteSuccedded(path)); or in doubt sth. stronger than debug that only acts on testing, ie. a global cmake option TEST_MODE, so that he can # if TEST_MODE if (!deleteSucceeded()) qFatal(my code is crap); #endif compiling a different exe for testing that behaves differently sounds bad to me. What we do often is write code like; #ifndef NDEBUG do some extra stuff here to test everything is going Ok. #endif This code should not change the behavior of the app, other than maybe asserting. The reason for that is that its really hard to maintain an application that behaves differently in different compilation modes. This is why we use QTextLib based unit tests; kevin pointed out great links to those already. -- Thomas Zander
Re: RFC: i18n: strict translation call-to-catalog mapping
Quoting Chusslove Illich caslav.i...@gmx.net:
[: Thomas Zander :]
I like that idea in general, not sure how to implement it properly,
though. Simplest idea is to make cmake generate a klocale-{module}.h
file and make everyone include that. But that sounds like a lot of work.
Actually I have nothing against providing any kind of special support on
CMake side, for whatever reason.
Good, I think both ossi and I feel thats the way to go.
But this must be technically optional. The library interface must provide a
build-system agnostic way to map i18n calls to specific catalogs.
Agreed.
In my exact example-solution the user either includes klocale.h for
traditional or klocale-plasma.h for his library (plasma in my
example). Can't get more optional than that ;)
My worry with it is that its confusing to have to include a different
header in different modules.
It does have the advantage of being really easy to auto test and stay
consistent.
--
Thomas Zander
Re: RFC: i18n: strict translation call-to-catalog mapping
On Tuesday 03 April 2012 20.05.14 Chusslove Illich wrote: At present (and since forever) it is practically indetermined from which catalog exactly an i18n() call will fetch the translation. All loaded catalogs in the process are tried in mostly arbitrary order, depending when and which library loaded them, and the first one that contains the translation is used. Hmm, this looks bleak, I'm kind of surprised by this, though. Let me explain; First, any Qt tr call has a context (typically the class name), am I correct that i18n() still does the same thing? In that case the context AND the translation string together are searched through the collection of catalogs. I'm wondering if you have any numbers on how often conflicting class names (and thus context names) appear in our frameworks. Next to that, I'm wondering how many catalogs we expect any normal app to actually load at runtime. I would think that most processes load 3 at most currently, maybe double that in frameworks. it becomes untollerable in the scope of Frameworks. So the question is how to fix this. Can you explain a bit more how things are untollerable? In my experience the current system scales rather well, but I could definitely be missing details here. -- Thomas Zander
Re: RFC: i18n: strict translation call-to-catalog mapping
On Wednesday 04 April 2012 21.11.22 Chusslove Illich wrote: First, any Qt tr call has a context (typically the class name), am I correct that i18n() still does the same thing? It doesn't: context is added manually, when judged or reported to be needed. (And this is how it always was.) Just to be clear; I am talking about the 'context' as used in the first argument to QCoreApplication::translate() method. Having the frameworks-libs always specify that (you can probably write a unit test that fails if this is not done) sounds like the best solution to me. Then any app string will never resolve to a string in any framework. -- Thomas Zander
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Friday 23 March 2012 19.39.26 Albert Astals Cid wrote: 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. I agree with David here, the fact that people don't use them does not mean we should aim at using them. And people don't use them because most people probably doesn't know, this can be attributed to a lot of things, like for example us not having a proper style guide where you would write Each time a filename appears in an user visible message write filename%1/filename. Other reason is developers not caring about consistency much, we could easily gather some non-hardcore developers to go other the various i18n messages of a given app and fix them. Looking at the numbers I'm not sure your optimism is warrented; this feature has been around for many years and its documented on techbase yet its being used in very very low numbers. (333 times in all of KDE for the filename tag..) Sure, it may be ignorance. Frankly, I didn't know about this feature. The fact that developers didn't know about this feature is just as much education as that they never needed it and asked how to do it. I think its nice to be optimistic and think that we can get people to fix their UIs and suddenly get people to care. But can we be certain enough of succeeding now where we clearly failed before that this is actually worth stopping the innovations that Chusslove is working on? Read those numbers again; its kinda depressing really; Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances). -- Thomas Zander
Re: [GSoC] KWin colour management
On Wednesday 21 March 2012 20.34.00 Martin Gräßlin wrote: Personally I would not make inclusion of code a pre condition for the success of such a project. Upstream inclusion of code is a high goal for contributors anywhere. Not many GSoC projects reach that immediately. If you don't aim for inclusion into KWin, I seriously do not see why such a project is needed. Given the changes inside KWin I doubt any of the code could be reused let's say a year later. Thats a very good point, one that may not be quick to grasp by potential gsoc students. This point should be made very clear otherwise I fear people might get very dissapointed if their work ends up being discarded. Discarded because the initial setup wasn't thought through. I would say that the core aim of the GSOC project should be inclusion in kwins tree for any KDE people to spent any time on this or even support it. Otherwise it would be unfair to various people. Like the student and the hosting org and also to the kde volunteers helping with it. Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) Color management in Qt is a bit of a weird statement; first of all, support is already possible as Krita proves. Second, I doubt that 94% of the widgets actually need color correction of the type that kwin could provide. Who cares that their text edits and their buttons are color correct? Its only for canvas-like widgets that this is relevant, and apps have that option already by linking to LCMS. So, KWin support would just be a shortcut. A one-stop solution to make all apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its a shortcut. So please keep treating it as such. When people talk about the toolkit adding support its more about convenience APIs. Think a QPainter method to set a color transform to do correction on following draws. When people want support in the toolkit, they want the color selector widget, the print preview widget etc, that come with Qt to natively use the monitor profile. Last, they want the printing to take color management into account. All of those are possible and likely even welcomed in Qt. The only thing is that someone has to actually do it. So saying that it won't happen in Qt6 is a self-fulfilling wish, and I feel its not very fair to plant that doubt in peoples minds. What would KWin people suggest how and where to place this feature near KWin? Well the question is whether such a feature is needed at all. I would say: * either correct the whole screen * or let the windows handle it Now it becomes quite simple: there's an app doing color correction itself. In that case we can safely assume that the user wants the app to take care - compositor does no longer color correct the screen. There is no application taking care of it: compositor renders the whole screen. Sounds good to me. -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 20.31.30 Lamarque V. Souza wrote: I said I wanted the most versatile, which means one that satisfies my needs and somebody else's needs. The requirement for 'most versatile' doesn't follow in that sentence. You are making a logic error, or at least taking the biggest car and hoping it will get you there fastest. If you want to satisfy your needs, try it for a while and see if it works. You are completey ignoring the fact that there are people using oyranos too, it has been developed for years, do you think it's fair to drop all that work now? Hmm, you pose lots of questions that are completely off-topic here. And jumping to weird conclusions about dropping work is just unhelpful. I am in favor of adding support to both colord and oyranos in kdegraphics. I strongly disagree with that. KDE is not a support group where lonely software goes to get more recognition. This community works based on choosing solutions that work best. Your suggestion to not choose is therefore not helpful. And no, I have not tested either of them Then I'm sorry to say, your opinion is just that, one uninformed opinion. At minimum read this; http://www.freedesktop.org/software/colord/intro.html And tell us if there is any reason to say that this product does *not* satisfy your needs (when the KDE stuff is finished) nobody is an expert in color managament to judge the merits of either project There are not a lot of experts on the topic, no. I've been doing my first physical monitor and scanner calibration back in 1999, on the Mac. (with a Barco monitor). I've been reading many (beautifyl) books and I'm nowhere near an expert at all. From a software engineer point of view there is a good solution; as I *do* have the basic information needed, and thats easy to get to for everyone else as well. Read the above linked page, for instance. Basic design of system color management is that each input (scanner etc) and each output (monitor, printer) has to have assigned a personal color profile. Applications that are capable of doing color management have to have access to those profiles so they can use them in combination with a library like lcms to do the right thing. Colord embraces that concept and provides all we need. Oyranos makes things ... complicated. See; http://www.oyranos.org/doc_alpha/index.html -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
Quoting Daniel Nicoletti dantti85-...@yahoo.com.br: So how do we go into the merit discussion without creating yet another flame war? I'm sorry, but merit has to be the metric, that's the basis of both open source in general and KDE specifically. I'd like KDE to avoid sliding towards a social support group ;) We had a little talk about those two projects recently on k-c-d as well, where colord was proposed and Kai used that opportunity to plug his project. I then went and downloaded both codebases and looked at them. First thing that I'm worried about is that the whole project is designed around user roles (called policies). As I have been involved with KDE usability I have seen discussions and concepts of user roles a lot. Frankly, they don't work. There is almost no research to support them, there is plenty of research stating they don't work. Then there is the technical dependency tree of Oyranos; this shows a subsection of its deps; http://pkgs.org/fedora-16/fedora-x86_64/oyranos-libs-0.3.1-1.fc16.x86_64.rpm.html Thats a lot of dependencies; some of them anything but easy to find packaged. Compare to http://packages.debian.org/wheezy/colord All of this could be ignored, as long as there is real cooperation and willingness to work together; so I looked at how lively the Oyranos community is. http://sourceforge.net/mailarchive/forum.php?forum_name=oyranos-devel I don't know why colord was created instead of working with Kai on his mostly one-man project, it may have been for very good reasons, it may have been just not-invented-here. But the end result is that the new project is quickly replacing the longer existing one both in developer community and in usage. And thats a good point; how many people use it in the wild? I find the debian popularity contest insightful; http://qa.debian.org/popcon.php?package=colord If you don't have a good idea what those numbers are, compare to; http://qa.debian.org/popcon.php?package=k3b or http://qa.debian.org/popcon.php?package=kdebase-workspace both of which have a lower install score than colord. So, last time the colord and oyranos projects where mentioned on kde-core-devel, this amounts to the data I looked through and got my impressions on. I personally came to the conclusion that KDE is probably better off by focusing on colord, even if there is currently no KDE gui for it. -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
Quoting Kai-Uwe Behrmann k...@gmx.de: I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am pretty much just rewriting it with Qt/KDE libs. OpenICC colour experts have then a different view of maturity. Kai, the two projects clearly have a different set of ideas about what they should do. Which is fine. What is not fine is write statements like the one I quoted above, you imply bad things about Daniel personally (his view of what is mature) which makes this a personal attack. In KDE we want to focus on the facts. We talk about merit. While its fine to give an opinion on a (technical) idea, the above is not acceptable. Please respect these values we hold dear here in KDE :) -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 16.59.55 Lamarque V. Souza wrote: Colord is not wide used in KDE and since oyranos includes a wider feature set I guess it is more usefull for a wider range of users. This assumption seems to not be supported by the documentation. The specific set of user-groups also speaks against this assumption. As said in other e-mails colord is required in Gnome3, so why not add oyranos to kdegraphics since other KDE software already work with it? I'm not following this sentence; becaues gnome uses X, kde should not use X. If thats what you are saying, I want to say I disagree. Could you explain what you mean with the since other KDE already works with it part? AFAIK there is no KDE software that would function better with oyranos than with colord. Which means there is no clear advantage on that basis. Am I missing some piece of software? -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote: Hi! Colord - just to mention that - is also not a GNOME project, it's a FreeDesktop project. (Doesn't mean it's standard, but does mean that it's not GNOME) Well, no, having something on freedesktop.org doesn't mean it's not a gnome project; Little semantic confusion here :) He said it *IS* a freedesktop project. Which means it is not a gnome project, which seems to me to be true. it is a gnome project, and it's widening its scope. The reason it's used at all is that is is used inside gnome. Projects should be judged on merit, irregardless of who pushes it. If gnome is using it and that makes it grow acceptance, thats a good thing in my book. Why; *because* acceptance is growing. I don't care if its gnome or any other player pushing it. That said; Cups also depends on colord. And IMO that has a bigger impact than the gnome components that pull it in. -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote: Am 14.03.12, 17:46 +0100 schrieb Thomas Zander: On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote: Colord - just to mention that - is also not a GNOME project, it's a FreeDesktop project. (Doesn't mean it's standard, but does mean that it's not GNOME) Well, no, having something on freedesktop.org doesn't mean it's not a gnome project; Little semantic confusion here :) He said it *IS* a freedesktop project. Which means it is not a gnome project, which seems to me to be true. It was developed specifically for Gnome Color Manager and then turned into a Glib depending library. So it bears all the specifics in it's concept. Notice I still maintain that we should judge a solution on merit, not on who pushes it. That said; Cups also depends on colord. And IMO that has a bigger impact than the gnome components that pull it in. colord print CM: CUPS does not depend in any way on colord. This opinion seems to conflict with the facts stated by others. Debian for instance has 'rec' (recommend) colord for cups.[1] Notice that colord allows components to use it without linking it in at startup using the dbus interface for instance. But colord depends on CUPS to support it's concept of placing colord's session centric configuration into each job on server side. Which makes total technical sense. No color management system will work 100% without support in the individual components. If Cups needs to be patched to support a new feature, that sounds sane to me. Does it not make more sense to have color management support in cups than cups support in the color management software? It certainly does to me :) It does not scale well and will likely be difficult to maintain. As someone that is also a software developer, I disagree, with the reasons I wrote above. :-) Bottom line for me really is that a project that has been around for a year has managed to grow fast and get accepted widely. Some may argue thats because of political issues, but in the end thats not really relevant. The end result is still 'market' acceptance. As mentioned before, accepting kolormanager in kdegraphics is kind of a no to colord. And I think thats would be cutting our own fingers. 1) http://packages.debian.org/wheezy/cups -- Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote: The wiki page somebody pointed to mentioned that colord is linux-only, while oyranos also works on Windows and OSX. If we chose colord, how does our solution for Windows and OSX look like ? Does kolormanager work under Windows and OSX ? Matthias answered your question very well, and I agree with him. Let me ask you a return question; with the heavy dependency on X11 in oyranos but with colord already starting work on wayland, how will we support wayland soon? -- Thomas Zander
Re: Re: DrKonqi improvement idea
Quoting Ben Cooksley bcooks...@kde.org: Whilst I have not evaluated it's compatibility with Bugzilla 4.2, I do not suppose anyone has looked at https://launchpad.net/bugzilla-traceparser ? The traceparser might be a good-enough solution for finding duplicates and helping the reading of backtraces, yes. This thread is a bit more about solving the inital problem in a different way since the actual usage of bugzilla for processing backtraces is something that we probably want to sidestep in the first place. Here is why; * users that get a crash have to have a bugzilla account already if they want to give it to us. This is a problem because developers don't get a good insight of how often things crash due to this higher level of contribution. Yes, reporting a backtrace makes the user a contributor! * users that get a crash are asked to themselves figure out if the trace is a duplicate and are offered the option to add a cc instead of a new report. This is a problem because users are not capable of doing this and it feels less-then-helpful to just cc yourself on a bugreport, which means a lot of people just choose the safe route of creating a new report. * bugzilla holds backtraces as plain text in comments. Often mixed with user-typed text. This is a problem because it makes parsing and generating statistics and automatic re-assignment near impossible. Consider how many ark and konq bugs there are that are actually a crash inside of a random kpart... * bugzilla is meant to be for developers, users find it provides an overkill of info and getting simple disable feature X to stop the crashing is just impossible to communicate with the user right now. * reporting to bugzilla means we have exactly one place where *everything* kde based goes. A monolithic database shared by hudreds of projects with 15 years of history. This one is thinking ahead, thinking about the future handling of project tasks and bugs and attacking the general dissatisfaction with mozillas bugzilla tool (which I won't address here). This database usage is a problem because it means the data is unavailable for innovative (read; not yet invented) usage in project-specific task-handling. Its also a problem for groups or indivuduals that are geographically too far from bugs.kde.org to have nice response times. Ideally the improvement idea that I see forming in this thread makes people stop reporting all backtraces to bugzilla but instead go to a component that solves all those issues and one that distills the inflow of traces into a limited number of issues. Those limited number of issues can then be made into bugzilla tasks which are handled as normal. So, I'm interested (and active) in solving this in a way that is only a little related to bugzilla and get free from the thinking imposed by bugzilla. -- Thomas Zander
Re: DrKonqi improvement idea
Quoting Niko Sams niko.s...@gmail.com: On Mon, Mar 12, 2012 at 17:32, Thomas Zander zan...@kde.org wrote: On Monday 12 March 2012 16.20.00 David Jarvie wrote: 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 was thinking about this a bit longer today and we[1] might do something smart like letting the webapp generate a url thats unique for this person , or the report and that url is his status page that will then get updated when something new happens. A plasma app can use polling at regular intervals to then show the user how his report progresses, including links to suggestions like fixed in ver xyz or workarounds like; don't use files with å or é in them.. Well, we have to see how fast a duplicate search can be done. Maybe there could be a quick search that provides a immediate solution (if available) and a better slower background search. Good idea! -- Thomas Zander
Re: DrKonqi improvement idea
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. Naturally, the actual automation means research and development, which means manpower. I didn't get from your email if you wanted to volunteer for some of this work :) Personally I'd go for a solution that also tries to register the last 20 keystrokes and 20 mouse clicks (qt global event listener) and if and when a crash occurs that info can be send with the backtrace. So even if there are no debug packages installed we get some info to do data-mining on. 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 ;) Either case, I'd think you want something custom written. Its not too much work to do the basics and maybe we can steal some code that compares backtraces and steal some ideas or code for on-disk data-store of those backtraces. Niko, I'm wondering if you can help out with realization of your ideas, and if you have php or perl skills for instance. I might find some time on my hands, and it sounds like a fun (and needed) project so I could help out. Cheers -- Thomas Zander
Re: Please avoid noisy merge commits in frameworks
söndagen den 19 februari 2012 14.36.07 skrev Stephen Kelly: I was reviewing the changes in the frameworks branch from yesterday. Something I noticed was that there are a lot of merge commits that don't need to exist. Heh, sounds familiar, the same thing was brought up when Qt switched to Git :) I think the following simple rule should be presented to committers, but in general these merges can be ignored in listings so its a problem that can be solved on both sides. Now the rule; If you have done commmits and *no* branching work at all, you should pull using; git pull --rebase The 'no branching work' is what 90% of the contributors will do, they just work on one branch all the time. -- Thomas Zander
Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 09.05.32 Dario Freddi wrote: if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc [] That said, I am in favor of moving to Qt 4.8 for a simple reason: I believe both of you are right, but you are missing a point: the occasional contributor is very likely to work in a branch. Dario, you seem to have skipped over my main argument. This is not *just* about code- contributors, although they make a very strong point too. Instaed think of the impact this has on all the groups I mentioned above. Artists trying to follow development. Translators trying to run stuff in order to figure out where a string comes from. Simple bugreporters that have little technical savy but can try out if a bug is still reproducable in 'master'. What some people here are arguing is that its Ok for a huge group of people that help KDE get better to have to wait for various months before they can compile KDE master again. And I want you to think about that long and hard because you may be underestimating the positive influence that group has on our community. Kind of a postscript I just wanted to reply on your argument for a branch. It doesn't in practice apply to the guys coming in with a simple bugfix. Their starting point will very likely be the current main branch. -- Thomas Zander
Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 10.11.58 todd rme wrote: But according to Martin, this isn't just about API changes, it is also about behavior changes. How do you expect people to know if they are relying on a Qt 4.8-specific behavior? As far as I know there are no forward incompatible behavior changes between Qt4.7 and Qt 4.8 I.e. AFAIK programming for 4.8 using 4.7 APIs but 4.8 behavior will give the same behavior on 4.7.
Re: hard-dep for Qt 4.8
On Thursday 19 January 2012 08.15.39 Martin Gräßlin wrote: As far as I know there are no forward incompatible behavior changes between Qt4.7 and Qt 4.8 I.e. AFAIK programming for 4.8 using 4.7 APIs but 4.8 behavior will give the same behavior on 4.7. What comes to my mind is multi thread support for QtOpenGL [1]. That is using threaded OpenGL with Qt 4.8 will work, while it fails with 4.7 without rendering a compile error. The enum Qt::AA_X11InitThreads is not available in 4.7, which enables the functionality mentioned in the blog. Using that would give a compile error. -- Thomas Zander
Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 06.35.57 Martin Gräßlin wrote: I didn't say that this is a reason. I wanted to highlight the problem of not depending on 4.8 and everybody using 4.8. I'm not going to start reviewing code for is this a Qt 4.8 change. Martin, if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc. I just wanted to point this out since your attitude can easily be mistaken as not caring about the people that are not able to do the Qt upgrade. I do believe you care, and thats why I think its important to indeed put in that little bit of extra time to make sure we don't use Qt4.8 APIs. Or just respond fast to a person noticing the compilation issue. Its not a whole lot of effort, as far as I can tell, but it does have a pretty big influence on our community members that may not have the computer power or computer savy or just the time you have. thanks :) -- Thomas Zander
Re: hard-dep for Qt 4.8
torsdagen den 12 januari 2012 22.50.24 skrev Ingo Klöcker: If you want developers to switch to Qt 4.8 to get the KDE code better tested with this version of Qt then simply ask developers to do so. I see no good reason to force developers to do so. +1 -- Thomas Zander
Re: Review Request: Port shutdown dialog to QML
On Wednesday 04 January 2012 20.54.27 Alexander Neundorf wrote: It would mean that simply using kdeclarative means that cmake interprets this as name of a library and simply adds -lkdeclarative to the command line, without checking whether it actually exists nor in which directory. I can confirm that this is what happens; it took me quite a while to figure out why stuff didn't compile due to that missing lib. I'm definitely in support of making this a configure check using the Find* cmake file.
Re: ktouchpadenabler moved to kdereview
On Wednesday 04 January 2012 21.55.36 Lamarque V. Souza wrote: My question is: since you know how to send patches to Qt's repository wouldn't be better just send my patch upstream (it is here https://bugs.kde.org/show_bug.cgi?id=182672) Contributing to Qt is a simple matter; after a simple setup procedure that takes a little time (with reading, and asking on irc, it was less than an hour for me) you can get your patches in into Qt very quickly nowadays. Start here :) http://wiki.qt-project.org/Setting_up_Gerrit
Re: More devices into the Shortcut system...
måndagen den 26 december 2011 01.36.47 skrev Albert Astals Cid: Ok, so after half reading the walls of text and this email what i think that actually what you and Rick suggest are different but not exclusive, Rick suggests improving existing Qt classes so they can handle a few more cases, you suggest creating a new plugabble framework to handle everything, if i was to choose i'd choose both :D But obviously i'm not the one choosing since i'm not the one doing the coding nor I am an expert in the field. Thanks Alberg for the high-level-overview! Altering Qt classes is going to be tricky since the feature-freeze in Qt is coming very very quickly. (mere weeks) So unless this can be done binary-compatible this change will likely have to wait for Qt6 ;) -- Thomas Zander
Re: kactivities update
On Thursday 08 December 2011 17.12.05 Kevin Kofler wrote: Aaron J. Seigo wrote: yes, i skipped the details. done properly it should be linking libkactivities. this is an acceptable short term work-around given it's in a branch, while doing it right requires the modularization to be complete for at least libkactivities dependencies. Or it'd require just building everything as one package as we've been doing before, which is the easiest way to avoid circular dependencies… Modularization keeps causing problems like this. Kevin, you have brought up your points and made your position very clear on this and related topics in your 15 mails or so in the last month. The result of you bringing them up has been that people thought more about the proper way to do it, but one point has been made clear. The direction of modularization will continue and is supported by a lot of people. I find it also quite funny that the very people complaining about distributions patching in features into their kdelibs are doing that very same thing as part of their Plasma Active distribution… A sentence like this, that implies an accusation but doesn't straight out say so is not helpful. Its close to being disrespectful. If you want to have an influence in KDE, in its direction and its quality and if you want to enjoy feeling part of a community as wonderful as KDE, this kind of talking is not very helpful. Please be part of KDE, in a positive way. :-) Thanks! -- Thomas Zander
Re: Moving libmm-qt and libnm-qt to kdereview
On Sunday 04 December 2011 10.02.20 Aaron J. Seigo wrote: i know its relatively late to bring this up, but better before a first initial release to do so: is there any chance that these libraries could get more descriptive names? there is already a libmm which is actually a shared memory helper, unrelated to libmm-qt (though the name suggests otherwise). mm and nm really don't say much about what these libraries do. the names are ambiguous and stand a high chance of collision with other libraries. +1 -- Thomas Zander
Re: Moving libmm-qt and libnm-qt to kdereview
On Sunday 04 December 2011 15.15.23 Lamarque V. Souza wrote: Em Sunday 04 December 2011, Aaron J. Seigo escreveu: On Saturday, December 3, 2011 17:48:17 Lamarque V. Souza wrote: https://projects.kde.org/projects/playground/base/libmm-qt https://projects.kde.org/projects/playground/base/libnm-qt i know its relatively late to bring this up, but better before a first initial release to do so: is there any chance that these libraries could get more descriptive names? there is already a libmm which is actually a shared memory helper, unrelated to libmm-qt (though the name suggests otherwise). mm and nm really don't say much about what these libraries do. the names are ambiguous and stand a high chance of collision with other libraries. i know that the networkmanager project decided to call their library libnm, but we don't need to repeat such errors ourselves, right? :) Well, the final goal is to move those two libraries to ModemManager and NetworkManager's repositories in the future. If I rename them now I will probably have to rename them back in the future. I think will have to ask this to NetworkManager guys now. What names do you suggest? libmodemmanager-qt and libnetworkmanager-qt? I do not see any other more descriptive name. Another suggestion is libQtModemManager and libQtNetworkManager, which follows Qt's library name convention. I think will stick to the latter. Just let me check with the NetworkManager guys if there is any problem using Qt's library name convention instead of NMs. Hey Lamarque, first sorry for the noisy '+1' email, seems I was impatient and your email was stuck in the moderation queue :) I just wanted to mention that in general longer library names are a real big help for avoiding problems, like Aaron suggested. If the network manager people tell you you should make it essentially an abbreviation it would be bad for a couple of reasons. Mostly the reasons suggested above :) It would be good to start with the names as you suggest, and I personally have no preference between the lowercase and the mixed-case ones. Lets start with a descriptive and clear name, to raise the bar. Cheers! -- Thomas Zander
Re: Frameworks mailing list
On Sunday 20 November 2011 12.49.46 Thomas Friedrichsmeier wrote: so, if we're very honest with the situation, what some people are actually asking for is their feature to be released sooner, freeze and devel plans non- withstanding. [] we already have a consensus position, we already have defined our compromise points ... we need to work on the respect. True. I wasn't trying to justify that sort of discussion. But the point is: Transitions like this are painful, and some people are going to yell about it. That's just a fact of life. It can be mitigated to some degree, but in general, whatever you do, you will not be able to silence this sort of fruitless discussion, entirely. We can't avoid people objecting, and thats perfectly fine as we want the feedback from others. Nobody wants to silence al voices. The line to be drawn is when the I want my feature in slipps from a simple opinion into a discussion. You can't work if every decision is reopened every time someone wants to challange it, and our community can't work if a decision is made without any means of giving feedback. There has to be a balance. The reality is that the amount of voices that can doubt a decision is many times greater than the amount that can defend it. So the balance has lean more towards those that do the work. To keep K-C-D productive we should all be able to say that when a discussion has been had, has been closed and a decision is made by those that do the work it should be made easy to continue on that path and hard to diverge. And currently k-c-d has the opposite effect, and has had for year. And to point out one more problem of working in a crowd: Those discussions tend to pop up in a thread that starts with a suggestion of some feature, then turn into a debate of why that feature can't be released in a kdelibs 4.8, then into a flame war of how this is all completely intolerable. You can't blame contributors who are only lightly involved, and who are not directly interested in the initial topic, for skipping such threads right at the start. In thus, other words: If you've knocked sense into one person, it doesn't mean you've educated all others at the same time. And so the next guy will not be much more to blame for bringing up the same old topic again. I agree this is an issue, and its a very real one. And I agree that we can't really expect the next guy to take this responsibility. I think your conclusions, above, are a good approach at mitigating this. But again: It is important to understand that the problem will remain to some degree. I also agree with Aarons approach, but I want to dream a bit and in that dream go one step further. What if a group of 10 or 20 people that are on kde-core-devel quite often agree on one approach that keeps the balance between decisions made by a core and the feedback from the community at large. With the bias as I wrote above. A specific example I just came up with what we can do is this; When a thread goes offtopic or a topic is started that essentially challanges a decision made in the past one person from that 20 answers with an email like this; Dear X, thanks for your email on this topic. Its always good to hear from people that are impacted by our decisions. The issue you have will be taken as a valuable measure-point to make sure we keep our past decisions actual.In the mean time we will stay on course. Thanks! And just as important, the topic should be closed by the simple act of people not replying anymore. Bottom line for me is that we move the responsibility of defending decisions and documenting them and gathering them up etc from the people that made those decisions to the community at large. -- Thomas Zander
Re: This starts to become a dangerous path (Was: New Feature for kdelibs)
On Thursday 17 November 2011 00.14.23 Scott Kitterman wrote: the best way to deal with it is not to consider it a fork of kdelibs but the next version of kdelibs (that's what it is) and help out with it I'd be interested if I could, but learning C++ didn't make it to the topof the TODO yet. I'm mostly interested in understanding how todistribute things in a functional, reliable, supportable way for all of4.x until the next generation is ready (then I'll probably be figuringout the same for it. If there is one thing to take away from the many emails, and especially Aarons excellent guidance towards the common thinking of the people doing the work, then its to not wait until Frameworks is ready. The Qt5 and kdelibs - frameworks transitions are much much less intrusive for apps than the Qt4 one and while it may take a little while to get the first stable frameworks vesion out, you can focus on frameworks already as the next version. I'm not sure why Scott is so focussed on the 4.x kdelibs and what lead to the conclusion to ignore frameworks until its ready. So I'm just saying that you should consider refocussing that attention. If you have a feature you would love to get into the common libs, you can still do what we have done for the last 10 years in KDE. * You first develop it in your own application, write the unit tests, you then stabilize it and you get more than one app to use it. * Then you get library reviews and you pick a target library to push it into. In this case this is frameworks; by default since 4.8 is closed. I'm unsure why thats an issue for anyone. Its not a huge wait, and it guarentees that your code will be in KDE for many years to come. On the other hand focussing on kdelibs which is essentially a stable branch now, will mean your code will die when apps switch to frameworks. Bottom line, I think this thread has too many talk and too little people volunteering for doing the work. And to be honest, I am not in a position to put time into this either. My €0.02 is that Aaron made clear the enormous amout of work (man-years!) and dedication it takes to do what Scott asked the kdelibs developers to do. And I'm still not seeing anyone put in the in comparison tiny fraction of time of porting the auto-download plasma thing to frameworks. Scott K wrote also; I get that what you're doing makes complete sense from your perspective. It also makes sense from the long term, the medium term and the KDE community perspectives. The short term you have to talk to the maintainer of the application you are targetting; but thats obviously off topic for this list. -- Thomas Zander
Re: The future of Power Management - together with Activities
I mean, the profile can be changed by switching Activities, so what is the technical reason it cannot be done by the user directly? The reason I'm concerned is that it takes concepts (power management policy, current Activity) which, although related, are orthogonal and then artificially combines them. As I understand the reasons for all those questions is the same; its a natural fit. I'm not sure why you wrote they are orthogonal as the two concepts are perfectly in line as far as I can tell. I've always had a slightly different take on activities, one that has not really been advertised as such, maybe my view may make the relation between power profiles and activities a bit more clear. In KDE we reached a point where various technologies needed to 'guess' what the user was doing. You can see this go back as far as the kde3 app that allowed you to register how much time you spent on some tasks. Excellent tool for consultants ;) It had a setting that started/stopped the clock based on the virtual desktop. Later we got nepomuk which makes different relations and data structures based on some settings. We got an offline mode in kdepim. Which later evolved into an offline mode in the network manager, which later evolved into the offline mode in solid. We have power-management profiles. There is a way for apps to say they are in 'presentation mode' so the screensaver doesn't kick in. All these settings *can* be managed individually, but you probably know that most users don't want do make those settings manually, everytime something changes. Anyone that is in a company with plenty of meetings knows that people don't turn off their screensaver or their ICQ/jabber when doing a presentation. So the way I see activities is that you can map a lot of those settings that are frankly all over the place onto a real-world activity. Plasma added a nice user interface for it and things suddenly became more consistent. So to go back to the initial point, in my view the power management and the activities concept are not at all orthogonal, its a natural evolution. -- Thomas Zander
Re: The future of Power Management - together with Activities
So I think there are more settings then display brightness (that you usually can control anyway with an Fn shortcut on laptops). Again, as I said before, I am pretty sure there are no settings except brightness which require you to change to a different profile - in fact, there is a reason why brightness handling works this way at the moment. You keep saying this, but sorry, I can just as well keep saying the opposite. :) Do you have some research showing this is true? If this is true, why would we have power magement configurations at all? Just as with turning off wifi with a hardware button, brightness can be changed from the hardware (well, software, but usually independent of the running OS). Certainly CPU wakeups, disk, perfipherials, etc. have an impact on battery life. What should be configurable is another thing. In perfect life, indeed we should just have good defaults. It looks a bit to me like you two are talking about different things, and they are not the opposite of each other either ;) So maybe you don't disagree after all. Point in fact; the power management profiles configure only this; * cpu policy * brightness (default, you can still adjust) * auto-suspend timeout. * button handling. So we are talking *only* about your ability to change those. Lets leave out things like 'disk' 'perfipherials' etc. since they are not what this discussion is about. They can be discussed later :) The point made by Dario is that there is no usecase stated yet where people need to create a new power usage profile. This is supported by the fact that you can and always will be able to change the brightness without changing profile. So, Andras, if you take into account that adjusting brightness doesn't require you to create a new profile or activity. Also take into account that things like turning off the wifi is just not something that powermanagement does, so it falls outside of this discussion (usage won't change). Can you perhaps state a situation where you require the creation of a power profile in order to support your usage? I think its useful to word it like that since if you are worried about a specific and exact situation you can explain, than I think this is the best way to take your wishes into account :) I have great experience with those guys changing their point of view if you can show a good usecase which they did not think about yet. Cheers! -- Thomas Zander
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 16.27.48 Dario Freddi wrote: Suppose you want to have an activity named Sleep, in which you watch a movie, and the PC will shutdown after 90 mins of inactivity. In this case, you would just specify to override the Suspend Session action. Or, you want to have an activity where you always want a profile which lets you run at full speed. You can define a whole new profile for it. Bottom line: manual profiles become activity profiles. My first response was that this would be a very hard to explain concept, but after a minute reflecting on my usecases I would say this is an brilliant solution! I have a computer in the living room connected to the TV and the stereo, one thing that annoys me is at parties the screen blanks (turns off) after some time, but I need to have it do that since otherwise it would stay on always, which is particularly disturbing at night. My usecases could now be solved by having an activity like watching TV, another thats Music centre for usage at parties and a 3rd for idle state which turns off the screen after 2 min. Thanks! -- Thomas Zander
Re: QML support in kde.org services
On Tuesday 13 September 2011 02.52.53 Giorgos Tsiapaliwkas wrote: Does anyone can point me to the qt docs system and how it works(any link?)? http://doc.qt.nokia.com/latest/qthelp-framework.html -- Thomas Zander
Re: QML support in kde.org services
On Monday 05 September 2011 15.32.03 todd rme wrote: On Mon, Sep 5, 2011 at 3:20 PM, Stephen Kelly steve...@gmail.com wrote: todd rme wrote: What about adding qdoc support to doxygen? -Todd You would have to investigate if that's possible? Are you volunteering? :) I don't know enough about either to attempt that, I just thought it might be easier than the two alternatives that seem to be available. As I understand it, its not that hard to do by having a little script we put in kdesdk (or whatever is used on docs.kde.org). See point 12 of the FAQ; http://www.stack.nl/~dimitri/doxygen/faq.html Here is a version that claims to do this trick for cmake modules; https://github.com/saschazelzer/CMakeDoxygenFilter/ -- Thomas Zander
Re: Review Request: Change konqueror tabs look and feel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/#review6263 --- Showing less text even when you have the space for it sounds like its not an improvement to me. - Thomas On Sept. 2, 2011, 10:51 a.m., Bellegarde Cédric wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/ --- (Updated Sept. 2, 2011, 10:51 a.m.) Review request for KDE Base Apps. Summary --- This patch change konqueror tabs behaviours with fixed size like in firefox, rekonq, ... Tabs size is fixed and text is adapted to this size. Diffs - konqueror/src/konqtabs.cpp d627fad Diff: http://git.reviewboard.kde.org/r/102519/diff Testing --- Screenshots --- Konqueror patched http://git.reviewboard.kde.org/r/102519/s/247/ Thanks, Bellegarde
Re: playground-libs/libkvkontakte has moved to kdereview
On Thursday 25 August 2011 19.23.10 Alexander Potashev wrote: 2011/8/25 Albert Astals Cid aa...@kde.org: The point is that usually you do not know what the library will end up doing and by using d-pointers everywhere you make it easier for yourself to maintain binary compatibility in the future. But in the case that most classes won't grow in the future by using mystrategy (keeping d-ptr NULL when possible) we cut down the number ofmemory allocations, and also simplify the existing code that doesn'twork with the private class' data. So, I'm going to keep following thecurrent strategy. There are several cornercases known where the d-pointer and a general policy of keeping the installed header file clean is a solution. One example is when you can get problems when dynamic_cast fails to work accross libraries (i.e. in code that uses your library) if there is not enough code in the cpp file. There are several other problems, like David also wrote, where you will end up accidentially changing ABI. So if you choose to not use this approach to solving ABI consistency, may I suggest you write some tests that export the ABI at release and compare it for every subsequent release so you can avoid accidental breakages. I've been doing C++ for years, and I still accidentally make breakages when I change something I didn't expect to cause issues, its much easier to break than you might expect ;) Cheers! -- Thomas Zander
Re: git workflow draft
On Wednesday 24 August 2011 06.20.06 Torgny Nyblom wrote: My vote goes for the X.Y scheme as the repo is already under the KDE namespace. That information is lost as soon as the repository is cloned, though. As disc and bandwidth gets cheaper we'll probably see more mirror sites do full mirrors of many open source git repositories from lots of different sources, there this would get lost too. I would be happier with the KDE/x.y solution, personally. -- Thomas Zander
Re: playground-libs/libkvkontakte has moved to kdereview
On Wednesday 17 August 2011 09.24.31 Alexander Potashev wrote: If I'll add just a forward declaration like class NoteInfoPrivate; and a NoteInfoPrivate *p; into the NoteInfo class, will it be OK? I guess you mean using a d-pointer, yes, that's the suggested way of dealing with this kind of issue. So, the NoteInfoPrivate class may not have any declaration (except for the forward declaration) until it will be necessary, right? The concept of a d-pointer is a bit weird at first, for sure ;) You may want to take a peek at some examples to see how its done and steal some patterns of usage. Most C++ libraries use this, but I suggest to take a look at kdelibs for inspiration. And to answer your question; yes, its Ok to just have a forward declaration in the header file.
Re: Review Request: Do not terminate threads
On Sunday 14 August 2011 23.05.41 Albert Astals Cid wrote: #2 Your patch has several issues i mentioned there I noticed those too, and I wanted to just say that I'd trust David and Thiago on these concepts any day. Maybe we can just use the structure they suggested (and Albert coded) and move on?
Re: Review Request: Speed limit in ftp kio slave
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102267/#review5598 --- kioslave/ftp/speedController.h http://git.reviewboard.kde.org/r/102267/#comment4996 I'm wondering if the function name contains a typo; maybe you meant 'calcHowMuchToRead' (notice the extra c in calc) ? - Thomas On Aug. 9, 2011, 7:16 p.m., Tushar Mehta wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102267/ --- (Updated Aug. 9, 2011, 7:16 p.m.) Review request for kdelibs. Summary --- - This patch contains the basic code which will put the limit on download speed of the ftp data transfer. - It is looking for speed-limit meta-data for deciding how much speed control is required. - If this meta-data is not found, code will work as it was before and no speed control related code will come into picture. - This patch is the most basic one which I have testing on my system and to the extent it is controlling the speed. - Lets say if speed limit is 30 KBps then mostly will get the avg speed around 30 to 35 KBps. - I am using QTime for measuring time elapsed between two socket read call and its precision is in millisecond. Looping is taking place in microsecond and thats why I am getting almost all the time 0 as time elapsed in between two calls. - To solve the above problem usleep is introduced to make it sync with the timer. Diffs - kioslave/ftp/CMakeLists.txt e080b02 kioslave/ftp/ftp.h 0bd375b kioslave/ftp/ftp.cpp 655524a kioslave/ftp/speedController.h PRE-CREATION kioslave/ftp/speedController.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/102267/diff Testing --- Thanks, Tushar
Re: Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp
On Monday 08 August 2011 16.28.43 Dawit A wrote:
Apologies for still not getting it.. You stated you wanted to have a
timeout to avoid a blocking UI, which as
far as I understand you would also avoid if you don't create a new
method that never blocks in the first place.
The uri filter plugins, which are primarly used to filter user input,e.g. user
typing into a konqueror's address, are time critical for theobvious reasons.
The architecture for these plugins relies on a directsynchrounous call. See
KUriFilterPlugin in kio/kio/kurifilter.h.Perhaps looking at the parent of the
plugin classes will help clarifythe problem for you. KUriFilter loads all
allowed uri filter pluginsand filters the user input by invoking
KUriFilterPlugin::filterUri.
Ok, I understand your issue;
To me there seems to be a architectural issue which you are fighting. Might be
interesting to keep this in mind for kde5.
The architectural issue I'm seeing is that there is a singleton which has a
method to filter and it blocks until the filtering is done. This is at odds
with the basic ingredient of using the network.
One is blocking and can only give a result once, but the result might get
better if we wait a bit longer. For example with DNS lookups.
Anyway; lets make do with what we have :)
Another solution for using a timeout can be something like the attached
version (I didn't even try to compile it, maybe the helper object has to be
moved to a _p.h file to get moc to run on it..)
The problem that remains with this solution is that if you have 20 plusing
that all have a timeout, your timeouts accumulate and you still get bad
performance. But I don't see a way to solve that using the current
architecture.
From 09eb6196198c057245651b7057cae9c079fbeeea Mon Sep 17 00:00:00 2001
From: Thomas Zander zan...@kde.org
Date: Tue, 9 Aug 2011 12:32:55 +0200
Subject: [PATCH 1/2] fix typos
---
kio/kio/kurifilter.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kio/kio/kurifilter.h b/kio/kio/kurifilter.h
index 289b910..c773f2d 100644
--- a/kio/kio/kurifilter.h
+++ b/kio/kio/kurifilter.h
@@ -709,7 +709,7 @@ protected:
/**
* Sets the arguments and options string in @p data to @p args if any were
- * found during filterting.
+ * found during filtering.
*/
void setArguments( KUriFilterData data, const QString args ) const;
@@ -807,7 +807,7 @@ private:
* http://kde.org;.
*
* You can also restrict the filters to be used by supplying the name of the
- * filters you want to use. By defualt all available filters are used.
+ * filters you want to use. By default all available filters are used.
*
* To use specific filters, add the names of the filters you want to use to a
* QStringList and invoke the appropriate filtering function.
--
1.7.1
From f6c8ba5f390ba214172dda8faa6d00bf95414681 Mon Sep 17 00:00:00 2001
From: Thomas Zander zan...@kde.org
Date: Tue, 9 Aug 2011 12:51:51 +0200
Subject: [PATCH 2/2] Implement the hostinfo fetch using a mutex
---
kio/kio/kurifilter.cpp | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/kio/kio/kurifilter.cpp b/kio/kio/kurifilter.cpp
index 0144a2c..1049365 100644
--- a/kio/kio/kurifilter.cpp
+++ b/kio/kio/kurifilter.cpp
@@ -569,9 +569,30 @@ QString KUriFilterPlugin::iconNameFor(const KUrl url, KUriFilterData::UriTypes
return lookupIconNameFor(url, type);
}
+namespace {
+class CallBack : public QObject {
+Q_OBJECT
+public slots:
+void setInfo(const QHostInfo info) {
+hostInfo = info;
+mutex.unlock();
+}
+
+public:
+QHostInfo hostInfo;
+QMutex mutex;
+};
+};
+
QHostInfo KUriFilterPlugin::resolveName(const QString hostname, unsigned long timeout) const
{
-return KIO::HostInfo::lookupHost(hostname, timeout);
+CallBack cb;
+cb.mutex.lock();
+
+const int id = QHostInfo::lookupHost(hostname, cb, SLOT(setInfo(const QHostInfo)));
+cb.mutex.tryLock(timeout);
+
+return cb.hostInfo;
}
--
1.7.1
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/#review5517 --- This change could alter the behaviour of some windows, if they have been coded without following the api descriptions properly. I agree with your observation, people that expect the current behavior may not have been following the API documentation, just the way that the usage of their code makes their app behave. Yet, I have to side with the argument that Oliver makes that this change would be behavior incompatible. Which would not be nice for kdelibs using apps... Maybe something to schedule for a change in kde5? - Thomas On Aug. 7, 2011, 3:18 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102246/ --- (Updated Aug. 7, 2011, 3:18 p.m.) 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: Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp
On Monday 08 August 2011 18.35.13 Dawit A wrote: #2. The original functions in this class were non-blocking. It is only the new function I added that is a blocking call. And that is required because of the need for a timeout when doing name lookups from the urifilter plugins. Thos plugins perform a job that is time critical and as such cannot be impeded by name lookups that will take too long and hence the need for a timeout. If QHostInfo offered such interface, then there will be no need for the newly added functions. Maybe naive; but would it not be simpler to wrap the Qt method like this? const int id = QHostInfo::lookupHost ( hostname, receiver, slot); QTimer::singleshot(timeout, QHostInfo::abortHostLookup (id ); And do we really want a public API doing that? I would guess a private (or non exported) method in kio and/or khtml can do that. -- Thomas Zander
Re: Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp
On Monday 08 August 2011 21.02.02 Dawit A wrote: On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander zan...@kde.org wrote: On Monday 08 August 2011 18.35.13 Dawit A wrote: #2. The original functions in this class were non-blocking. It is only the new function I added that is a blocking call. And that is required because of the need for a timeout when doing name lookups from the urifilter plugins. Thos plugins perform a job that is time critical and as such cannot be impeded by name lookups that will take too long and hence the need for a timeout. If QHostInfo offered such interface, then there will be no need for the newly added functions. Maybe naive; but would it not be simpler to wrap the Qt method like this? const int id = QHostInfo::lookupHost ( hostname, receiver, slot); QTimer::singleshot(timeout, QHostInfo::abortHostLookup (id ); eh ? The version of QHostInfo::lookupHost you used above is non blocking so the entire function becomes a non-blocking function which is not what we want. In Qt (networking) stuff is non-blocking, which carries over to KDELibs using non-blocking calls. So by my reading we *do* want it to be non-blocking. The main reason I see to use blocking calls is because they are easier to use as a programmer as they allow you to avoid having an extra slot to handle the callback. Am I missing a reason for this case? Moreover, abortHostLookup is not a SLOT either. It is simply a static member function. Perhaps I am missing something here, but I fail to see how this is supposed to work. Right, its not a slot. I missed that :) -- Thomas Zander
Re: Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp
On Monday 08 August 2011 21.28.45 Dawit A wrote: On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander zan...@kde.org wrote: On Monday 08 August 2011 21.02.02 Dawit A wrote: On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander zan...@kde.org wrote: On Monday 08 August 2011 18.35.13 Dawit A wrote: #2. The original functions in this class were non-blocking. It is only the new function I added that is a blocking call. And that is required because of the need for a timeout when doing name lookups from the urifilter plugins. Thos plugins perform a job that is time critical and as such cannot be impeded by name lookups that will take too long and hence the need for a timeout. If QHostInfo offered such interface, then there will be no need for the newly added functions. Maybe naive; but would it not be simpler to wrap the Qt method like this? const int id = QHostInfo::lookupHost ( hostname, receiver, slot); QTimer::singleshot(timeout, QHostInfo::abortHostLookup (id ); eh ? The version of QHostInfo::lookupHost you used above is non blocking so the entire function becomes a non-blocking function which is not what we want. In Qt (networking) stuff is non-blocking, which carries over to KDELibs using non-blocking calls. So by my reading we *do* want it to be non-blocking. The main reason I see to use blocking calls is because they are easier to use as a programmer as they allow you to avoid having an extra slot to handle the callback. Am I missing a reason for this case? Yes. The uri filter plugins that are the primary users of this new function require a synchronous function call or they would all have to implement this syncing part individually for themselves. Apologies for still not getting it.. You stated you wanted to have a timeout to avoid a blocking UI, which as far as I understand you would also avoid if you don't create a new method that never blocks in the first place. My confusion lies in the idea that the new lookupHost method introduces blocking which we both agree will be bad for UI responsiveness. Using non-blocking callbacks using the main threads eventloop sounds like its the way to go, then. It doesn't have to be very complicated for those plugins to do; some of those uri filter plugins can use the trick of a QTimer if thats what they want. There are other solutions too, I guess I can google for other usages of this Qt class on the net and see what others did. Maybe that solution is less complicated then creating an extra thread? -- Thomas Zander
Re: Review Request: Improve Calculate/Stop buttons when folder Size is being calculated
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102149/#review5482 --- Hmm, did this get committed already? visually the change looks good to me, what do others think? - Thomas On July 30, 2011, 2:51 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102149/ --- (Updated July 30, 2011, 2:51 p.m.) Review request for kdelibs. Summary --- This patch improves the Calculate and Stop buttons in folder properties. Instead of having two buttons that are enabled/disabled accordingly, we only have one that toggles (technically there are still two buttons but it looks as if there was one) I removed that Calculating... label when there is already a size shown, instead the stop button says Stop Calculating and somehow serves as indicator. Also, I added a line-break after the Calculating... so the label doesn't change its size making the other elements moving around. I don't know if the additional icons (view-refresh and process-cancel) add too much clutter to the visual interface since this features is not sooo important/frequently used(?) that the buttons need an icon. Diffs - kio/kfile/kpropertiesdialog.cpp ba56f18 Diff: http://git.reviewboard.kde.org/r/102149/diff Testing --- Compiles and the buttons toggle (and react) fine. Screenshots --- Screenshot of the dialog while it is calculating http://git.reviewboard.kde.org/r/102149/s/213/ Thanks, Kai Uwe
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Monday 25 July 2011 07.49.17 Scott Kitterman wrote: I haven't seen anything in any mailing list posts that is nearly as aggressive as knowningly reusing a name that was in use like systemsettings. Please don't assume that was an agressive act. I can totally see that someone that goes with the assumption that a piece of software is only usable on one desktop won't have problems if you call a similar piece of software the same on your desktop. In general; please stop assuming ;) (ask politely first) -- Thomas Zander
