http://permalink.gmane.org/gmane.comp.kde.devel.core hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.kde.devel.core/55350 [snip] Fixed. Fixed. Fixed. Nice catch That was a bad one. =:) Thank you, Christoph! Jason 'vanRijn' Kasper 2008-10-07T04:31:49 http://permalink.gmane.org/gmane.comp.kde.devel.core/55349 Done. Allen Winter 2008-10-06T23:10:23 http://permalink.gmane.org/gmane.comp.kde.devel.core/55348 The point of metadata in slaves is to use it, or to send it back to the application; at the time of error(), there is no "use it" to be done anymore (the current operation is over), and there hasn't been a need to sent it to the app until now, since the job is over, but I guess this could be changed. Arguably, yes. In copyjob we do m_incomingMetaData += kiojob->metaData(); when kiojob emits result, I wouldn't be opposed to deletejob doing the same. You mean .protocol file? There's a webdav.protocol which defines this. http.protocol doesn't since you can't write or delete over a http url afaik. Well it's a convenience method, how is that different from a convenience class? "Expressed by existing methods" -- well, not really, if you take into account the big security check in that method (precheckHttpPost). Yep, feel free to clarify the docs. The implementation is rather clear at that place, e.g. KIO::Job::setMetaData is outgoing, it's metadata that will be sent to the slave, while KIO::Job::metaDat David Faure 2008-10-06T21:46:37 http://permalink.gmane.org/gmane.comp.kde.devel.core/55347 No it can't, although no tool would be able to find that out indeed ;) Those factories are all created unconditionally in lines 428-431. David Faure 2008-10-06T21:30:28 http://permalink.gmane.org/gmane.comp.kde.devel.core/55346 README.qt-copy is for developers, NOT for packagers. It would be a bad mistake for a distribution to follow the configuration listed there, since it's a "KDE only" setup, and indeed doesn't match other users of Qt. Well, not _that_ different. Why would "Qt compiled with xmlpatterns" behave any differently from "Qt compiled without xmlpatterns" as far as KDE is concerned? Besides, not all developerrs use qt-copy, I see many people using their distro's Qt (although I would myself never do that, since adding debug output to Qt itself is sometimes helpful to understand the way the app is using it). OK, so no change needed in README.qt-copy, current recommendation is fine as long as no kde code needs xmlpatterns. David Faure 2008-10-06T21:25:30 http://permalink.gmane.org/gmane.comp.kde.devel.core/55345 That's ok. Honestly, I don't think of kdesupport as being a build headache, which means I've either somehow taken much less notice of problems (compared to other modules), or else had far fewer problems that with other modules. If something persists for more than a few days, usually I'll try to fix it myself (which is probably a good thing, since it means I'm contributing to fixing build breakage, whereas with a tag I wouldn't be.) Matthew Woehlke 2008-10-06T19:33:15 http://permalink.gmane.org/gmane.comp.kde.devel.core/55344 I had flipped back and forth on this point. I eventually decided to leave it in the code for simplicities sake, but said that if another enormous comment like this was needed, I'd start a new document for them. I'm pretty sure QPoint is the right type for the job, but maybe "vector" is the wrong name. My "vectors" are simply offsets that can be added to a QPoint to get a neighbouring point. I knew eventually somebody was going to call me on that. I have an aversion to switch statements: I find them clunky and hard to read (no braces) and I have a tendency to forgot break statements which can be pretty painful to debug. I also work with Python quite a bit, which doesn't bother with a switch statement. But when in C++land do as the C++ers do, I guess. Well there is the handbook :) , but I realise that almost nobody reads the documentation. I had looked at doing a tutorial earlier in the development cycle, but put it aside as a "maybe later". The issue with tutorials and demo modes is that they tend to b Parker Coates 2008-10-06T19:33:00 http://permalink.gmane.org/gmane.comp.kde.devel.core/55343 Hi Parker, First impressions of the code are good. Easy to read and mostly self-documenting. Fiddly parts like the Killbots::Engine::moveIsSafe() method have good comments to explain the algorithm - although if it goes on to more than a page or so it might be worth putting it in a text file somewhere else. Some small points: - I'd suggest using a QSize or a custom class rather than a QPoint to represent a vector, since its about magnitude in different directions. - Where you've got code like: if (value == EnumValueA) ... else if (value == EnumValueB) ... ... Consider using a switch() statement instead. This has the advantage that the compiler will warn you if there any enum values which you haven't handled. Regarding the game itself, I think it would be useful to have a simple, preferably graphical tutorial available for people who have not played the BSD robots game that KillBots is based on. This applies to quite a lot of games that are shipped with Ubuntu. The description often reads something Robert Knight 2008-10-06T17:56:31 http://permalink.gmane.org/gmane.comp.kde.devel.core/55342 Yes, please commit. Allen Winter 2008-10-06T13:56:50 http://permalink.gmane.org/gmane.comp.kde.devel.core/55341 Those suggestions are all well and good, but they're also way out of my league. I'm just a selfish app developer proposing to add this method so that I can call it in my own code. I don't care where the number comes from, as long as I don't have to hardcode it. ;) Making all three of these methods theme and/or font size dependent seems like a good idea to me, and if someone with the time and know-how wanted to do so, that'd be great. But it seems unlikely to happen before 4.2, so I'm proposing we use a constant 16 pixels for the moment, so code can start using it. If a more advance solution happens in the future, everyone will get the benefits automatically. Parker Parker Coates 2008-10-06T13:36:50 http://permalink.gmane.org/gmane.comp.kde.devel.core/55340 fixed fixed fixed Allen Winter 2008-10-06T12:18:37 http://permalink.gmane.org/gmane.comp.kde.devel.core/55339 When KIO was designed, back in KDE 2 days, the semantic was that which I described. There was no REST those days. And SMTP isn't really a filesystem, so someone chose to implement the sending of email using the standard "put" operation. You may notice that there's no "get" for SMTP. In any case, libkio went mostly untouched for the KDE 4 porting effort. Aside from the porting to Qt 4 and KDE 4 lower libraries, plus a cleaning up that I did, nothing happened. Given that track record, I expect KDE 5's KIO to be exactly like that again. Mostly because it just works and it isn't "sexy" to touch the I/O internals. Thiago Macieira 2008-10-06T07:28:52 http://permalink.gmane.org/gmane.comp.kde.devel.core/55338 Having a method to get the spacing is good, since it is something that should not be hardcoded (think higher resolution displays or small devices). But wouldn't it be better to be a property of the style? In this way it would be possible to use smaller spaces on small screen/small resolution displays, with a customized style. Other than that, why is this size specified in pixels? I think the font size should be involved in its calculation. Can it be expressed in function of the x height of the "normal" font, or the linespacing of the "normal" font? Luciano Montanaro 2008-10-06T07:17:50 http://permalink.gmane.org/gmane.comp.kde.devel.core/55337 Am Montag, 6. Oktober 2008 08:12:35 schrieb Thiago Macieira: Wrong. Please consult part 2 of the specification where it clearly mandates the implementation of both POST and GET. But in the context of this discussion, it doesn't matter. What matters is that SOAP operations process data instead of working on locatable resources. The semantics of PUT is that a resource is stored and can be retrieved from the same location (barring a 301-PUT where it can be retrieved from another location). The semantics of POST is that some processing is done with the data, not necessarily that it is stored. A 204-POST processes without giving feedback other than a confirmation. Exactly what you described above, hence SMTP follows POST semantics and not PUT semantics (especially since essentially all MTAs modify messages by design, adding Received headers and whatnot). POST semantics doesn't imply "downloading data". The result might refer to a newly created resource, but it doesn't have to. Please read section Josef Spillner 2008-10-06T07:02:19 http://permalink.gmane.org/gmane.comp.kde.devel.core/55336 Hello, The latest KDE HIG offers using a vertical space of 16 pixels as an additional method of grouping logically related items in a dialog. [1] Rather than have this 16 pixel value hardcoded in dozens of different dialogs, I propose adding a groupSpacingHint() method to the KDialog class. [2] This is a static method that returns a constant in the same vein as KDialog::marginHint() and KDialog::spacingHint(). The attached patch adds such a method. Any comments? Parker [1] http://techbase.kde.org/Projects/Usability/HIG/Form_Label_Alignment#Grouping_related_options_within_a_GroupBox [2] I realise that KDialog isn't necessarily the most logical place for these functions to live, but spacingHint() and marginHint() are already there and placing groupSpacingHint() anywhere else would be even less logical. Parker Coates 2008-10-06T06:48:13 http://permalink.gmane.org/gmane.comp.kde.devel.core/55335 Hi, I've removed all items that got feedback to make the list shorter. ------------------------------------------------------------------------------- The following items are for revision 864329: - kdelibs/kate/completion/katecompletionconfig.cpp:226 kdelibs/kate/completion/katecompletionconfig.cpp:176 If the condition in line 225 is true for the first iteration then the shift amount is i - 1 == -1 in line 226. This is invalid. - kdebase/workspace/ksysguard/gui/SensorDisplayLib/SignalPlotter.cc:635 Line 604 indicates that mVerticalLinesDistance can be 0. If this is the case and the execution reaches this line, then a devision by 0 is the result. - kdebase/workspace/ksysguard/gui/WorkSheet.cc:548, 551 If the condition in line 538 is false then newDisplay is NULL here. - kdebase/workspace/powerdevil/kcmodule/CapabilitiesPage.cpp:205 There is no need to confuse the reader and use the bitwise-or here. - kdebase/workspace/powerdevil/kcmodule/CapabilitiesPage.cpp:304 If line 270 is false and line Christoph Bartoschek 2008-10-06T06:48:18 http://permalink.gmane.org/gmane.comp.kde.devel.core/55333 SOAP's HTTP transport is always POST. But that's just the transport: even for obtaining data it uses POST. I would argue that SMTP sending (even according to your description) is "put", not "post". It sends something and maybe it'll give you a confirmation and an identification. That's all. HTTP's POST is a special kind of operation that both uploads data and then downloads it. It's not something you'll easily find in other protocols. That's why it's "http_post" in KIO. Thiago Macieira 2008-10-06T06:12:35 http://permalink.gmane.org/gmane.comp.kde.devel.core/55332 The attached patch to KConfigDialogManager causes the tooltips to be pulled from the kfcg file just the as the whatsthis text already is. If the tooltip has already been set in the UI file or the C++ code, it will not replaced. Is anyone opposed to me committing this? It seems like this must have been the original intention. Parker Parker Coates 2008-10-06T05:40:43 http://permalink.gmane.org/gmane.comp.kde.devel.core/55331 A Diumenge 05 Octubre 2008, Tobias Koenig va escriure: Commited. clear is slower than = if you know token is not null. Albert Albert Astals Cid 2008-10-05T22:21:29 http://permalink.gmane.org/gmane.comp.kde.devel.core/55330 Am Sonntag 05 Oktober 2008 21:16:20 schrieb Thiago Macieira: We either want to offer an abstraction layer with KIO, or we don't. From what I can see data can either be put somewhere, or it can be given to a service to do something with it. In this regard, a HTTP POST is highly similar to sending mail by SMTP or calling a SOAP operation. They all do something with data without any guarantee to give it back to you. Josef Josef Spillner 2008-10-05T21:06:51 http://permalink.gmane.org/gmane.comp.kde.devel.core/55329 Hej, Why not token.clear()? At least that's what is recommended by krazy IIRC. Ciao, Tobias Tobias Koenig 2008-10-05T15:53:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.kde.devel.core