Re: kdeinit
On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu k...@rusu.info wrote: On 08/20/2011 02:11 PM, Oswald Buddenhagen wrote: A cross-desktop specification, but we still use kwallet. There's no reason to dump it in favour of another implementation. So I see no arguments at all in favour of dropping it -- in fact, I see more in keeping it. ksecretservice is a new implementation. dunno how much code was reused. the arguments against two backends are easy: - two backends means almost twice the work, including security auditing - assuming the backends use different storage (it's not part of the spec, after all), even after switching desktops you need to stick with the now alien password manager. KSecretsService is a new implementation. It has a new backend that organizes secrets in collections and follows the freedesktop.org specification. KDE applications will use the new KSecretsService client library that'll replace KWallet API. I'm currently rewriting the KWallet class in order to get it use this new KSecretsService Client API. The backend (or daemon) will also be able to import kwallet files. So in the future the kwalletd will become useless. The KSecretsService Client API will be able to connect to whatever service will expose the freedesktop.org secrets service specification on the DBus. That means that KDE applications will be able to store passwords in gnome-keyring if present instead or ksecretsserviced (this is the name of the daemon exposing fd.o secrets specification currently under development). Great! This should be very helpful A few general questions: 1. Will it be possible to add connections to password providers, like online password management services or firefox, that allow those passwords to be integrated with secretservice? Or is this something that would need to be handled at the frontend (ksecretserviced) level? 2. Is secretservice integrated with PAM so that the passwords can be opened on login? Or is this also something that needs to be handled at the ksecretserviced level? 3. Will gnome-keyring and ksecretserviced by storing their passwords in the same location or file(s), or will there need to be a separate set of passwords for gnome-keyring and ksecretservicd? 4. If you are running gnome programs in a KDE workspace, or vice versus, will they automatically connect to the right secretservice or will they try to call their own backend? -Todd
Review Request: GSoC: Errors handling during file transfer.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102388/ --- Review request for kdelibs. Summary --- Modeless dialog to handle interactions and modifications in CopyJob. Diffs - kio/CMakeLists.txt b517621 kio/kio/copyjob.h eb88c7a kio/kio/copyjob.cpp eff7825 kio/kio/interactiondialog/abstractinteractionitem.h PRE-CREATION kio/kio/interactiondialog/abstractinteractionmodel.h PRE-CREATION kio/kio/interactiondialog/abstractinteractionmodel.cpp PRE-CREATION kio/kio/interactiondialog/allinteractionitem.h PRE-CREATION kio/kio/interactiondialog/allinteractionmodel.h PRE-CREATION kio/kio/interactiondialog/allinteractionmodel.cpp PRE-CREATION kio/kio/interactiondialog/existinginteractionitem.h PRE-CREATION kio/kio/interactiondialog/existinginteractionmodel.h PRE-CREATION kio/kio/interactiondialog/existinginteractionmodel.cpp PRE-CREATION kio/kio/interactiondialog/interactiondialog.h PRE-CREATION kio/kio/interactiondialog/interactiondialog.cpp PRE-CREATION kio/kio/interactiondialog/interactiondialogtab.h PRE-CREATION kio/kio/interactiondialog/interactiondialogtab.cpp PRE-CREATION kio/kio/interactiondialog/renameinteractionwidget.h PRE-CREATION kio/kio/interactiondialog/renameinteractionwidget.cpp PRE-CREATION kio/kio/interactiondialog/requestitemmodel.h PRE-CREATION kio/kio/interactiondialog/requestitemmodel.cpp PRE-CREATION kio/kio/interactiondialog/unreadableinteractionitem.h PRE-CREATION kio/kio/interactiondialog/unreadableinteractionmodel.h PRE-CREATION kio/kio/interactiondialog/unreadableinteractionmodel.cpp PRE-CREATION kio/kio/jobuidelegate.h 25e0728 kio/kio/jobuidelegate.cpp 85679c2 Diff: http://git.reviewboard.kde.org/r/102388/diff Testing --- Thanks, Cyril
Review Request: Determining MIME type of corrupted files hangs on repeated reads
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102382/ --- Review request for kdelibs and David Faure. Summary --- Please see the associated bugreport for all information, including a non-git patch. This addresses bug 280446. http://bugs.kde.org/show_bug.cgi?id=280446 Diffs - Diff: http://git.reviewboard.kde.org/r/102382/diff Testing --- Thanks, Miroslav
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sat, Aug 20, 2011 at 02:43:49PM +0200, Thiago Macieira wrote: On Saturday, 20 de August de 2011 14:11:32 Oswald Buddenhagen wrote: yeah, at the cost of rather considerable instability. we should see whether regular service activation isn't the better option, now that we have it. What instability? If kded crashes, what makes you think individual services won't crash, in addition to taking longer to load and use more memory? look at it from the perspective of the daemon, not the modules. there have been *tons* of bugs related to crashes and freezes in kded - which were module bugs actually. in-process is simply no sound architecture from a stability (and security) pov. guess which other kde component i'm thinking of ... One problem with a no-exec scenario is the inability to switch security contexts and to control them on a per-binary case. Today, that is. There's nothing preventing additional code to be introduced to do that, indeed, that's what i suggested as well. if we start from an all-privileged daemon like systemd. It's privilege elevation that suffers. does the session systemd run privileged in the first place? [...] The end result is that the launcher has a lot more COW operations that aren't its fault and its pages are duplicated everywhere. If there's a privilege boundary in the process, then this might even be a security risk [...] yeah, both of these concern result from systemd being a bit more than kdeinit. they could be mitigated by forking off the actual launcher process very early, but this may turn out ugly. It's far easier to introduce the feature we want into the prelinker and dynamic loader, such as having a stasis process: the dynamic loader could load everything as needed, then freeze the images just prior to running any code. one can have that with some ptrace trickery. but i'm not sure how this fixes the problem. do you want to exec() such pre-initialized images? i think it is pretty clear that our *code* is not going to be accepted as the cross-desktop solution. [...] I don't know where you got those numbers for weight, not to mention it's completely ambiguous (did you mean memory consumption?). code size = shared memory, page faults on load. But I don't care what they like or dislike: if the implementation is good, it should stay. there are two problems with that: - history has shown that it doesn't matter what the pragmatic solution would be, on both sides (just remember the utterly ridiculous bike shedding when aRts dared to add a glib dependency) - introducing a qt or even kde dependency into a so far gnome-only system can be a very real resource problem. that's not likely to apply to kglobalaccel (as it is pretty desktop-specific), but i'm assuming you are making a general statement I could even accept the alternate representation to be optional, so an UTF-8- to-UTF-16 coversion needs to happen when Qt-based code reads the config. on-demand conversion could lead to some nasty encoding ping-pong when the data is accessed concurrently. The problem I found is the same as QUrl today: implicit sharing of lazily constructed data. When you need to finish your lazy work, do you need to detach or not? If you detach, only one side will get the non-lazy output. If you don't detach, you need to somehow make the setting thread-safe -- which QUrl doesn't do. not detaching needs to do atomic pointer replacement to avoid memory leaks, but other than that it is relatively uncritical. a problem is of course that the converted data would need a separate allocation, as opposed to the embedded raw string data. This also carries the burden of checking the flags at many points in the code, probably adding overhead to timing-sensitive code which many already find slow. when i was pondering this with andre, we came up with the idea to make character access possible only through some kind of reference object, so checking the need for detaching and conversions would have to be done only when obtaining the reference. but that was long before qt5 actually materialized, including its mostly source compatible mandate.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote: What instability? If kded crashes, what makes you think individual services won't crash, in addition to taking longer to load and use more memory? look at it from the perspective of the daemon, not the modules. there have been *tons* of bugs related to crashes and freezes in kded - which were module bugs actually. in-process is simply no sound architecture from a stability (and security) pov. guess which other kde component i'm thinking of ... Sure, if each of 10 modules has a certain chance of failure or MTBF, the whole process has a much greater chance of failure or smaller MTBF. But if you look from the point of view from the system that requires each of those services, it doesn't matter if the crash brings down all services or just one. In any case, kded restarts. if we start from an all-privileged daemon like systemd. It's privilege elevation that suffers. does the session systemd run privileged in the first place? I have no clue. I don't even know if there's a session systemd. It's far easier to introduce the feature we want into the prelinker and dynamic loader, such as having a stasis process: the dynamic loader could load everything as needed, then freeze the images just prior to running any code. one can have that with some ptrace trickery. but i'm not sure how this fixes the problem. do you want to exec() such pre-initialized images? This isn't a fully-formed idea. It might need kernel help too. i think it is pretty clear that our *code* is not going to be accepted as the cross-desktop solution. [...] I don't know where you got those numbers for weight, not to mention it's completely ambiguous (did you mean memory consumption?). code size = shared memory, page faults on load. That is true. But it is not proven. Sure, QtCore is much bigger than glib: $ ls -l /usr/lib/libQtCore.so.4.8.0 /lib/libglib-2.0.so.0.2800.8 -rwxr-xr-x 1 root root 979028 Jun 8 02:53 /lib/libglib-2.0.so.0.2800.8* -rwxr-xr-x 1 root root 2980096 Jul 25 22:28 /usr/lib/libQtCore.so.4.8.0* But file sizes don't mean much. You'd have to check how much in page faults really happens to fault in those services: given comparable uses of the libraries, what is the actual memory use? What's more, you can also justify it as a trade-off in readability and maintainabilty. In a running system, where QtCore is already loaded, there aren't any page faults to load the code or marginal increase in memory usage because of it. And if we fix the above problem of prelinking, the prelinked read-only data can also be shared. (note my use of commas in where QtCore is already loaded: it's not a restrictive definition of system, it's an explanation of it; for me, there are no systems where QtCore isn't already loaded) - introducing a qt or even kde dependency into a so far gnome-only system can be a very real resource problem. that's not likely to apply to kglobalaccel (as it is pretty desktop-specific), but i'm assuming you are making a general statement Right. And if we accept glib dependencies, I don't see why they shouldn't accept QtCore dependencies. I could even accept the alternate representation to be optional, so an UTF-8- to-UTF-16 coversion needs to happen when Qt-based code reads the config. on-demand conversion could lead to some nasty encoding ping-pong when the data is accessed concurrently. You misunderstand dconf: reading settings is done via mmap()ed read-only memory. If the UTF-16 encoding isn't there, then the reader needs to create a QString from the UTF-8 data. Writing is done via D-Bus. I don't see a ping-pong. The problem I found is the same as QUrl today: implicit sharing of lazily constructed data. When you need to finish your lazy work, do you need to detach or not? If you detach, only one side will get the non-lazy output. If you don't detach, you need to somehow make the setting thread-safe -- which QUrl doesn't do. not detaching needs to do atomic pointer replacement to avoid memory leaks, but other than that it is relatively uncritical. a problem is of course that the converted data would need a separate allocation, as opposed to the embedded raw string data. If you don't detach and you do replace the pointers, when do you delete the old data? You need a shared data pointer of some kind. I don't want to introduce a second reference count in QStringData. when i was pondering this with andre, we came up with the idea to make character access possible only through some kind of reference object, so checking the need for detaching and conversions would have to be done only when obtaining the reference. That's QCharRef. but that was long before qt5 actually materialized, including its mostly source compatible mandate. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source
Re: Review Request: Don't hang when determining MIME type of corrupted files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102391/#review5872 --- Thanks Peter and Miroslav. The analysis looks correct, the pre-read part of the patch looks good. I'm just wondering about using Unbuffered. If someone installs a mimetype definition with multiple rules trying to match some bytes after the 2K limit, then all this seeking-and-reading back and forth will be very slow, in unbuffered mode (since neither cache will be used). - David On Aug. 20, 2011, 5:21 p.m., Peter Penz wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102391/ --- (Updated Aug. 20, 2011, 5:21 p.m.) Review request for kdelibs and David Faure. Summary --- If KMimeTypeRepository::findFromContent() tries to determine MIME from a file that cannot be read, such as on a corrupted optical disc, a read attempt is made in KMimeMagicMatch::match() for every available rule, resulting in UI hangs (e.g. file dialogs, dolphin) for tens of minutes (see https://bugs.kde.org/show_bug.cgi?id=280446 for more details). I've submitted this patch here on behalf of Miroslav ?os, who has submitted the bug-report and also has written the patch. This addresses bug 280446. http://bugs.kde.org/show_bug.cgi?id=280446 Diffs - kdecore/services/kmimetype.cpp 955bf62 kdecore/services/kmimetyperepository.cpp 6ff3d16 Diff: http://git.reviewboard.kde.org/r/102391/diff Testing --- Thanks, Peter
Re: Review Request: Do not crash because a badly servicetype_profilerc is found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101914/#review5874 --- Ship it! Yes, please commit to 4.7 and frameworks. - David On Aug. 20, 2011, 4:51 p.m., Jaime Torres Amate wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101914/ --- (Updated Aug. 20, 2011, 4:51 p.m.) Review request for kdelibs. Summary --- My I push this patch to 4.7 and frameworks branchs? This addresses bug 269785. http://bugs.kde.org/show_bug.cgi?id=269785 Diffs - kdecore/services/kservicetypeprofile.cpp 7403e2a Diff: http://git.reviewboard.kde.org/r/101914/diff Testing --- It does not crash in the assertion :-) Thanks, Jaime Torres
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sun, Aug 21, 2011 at 11:28:02AM +0200, Thiago Macieira wrote: Sure, if each of 10 modules has a certain chance of failure or MTBF, the whole process has a much greater chance of failure or smaller MTBF. But if you look from the point of view from the system that requires each of those services, it doesn't matter if the crash brings down all services or just one. not all kded services are required - many are more like recommended. but even if we assume that all are required, then out-of-process still improves fault isolation and recoverability. In any case, kded restarts. yes, when the faulty module crashes. not so when it deadlocks or busy-loops. also, a restart typically loses state. code size = shared memory, page faults on load. That is true. But it is not proven. [...] well, yeah, somebody has to do some real research. but the outcome is pretty predictable: qt's use of templates makes it extremely likely that significantly more code is executed, and the rather likely suboptimal code locality makes it probable that more unused code needs to be paged in from the much larger binary. What's more, you can also justify it as a trade-off in readability and maintainabilty. well, of course. but given the availability of two equivalent solutions and people willing to maintain them, the one with a lower resource consuption will always be favorable. Right. And if we accept glib dependencies, I don't see why they shouldn't accept QtCore dependencies. well, given that glib is an accepted dependency of qt (at least on the desktop), qt will always be an *additional* dependency. it's going to be interesting to push it down the stack enough that people stop thinking about it. reading settings is done via mmap()ed read-only memory. If the UTF-16 encoding isn't there, then the reader needs to create a QString from the UTF-8 data. Writing is done via D-Bus. i know. exactly this has the potential for ping-pong if you do on-demand conversion of the actual store. anyway, i really wonder whether insisting on utf-16 makes sense, assuming that the store is not abused for more than config data. KConfig and QSettings use utf-8, too, and nobody seriously complained about that afaik. the dconf client can implement caching of converted data just like the exising classes do. If you don't detach and you do replace the pointers, when do you delete the old data? the lifetime would be bound to the qstringdata, like the latin1 data in qt3-. i wouldn't bother with sharing the converted values - upon detaching, the format which is needed for the operation which caused the detach is made the primary (embedded) and only data of the clone. when i was pondering this with andre, we came up with the idea to make character access possible only through some kind of reference object, That's QCharRef. more like a qstringref, as we want bounds checking. but it should be also possible to append to the non-const variant of that thingie.
Re: Review Request: Do not terminate threads
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102179/#review5875 --- I think this patch is almost ready, but Dawit's comment seems right about an improvement that should be done to it: - Move all the preemptive lookup logic from the thread's run function to HostInfo::lookupHost. [No need to create a thread when DNS is already cached]. - David On Aug. 11, 2011, 10:10 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102179/ --- (Updated Aug. 11, 2011, 10:10 p.m.) Review request for kdelibs and Dawit Alemayehu. Summary --- Each time the terminate code triggers my Konqueror crashes, i'm substituting the terminate for just waiting the thread to finish and we just ignoring it. The code has a race condition in which wait() returns false, then we switch to the thread and m_autoDelete is still not set and thus noone will delete the thread. I can add a mutex if you guys think this is unacceptable. Diffs - kio/kio/hostinfo.cpp 344b1d8 Diff: http://git.reviewboard.kde.org/r/102179/diff Testing --- When the kDebug() Name look up for hostName failed; if triggers i do not get a crash anymore. Thanks, Albert
Re: Review Request: Do not crash because a badly servicetype_profilerc is found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101914/#review5876 --- This review has been submitted with commit 24498bb761630e24e39df1ea5c614136eff7310c by Jaime Torres to branch KDE/4.7. - Commit On Aug. 20, 2011, 4:51 p.m., Jaime Torres Amate wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101914/ --- (Updated Aug. 20, 2011, 4:51 p.m.) Review request for kdelibs. Summary --- My I push this patch to 4.7 and frameworks branchs? This addresses bug 269785. http://bugs.kde.org/show_bug.cgi?id=269785 Diffs - kdecore/services/kservicetypeprofile.cpp 7403e2a Diff: http://git.reviewboard.kde.org/r/101914/diff Testing --- It does not crash in the assertion :-) Thanks, Jaime Torres
Re: Review Request: Do not crash because a badly servicetype_profilerc is found
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101914/#review5877 --- This review has been submitted with commit c470a32fffd7a97302ed86c5812bb58da3141eb7 by Jaime Torres to branch frameworks. - Commit On Aug. 20, 2011, 4:51 p.m., Jaime Torres Amate wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101914/ --- (Updated Aug. 20, 2011, 4:51 p.m.) Review request for kdelibs. Summary --- My I push this patch to 4.7 and frameworks branchs? This addresses bug 269785. http://bugs.kde.org/show_bug.cgi?id=269785 Diffs - kdecore/services/kservicetypeprofile.cpp 7403e2a Diff: http://git.reviewboard.kde.org/r/101914/diff Testing --- It does not crash in the assertion :-) Thanks, Jaime Torres
Re: Git migration status (Was: Re: Where is kmix hidden?)
On 19 August 2011 22:18, Jeremy Whiting jpwhit...@kde.org wrote: On Fri, Aug 19, 2011 at 1:27 PM, John Layt jl...@kde.org wrote: On Friday 19 Aug 2011 19:54:21 Harald Sitter wrote: On Fri, Aug 19, 2011 at 6:54 PM, Lukas Appelhans l.appelh...@gmx.de wrote: I guess there were no efforts yet from the kdemultimedia team to make the move. I did not realize we had to take care of the move seems a bit inconvenient. Yep, you need to mak e it happen as it involves decision no-one else can make for you. There's basically three steps needed. First, you have to decide on separate Git repos per app or stick with the monolithic module. Second, if going for separete repos make sure everything actually builds properly that way. Third you need to write the conversion rules for you history, but there's a few people around who may be willing to help out with that once you know what you want. Have a chat on the #kde-git channel for more details. On the subject of un-converted svn modules, the following are still left: kdeaccessibility kdeadmin kdegames kdemultimedia kdenetwork I have partially written the rules for kdenetwork, but they are not complete. I don't have time to work on them at the moment, so someone else taking that over would be good if it's going to happen any time soon. The work I've done so far is in the git repository with all the other conversion rules. -- George
Re: Review Request: Only include nepomuk directories if nepomuk is available
On Aug. 17, 2011, 1:19 p.m., Allen Winter wrote: Has this been committed? If so, please close this review; else please commit and close this review. Bjoern Ricks wrote: Commit to trunk and/or 4.7? Allen Winter wrote: Only master -- better not muck around with 4.7 too much. The real solution is to finally make Soprano a hard requirement. On second thought, please commit to the 4.7 branch as well. master is frozen now so you should commit into the frameworks branch. - Allen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101949/#review5772 --- On July 14, 2011, 2:40 p.m., Bjoern Ricks wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101949/ --- (Updated July 14, 2011, 2:40 p.m.) Review request for kdelibs. Summary --- kdelibs build fails if sdo and/or soprano aren't available Diffs - kparts/CMakeLists.txt db76613 Diff: http://git.reviewboard.kde.org/r/101949/diff Testing --- Thanks, Bjoern
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote: yes, when the faulty module crashes. not so when it deadlocks or busy-loops. also, a restart typically loses state. True, but I don't remember that happening a single time to me in the past 3 years. I remember seeing people complain about kded taking 100% CPU, but it hasn't happened to me. code size = shared memory, page faults on load. That is true. But it is not proven. [...] well, yeah, somebody has to do some real research. but the outcome is pretty predictable: qt's use of templates makes it extremely likely that significantly more code is executed, and the rather likely suboptimal code locality makes it probable that more unused code needs to be paged in from the much larger binary. The extensive use of templates probably generates more code, but due to better inlining, the code is potentially faster. So we're trading off code size for code performance. I once wrote a benchmark comparing iterating over a QString to iterating over a gchar UTF-8 string using glib functions to get each UCS-4 character (ostensibly to prove that UTF-16 was better than UTF-8). The result was clear: Qt code was much faster, over 10x, compared to glib. I wouldn't be surprised if we find the same about the other containers. Our benchmark isn't glib containers, but STL ones. well, of course. but given the availability of two equivalent solutions and people willing to maintain them, the one with a lower resource consuption will always be favorable. Agreed. Which is why an existing service that we write should be in C++. We should not be required to learn glib in order to write a shared service. If the GNOME developers decide they want to rewrite it, they are welcome to do so and dedicate resources. Note I have never proposed rewriting existing shared service code in Qt. well, given that glib is an accepted dependency of qt (at least on the desktop), qt will always be an *additional* dependency. it's going to be interesting to push it down the stack enough that people stop thinking about it. Or make enough interesting services that are Qt-based. Back on the Ubuntu Developer Summit in May last year, when I was presenting some of the technologies of Qt Mobility, there was a big interest in using them. Mark Shuttleworth asked if there were bindings for Python, which is the language that Canonical likes to use. But I'm sure other people wanted to use them from C too, they just didn't ask. The point is just as above: we, the KDE and Qt communities, are not required to learn glib in order to write a new service or library. reading settings is done via mmap()ed read-only memory. If the UTF-16 encoding isn't there, then the reader needs to create a QString from the UTF-8 data. Writing is done via D-Bus. i know. exactly this has the potential for ping-pong if you do on-demand conversion of the actual store. What ping-pong? If there's no UTF-16 encoding of the read-only and unchangeable data, you use QString::fromUtf8. If there is, you return QString::fromRawData. When you write, you write with the encoding. Already-running applications must reopen the file, or scan to a later point in it anyway to see the new value. anyway, i really wonder whether insisting on utf-16 makes sense, assuming that the store is not abused for more than config data. KConfig and QSettings use utf-8, too, and nobody seriously complained about that afaik. the dconf client can implement caching of converted data just like the exising classes do. I have. Please try this: valgrind --tool=massif kwrite Then use the nice massifvisualizer to look at what consumes the most memory at startup. It's KConfig, upwards of a couple of megabytes of heap. If you don't detach and you do replace the pointers, when do you delete the old data? the lifetime would be bound to the qstringdata, like the latin1 data in qt3-. i wouldn't bother with sharing the converted values - upon detaching, the format which is needed for the operation which caused the detach is made the primary (embedded) and only data of the clone. So you're advocating the detaching method, not the convert-and-inline-replace one which QUrl tries to do and fails. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: Git migration status (Was: Re: Where is kmix hidden?)
Hey! Cool... I see you go for a split up of kdenetwork (makes sense imo). The problem I see at the moment you have to build all applications together in kdenetwork, otherwise they fail to compile. So this is a first thing which needs to change. What is missing are tags and branches right? Lukas PS: The KGet svn cp comment is (I guess) about this branch: http://websvn.kde.org/branches/work/make_kget_cool/?pathrev=647221 As far as I know this is the KGet2 rewrite and was copied to trunk then... I have partially written the rules for kdenetwork, but they are not complete. I don't have time to work on them at the moment, so someone else taking that over would be good if it's going to happen any time soon. The work I've done so far is in the git repository with all the other conversion rules. -- George signature.asc Description: This is a digitally signed message part.
Re: Git migration status (Was: Re: Where is kmix hidden?)
On Fri, Aug 19, 2011 at 9:27 PM, John Layt jl...@kde.org wrote: The kde-wallpapers and kdeartwork modules are likely to remain in svn until git handles binary blobs better. Then there is also a lot of stuff still in extragear and playground. This is an issue with kdegames as well: A complete source tree is 112 megabytes, of which about AFAIR 80% is data (SVGZ, audio files, levelsets, etc.). Some months ago, I've proposed on kde-games-devel@ to split a kdegames-data module from kdegames. The discussion ended because we decided not to switch to git before a workflow exists to handle split repositories. (With SuperBuild being available now, this discussion probably needs to be restarted.) What I proposed: 1. Freeze trunk/KDE/kdegames, conserve this state as kdegames-history.git 2. Move all data files from trunk/KDE/kdegames to trunk/KDE/kdegames-data. 3. Move the source code to git.kde.org (as fresh repos, to avoid data blobs in the object db). 4. Optionally patch the games to run without data. This is because the build order of the modules would be: kdegames, then kdegames-data. Greetings Stefan
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Saturday 20 Aug 2011 13:11:32 Oswald Buddenhagen wrote: On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote: It needs a global spec too, since global shortcut grabbing with X11 libs only is sorely lacking. I think the solution we made for KDE 4 is actually quite good. Anyone wants to create an XDG spec for global accelerators? well, yeah. good luck to whoever. :P We had a bad experience last time, but we should use that experience to play smarter this time around. The big complaints that I saw from Gnome last time was that we supposedly had no clear statement of why the spec was needed and what it was meant to achieve, that they had no real involvment in the drafting of the spec, that we talked to the wrong people, and that it was something they didn't need in G3. So lets turn that on its head. Lets write a statement saying why we need a spec and what it needs to achieve. Mention we have an existing solution that would be a good starting point, but don't actually detail it. Then send that to xdg and Gnome and Unity and anyone else asking who are the right pople to talk to. Hopefully those people then decide it's a good thing and agree to work together to develop a standard. If they're not interested then we get to draft it ourselves knowing there can be no complaints. But just as before, I don't see why our code can't be cross-desktop. So no argument in favour of dropping kglobalaccel. i think it is pretty clear that our *code* is not going to be accepted as the cross-desktop solution. seeing the reluctance to anything with g* within our community, why do you think the gnomers would embrace anything with a q* or even k*, esp. given that it usually weights in at least twice as much as the typical g* solution? We depend on a lot of g code these days, some of it even willingly, and we're looking at even more. As for Gnome never accepting any q/k code, it's mostly true, but copying is the sincerest form of flattery :-) Can we actually point to cases where Gnome rejected Qt/KDE code proposals, and how about ones that have been accepted (Poppler?). I'm not convinced it's really about the weight or otherwise of our solutions (system-config-printer is written in python!). How much is just C vs C++, or our not pushing stuff, or just not having key people employed by the distros? I'd like to see what happens when Qt5 has a nice light QtCore that we use to write something small and light that they need. John.
Re: Git migration status (Was: Re: Where is kmix hidden?)
On Sun, Aug 21, 2011 at 4:05 PM, Lukas Appelhans l.appelh...@gmx.de wrote: Hey! Cool... I see you go for a split up of kdenetwork (makes sense imo). The problem I see at the moment you have to build all applications together in kdenetwork, otherwise they fail to compile. So this is a first thing which needs to change. It is not really required to build them all together. I used to have git-svn clones of krdc, krfb and kopete and built them separately. Actually, all the work I have done on krfb was done this way. Iirc there is extra cmake code in there to ensure that they build both standalone and all together. What is missing are tags and branches right? Lukas PS: The KGet svn cp comment is (I guess) about this branch: http://websvn.kde.org/branches/work/make_kget_cool/?pathrev=647221 As far as I know this is the KGet2 rewrite and was copied to trunk then... I have partially written the rules for kdenetwork, but they are not complete. I don't have time to work on them at the moment, so someone else taking that over would be good if it's going to happen any time soon. The work I've done so far is in the git repository with all the other conversion rules. -- George
Re: Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
A Diumenge, 21 d'agost de 2011, John Layt vàreu escriure: On Saturday 20 Aug 2011 13:11:32 Oswald Buddenhagen wrote: On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote: It needs a global spec too, since global shortcut grabbing with X11 libs only is sorely lacking. I think the solution we made for KDE 4 is actually quite good. Anyone wants to create an XDG spec for global accelerators? well, yeah. good luck to whoever. :P We had a bad experience last time, but we should use that experience to play smarter this time around. The big complaints that I saw from Gnome last time was that we supposedly had no clear statement of why the spec was needed and what it was meant to achieve, that they had no real involvment in the drafting of the spec, that we talked to the wrong people, and that it was something they didn't need in G3. So lets turn that on its head. Lets write a statement saying why we need a spec and what it needs to achieve. Mention we have an existing solution that would be a good starting point, but don't actually detail it. Then send that to xdg and Gnome and Unity and anyone else asking who are the right pople to talk to. Hopefully those people then decide it's a good thing and agree to work together to develop a standard. If they're not interested then we get to draft it ourselves knowing there can be no complaints. But just as before, I don't see why our code can't be cross-desktop. So no argument in favour of dropping kglobalaccel. i think it is pretty clear that our *code* is not going to be accepted as the cross-desktop solution. seeing the reluctance to anything with g* within our community, why do you think the gnomers would embrace anything with a q* or even k*, esp. given that it usually weights in at least twice as much as the typical g* solution? We depend on a lot of g code these days, some of it even willingly, and we're looking at even more. As for Gnome never accepting any q/k code, it's mostly true, but copying is the sincerest form of flattery :-) Can we actually point to cases where Gnome rejected Qt/KDE code proposals, and how about ones that have been accepted (Poppler?). You really can not cound poppler as coming from our side. Poppler was started and driven by Red Hat Desktop Team (or something similar) and it was not until they lost interest (aka Red Hat relocated people to work on a different project) that real easy collaboration started to happen. Albert I'm not convinced it's really about the weight or otherwise of our solutions (system-config-printer is written in python!). How much is just C vs C++, or our not pushing stuff, or just not having key people employed by the distros? I'd like to see what happens when Qt5 has a nice light QtCore that we use to write something small and light that they need. John.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sun, Aug 21, 2011 at 02:54:41PM +0200, Thiago Macieira wrote: On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote: yes, when the faulty module crashes. not so when it deadlocks or busy-loops. also, a restart typically loses state. True, but I don't remember that happening a single time to me in the past 3 years. I remember seeing people complain about kded taking 100% CPU, but it hasn't happened to me. yes, things have stabilized meanwhile. but the problem will re-appear during the kde5 cycle. it's inherent, after all. The extensive use of templates probably generates more code, but due to better inlining, the code is potentially faster. So we're trading off code size for code performance. probably. depending on the use case, this may or may not be a convincing argument. it's going to be interesting to push it down the stack enough that people stop thinking about it. Or make enough interesting services that are Qt-based. well, that's the only way to do the pushing. it's not like we have any political leverage to do it differently. The point is just as above: we, the KDE and Qt communities, are not required to learn glib in order to write a new service or library. some day maybe. but to be able to join existing projects we have to learn glib anyway. and if qt becomes a common framework for low-level things, others will have to learn qt. we are going to fragment the ecosystem! :D What ping-pong? If there's no UTF-16 encoding of the read-only and unchangeable data, you use QString::fromUtf8. uhm, ok, i think i misunderstood you. If there is, you return QString::fromRawData. uhm, no, you must make a deep copy, otherwise you get a time bomb. but yeah, no conversion, so pretty cheap. anyway, i really wonder whether insisting on utf-16 makes sense, assuming that the store is not abused for more than config data. [...] valgrind --tool=massif kwrite Then use the nice massifvisualizer to look at what consumes the most memory at startup. It's KConfig, upwards of a couple of megabytes of heap. there is a 90+ kb file named katesyntaxhighlightingrc which seems to be mostly a cache file. this use of kconfig borders on abuse. not sure if there are other files on your system or kconfig really is that inefficient. but generally speaking, a program which actually needs to query several thousand keys on startup is definitely Doing It Wrong. and if it reads only a few keys (of even a million), then the conversion cache will hold almost nothing. on top of that, the cached converted values will be to some degree shared with the objects which requested the values. So you're advocating the detaching method, not the convert-and-inline-replace one which QUrl tries to do and fails. uhm, maybe. it's not like the terminology would be self-evident. ;)
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Saturday 20 Aug 2011 10:14:20 Oswald Buddenhagen wrote: On Tue, Aug 16, 2011 at 08:00:19PM +0100, John Layt wrote: I've certainly seen him state that he doesn't care about KDE, that we are irrelevent to anything he does, and he sees no reason to collaborate on anything with us. and he's right. show me one case where the outcome of his low-level work did not meet kde requirements. Ummm, Pulse Audio? It completely broke sound under KDE. It caused a lot of users a lot of pain before Colin come along to fix it for us and for Gnome users too. I don't want to see a repeat of that, so figuring out how to get Lennart to care becomes important. It's similar to his attitude towards *BSD. he's right with that, too. if the bsd's (or solaris, for that matter) want to stay relevant on the desktop, they need to catch up with linux. or put differently, they make up about about 0.1% of our user base, which easily could be several times bigger if we were able to provide something well-integrated (mac os x anyone?). do you think they are worth sacrificing? I have no problem with him saying he won't support BSD, I'm happy for them to write their own patches or version, but that's a bit hard for them to do if the dbus api is a moving target. If we have people willing to do the work to support KDE on BSD, then who are we to stop them provided the rest of KDE isn't negatively affected? Will we also stop supporting Windows and OSX because we're not fully integrated there and just focus on Linux? That sounds very much like the GnomeOS idea... John.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday 21 August 2011 Aug, Oswald Buddenhagen wrote: On Sun, Aug 21, 2011 at 02:54:41PM +0200, Thiago Macieira wrote: On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote: yes, when the faulty module crashes. not so when it deadlocks or busy-loops. also, a restart typically loses state. True, but I don't remember that happening a single time to me in the past 3 years. I remember seeing people complain about kded taking 100% CPU, but it hasn't happened to me. yes, things have stabilized meanwhile. but the problem will re-appear during the kde5 cycle. it's inherent, after all. Actually kded using 100% cpu happened to me last week, when I was travelling. Took me some googling to figure out that it was some incompability with libntrack and that I needed to install that from source. I even had to use gnome as my desktop for a day before I had time to figure out what was going on... -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Nepomuk and MySQL - Why?
Hi, Every time when i start a brand new KDE session with a new user i see some stuff passing by with MySQL.. Now i understand a database is needed for nepomuk but does it have to be a heavy weight one like MySQL? MySQL is not only big in hdd footprint, it also loves to suck up memory. Some alternatives i can think of: - SQLite - MongoDB A bit about MongoDB. That database spits data out in BSON format (Binary JSON) which -to me- seems to perfectly fit the the QML strategy that KDE seems to be going to (for KDE 5.0 or so?). It prevents conversion to JSON and thus would seem like a perfect fit for QML plasmoids. On the C++ side things are a bit different. There is a C++ wrapper for MongoDB but it uses boost. There is no native Qt wrapper for MongoDB (yet). The advantages of using MongoDB over MySQL are (that i can think of in a few seconds): - Just a few MB hdd footprint for the binary and libs - Faster then MySQL - Easy to use in QML plasmoids The disadvantage is obviously more hdd space for the database itself and no existing Qt wrapper. So, why is MySQL used and not a lighter alternative like SQLite or MongoDB? Please do note that this is by no means a intent to start a flame war or anything! I'm just curious behind the MySQL reasoning and if it's worth a consideration to move to another lighter database. Kind regards, Mark
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday, 21 de August de 2011 16:40:32 Oswald Buddenhagen wrote: If there is, you return QString::fromRawData. uhm, no, you must make a deep copy, otherwise you get a time bomb. but yeah, no conversion, so pretty cheap. You can also use a QStringData with a regular refcount and just watch as it becomes 1. When all the QStrings in this segment of mmapped memory have refcount 1 or 0, then you can unmap it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: Nepomuk and MySQL - Why?
On Sun, Aug 21, 2011 at 5:25 PM, Thiago Macieira thi...@kde.org wrote: On Sunday, 21 de August de 2011 17:03:10 Mark wrote: Every time when i start a brand new KDE session with a new user i see some stuff passing by with MySQL.. Now i understand a database is needed for nepomuk but does it have to be a heavy weight one like MySQL? It's not nepomuk, it's akonadi. MySQL is not only big in hdd footprint, it also loves to suck up memory. Some alternatives i can think of: - SQLite - MongoDB SQLite works now. It didn't use to in previous versions, since the SQL requirements that Akonadi had weren't supported. A bit about MongoDB. Irrelevant until someone writes a QtSql backend for it. which is not possible since the entire NoSQL principle doesn't fit SQL. Perhaps a QtNoSQL implementation ^_-
Re: d-conf (was: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit))
On Sun, Aug 21, 2011 at 05:23:14PM +0200, Thiago Macieira wrote: On Sunday, 21 de August de 2011 16:40:32 Oswald Buddenhagen wrote: If there is, you return QString::fromRawData. uhm, no, you must make a deep copy, otherwise you get a time bomb. You can also use a QStringData with a regular refcount and just watch as it becomes 1. When all the QStrings in this segment of mmapped memory have refcount 1 or 0, then you can unmap it. well, yes, you can put a (shallow) copy of every qstring you hand out into an appropriate data structure and from there watch the refcount. but maps become invalid when the underlying data changes. in fact, it would seem that reads must be locked out while a write is in progress.
systemd and KDE (was: Re: kdeinit)
On Sun, Aug 21, 2011 at 4:54 PM, John Layt jl...@kde.org wrote: Ummm, Pulse Audio? It completely broke sound under KDE. It caused a lot of users a lot of pain before Colin come along to fix it for us and for Gnome users too. I don't want to see a repeat of that, so figuring out how to get Lennart to care becomes important. During Desktop Summit, I've jumped on the systemd-KDE-integration bandwagon (which seems to be only me at the moment, or is there any work which I'm not aware of?). As a very first step, there's libqsystemd [1], which I'll try to finish and polish in the next few weeks. This should make it easy to write apps that communicate with systemd. For example, what about a proper Plasma dataengine for systemd units/jobs and an applet that e.g. shows the state of a systemd unit? There's an proof-of-concept dataengine in the repo [1], but the subject is in need of someone who knows his way around Plasma dataengines and friends. The second integration point is the unified interfaces for system configuration that systemd provides. If systemd is present, it should be used to set (possibly also get) the hostname, locale, and system time. Also, KDM should be able to communicate with systemd-logind, which (as outlined by Lennart's talk at DS) seeks to replace ConsoleKit. The third integration point is to use systemd as a session manager, thereby (as already mentioned) possibly replacing big parts of our own startup sequence. Once I can get a current version of systemd to compile on my machine, I will try to look into this, but of course help is appreciated on all fronts. Greetings Stefan [1] git clone kde:libqsystemd
Re: Nepomuk and MySQL - Why?
On Sunday, 21 de August de 2011 17:28:36 Mark wrote: A bit about MongoDB. Irrelevant until someone writes a QtSql backend for it. which is not possible since the entire NoSQL principle doesn't fit SQL. Perhaps a QtNoSQL implementation ^_- That doesn't work. Akonadi is implemented entirely on top of SQL and QtSql. If MongoDB can't do SQL, it can't be a DB backend for Akonadi and thus the discussion is irrelevant. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: d-conf (was: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit))
On Sunday, 21 de August de 2011 17:46:22 Oswald Buddenhagen wrote: but maps become invalid when the underlying data changes. in fact, it would seem that reads must be locked out while a write is in progress. By design it is. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday, 21 de August de 2011 17:30:39 Oswald Buddenhagen wrote: That sounds very much like the GnomeOS idea... yes, it does. i'm fully sold on that idea. if kde is ever going to have any globally significant market share (*), then as applications and possibly an alternative shell - on top of gnome os. exclude from that specialized markets where a broad range of applications (and thus a workable 3rd party developer platform) is insignificant. Considering the audience and considering that KDE has more deployments than GNOME, why can't it be the other way around? Why do we need to drop what we already have and are ahead to gain more? You're not going to find supporters of that idea here. Therefore, we will continue to develop KDE Platform as the main desktop and require GNOME apps to integrate with us instead (and if they don't, we'll probably call their apps and frameworks badly designed -- which will be partly right and partly wrong and petty). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
[: Thiago Macieira :]
I once wrote a benchmark comparing iterating over a QString to iterating
over a gchar UTF-8 string using glib functions to get each UCS-4 character
(ostensibly to prove that UTF-16 was better than UTF-8). The result was
clear: Qt code was much faster, over 10x, compared to glib.
[...]
The point is just as above: we, the KDE and Qt communities, are not
required to learn glib in order to write a new service or library.
Funilly, this is something that I was just intending to do for the sake of
acceptance. I started by looking for the necessary pieces in glib and how
they work, saw glib's iteration over characters, and thought this has got
to be mightily slower. And the code I want to write will mostly be doing
that.
Do you perhaps still have that benchmark code? Do you have (or know of)
similar benchmarks for XML parsing (GMarkupParser vs. QXmlStreamReader) and
JavaScript (QtScript vs. say SpiderMonkey)? Also, a QRegExp vs. GRegex
benchmark would be nice.
If the Qt-based implementation would be significantly superior in
performance, I gather you would advise just doing it and ignoring any but
C++... but another dependency... objections?
Also, with library being native C++, can there be any problem with C
bindings? I tried something like this:
// lib.h
class Foo {
public:
Foo (...);
void doSomething (...);
};
// lib.cpp
#include lib.h
Foo::Foo (...) { ... }
void Foo::doSomething (...) { ... }
// c_bindings.h
typedef struct Foo CFoo;
CFoo *foo_new (...);
void foo_dosomething (...);
// c_bindings.cpp
#include lib.h
extern C {
#include c_bindings.h
CFoo *foo_new (...) { return new Foo(...); }
void foo_dosomething (CFoo *a, ...) { a-doSomething(...); }
}
// app_main.c
#include c_bindings.h
int main ()
{
CFoo *f;
f = foo_new(...);
foo_dosomething(f, ...);
return 0;
}
I could build it with:
g++ lib.cpp
g++ c_bindings.cpp
gcc app_main.c lib.o c_bindings.o -lstdc++
but I don't know if this test covers everything.
--
Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sun, Aug 21, 2011 at 06:26:19PM +0200, Chusslove Illich wrote: Also, with library being native C++, can there be any problem with C bindings? once upon a time, there were (maybe still are, i dunno) more or less full c bindings for qt and kde, and they even served as a base for bindings to some script language. so it's doable, and the history of kdebindings should contain enough example code. and there are some libraries in actual use which are written in c++ but expose (only) a c api to the outside. so there is no technical reason why it wouldn't work. the only challenge is selling the qt dependency. :)
Re: Git migration status (Was: Re: Where is kmix hidden?)
On Sunday 21 August 2011 17:27:01 George Kiagiadakis wrote: On Sun, Aug 21, 2011 at 4:05 PM, Lukas Appelhans l.appelh...@gmx.de wrote: Hey! Cool... I see you go for a split up of kdenetwork (makes sense imo). The problem I see at the moment you have to build all applications together in kdenetwork, otherwise they fail to compile. So this is a first thing which needs to change. It is not really required to build them all together. I used to have git-svn clones of krdc, krfb and kopete and built them separately. Actually, all the work I have done on krfb was done this way. Iirc there is extra cmake code in there to ensure that they build both standalone and all together. Okay. This is not true for KGet though: All searching for dependencies is done in the top-level CMakeLists.txt. Lukas What is missing are tags and branches right? Lukas PS: The KGet svn cp comment is (I guess) about this branch: http://websvn.kde.org/branches/work/make_kget_cool/?pathrev=647221 As far as I know this is the KGet2 rewrite and was copied to trunk then... I have partially written the rules for kdenetwork, but they are not complete. I don't have time to work on them at the moment, so someone else taking that over would be good if it's going to happen any time soon. The work I've done so far is in the git repository with all the other conversion rules. -- George signature.asc Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday, 21 de August de 2011 18:26:19 Chusslove Illich wrote: Do you perhaps still have that benchmark code? Do you have (or know of) The code exists, but I don't have it. It's part of the QCharIterator work I did while at Nokia but never published, so I don't have rights to that code anymore. I'm sure I put it in the codereview tool before I left so it would be opensourced some day. similar benchmarks for XML parsing (GMarkupParser vs. QXmlStreamReader) and JavaScript (QtScript vs. say SpiderMonkey)? Also, a QRegExp vs. GRegex benchmark would be nice. XML parsing? no, I doubt. JS engine? Yes, a lot. That's why JavaScriptCore is being replaced with V8 now. QRegExp? don't try. The RE backend needs to be replaced. If the Qt-based implementation would be significantly superior in performance, I gather you would advise just doing it and ignoring any but C++... but another dependency... objections? C++ being a dependency is a very, very weak argument. There are lots of GNOME applications using gtkmm, pangomm, etc. C++ is present in most/all systems anyway, so it's not a dependency. The argument they may have is to Qt as a dependency, but as I said, that's not an argument for me. Qt being present and loaded into memory is baseline. Also, with library being native C++, can there be any problem with C bindings? I tried something like this: All problems with bindings can be solved. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: Nepomuk and MySQL - Why?
On Sun, Aug 21, 2011 at 1:09 PM, Thiago Macieira thi...@kde.org wrote: On Sunday, 21 de August de 2011 17:28:36 Mark wrote: A bit about MongoDB. Irrelevant until someone writes a QtSql backend for it. which is not possible since the entire NoSQL principle doesn't fit SQL. Perhaps a QtNoSQL implementation ^_- That doesn't work. Akonadi is implemented entirely on top of SQL and QtSql. If MongoDB can't do SQL, it can't be a DB backend for Akonadi and thus the discussion is irrelevant. Nope, MongoDB can't do SQL. Mongo doesn't have a 'Language Specification', it needs methods to add / remove items, and it's very weird to do updates. It's easyer to create simple adds, very complex to do complex queries. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sun, Aug 21, 2011 at 06:15:53PM +0200, Thiago Macieira wrote: On Sunday, 21 de August de 2011 17:30:39 Oswald Buddenhagen wrote: if kde is ever going to have any globally significant market share (*), then as applications and possibly an alternative shell - on top of gnome os. (*) exclude from that specialized markets [...]. Considering the audience and considering that KDE has more deployments than GNOME, why can't it be the other way around? this is where we started from. gnome is now serious about making a complete platform. if they succeed, they will win. big time. that's how apple did it, at the technical level. and how kde won't, due to lack of interest (commercial or otherwise) in that area. Why do we need to drop what we already have and are ahead to gain more? the point is that there isn't much to drop. it's some barely maintained code, and some informal specifications the best of which we could implement in gnome with relative ease if we actually cared to. You're not going to find supporters of that idea here. [...] i'm not sure whether you believe that this is how it should be or whether this is resignated cynicism.
Re: kdeinit
On 21/08/11 15:23, John Layt wrote: So lets turn that on its head. Lets write a statement saying why we need a spec and what it needs to achieve. Mention we have an existing solution that would be a good starting point, but don't actually detail it. Then send that to xdg and Gnome and Unity and anyone else asking who are the right pople to talk to. Hopefully those people then decide it's a good thing and agree to work together to develop a standard. If they're not interested then we get to draft it ourselves knowing there can be no complaints. On the other hand, what's the point of creating a cross-desktop standard without anyone involved from other desktops? We're just creating a KDE standard and slapping a cross-desktop label on it, which is kind of missing the point. Although KGlobalAccel could really do with a nicer D-Bus API. Alex
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
if we start from an all-privileged daemon like systemd. It's privilege elevation that suffers. does the session systemd run privileged in the first place? I have no clue. I don't even know if there's a session systemd. I'm not sure exactly how you people are planning to make use of systemd; but hopefully: - It won't require the operating system to be running systemd as an init system. Any OS/user should be free to use a different/custom init system and still be able to use KDE. - It won't require root privileges to start KDE (including setuid programs). I don't see how dropping privileges from a user account wouldn't work (except perhaps the not implemented part, in which case the right way is to implement it). I suggest you think well whether systemd is indeed the right solution. As far as I see it, it was designed to be used for system services only, and not as a generic framework for controlling services and dependencies (hopefully I'm wrong). I've written some software which might also be used in this place. Please, read it through: http://code.google.com/p/badvpn/wiki/NCD . Yes, it doesn't have everything that would be needed to plug it into KDE right now, but it might be worth looking into because of its simplicity, compared to systemd. Regards, Ambroz
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sun, Aug 21, 2011 at 11:28 AM, Thiago Macieira thi...@kde.org wrote: On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote: if we start from an all-privileged daemon like systemd. It's privilege elevation that suffers. does the session systemd run privileged in the first place? I have no clue. I don't even know if there's a session systemd. systemd can be run in session mode, and I assume this is what is being discussed for possibly replacing kded (using the system instance would not make much sense). The session instance does not have special privileges (just like the dbus session instance). It's great to see this being discussed, having the possibility of integrating systemd with kde would be truly awesome! Cheers, Tom
Re: systemd and KDE (was: Re: kdeinit)
On Sun, Aug 21, 2011 at 5:59 PM, Stefan Majewsky stefan.majew...@googlemail.com wrote: Once I can get a current version of systemd to compile on my machine, I will try to look into this, but of course help is appreciated on all fronts. Feel free to drop by #systemd if you are having trouble with compiling / dependencies (I'm tomegun). Alternatively, Arch Linux ships the latest version of systemd in our community repositories. Cheers, Tom
Re: Review Request: GSoC: Errors handling during file transfer.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102388/ --- (Updated Aug. 21, 2011, 3:21 p.m.) Review request for kdelibs and David Faure. Summary --- Modeless dialog to handle interactions and modifications in CopyJob. Diffs - kio/CMakeLists.txt b517621 kio/kio/copyjob.h eb88c7a kio/kio/copyjob.cpp eff7825 kio/kio/interactiondialog/abstractinteractionitem.h PRE-CREATION kio/kio/interactiondialog/abstractinteractionmodel.h PRE-CREATION kio/kio/interactiondialog/abstractinteractionmodel.cpp PRE-CREATION kio/kio/interactiondialog/allinteractionitem.h PRE-CREATION kio/kio/interactiondialog/allinteractionmodel.h PRE-CREATION kio/kio/interactiondialog/allinteractionmodel.cpp PRE-CREATION kio/kio/interactiondialog/existinginteractionitem.h PRE-CREATION kio/kio/interactiondialog/existinginteractionmodel.h PRE-CREATION kio/kio/interactiondialog/existinginteractionmodel.cpp PRE-CREATION kio/kio/interactiondialog/interactiondialog.h PRE-CREATION kio/kio/interactiondialog/interactiondialog.cpp PRE-CREATION kio/kio/interactiondialog/interactiondialogtab.h PRE-CREATION kio/kio/interactiondialog/interactiondialogtab.cpp PRE-CREATION kio/kio/interactiondialog/renameinteractionwidget.h PRE-CREATION kio/kio/interactiondialog/renameinteractionwidget.cpp PRE-CREATION kio/kio/interactiondialog/requestitemmodel.h PRE-CREATION kio/kio/interactiondialog/requestitemmodel.cpp PRE-CREATION kio/kio/interactiondialog/unreadableinteractionitem.h PRE-CREATION kio/kio/interactiondialog/unreadableinteractionmodel.h PRE-CREATION kio/kio/interactiondialog/unreadableinteractionmodel.cpp PRE-CREATION kio/kio/jobuidelegate.h 25e0728 kio/kio/jobuidelegate.cpp 85679c2 Diff: http://git.reviewboard.kde.org/r/102388/diff Testing --- Thanks, Cyril
Re: kdeinit
On Sunday, 21 de August de 2011 21:07:05 Alex Merry wrote: On 21/08/11 15:23, John Layt wrote: So lets turn that on its head. Lets write a statement saying why we need a spec and what it needs to achieve. Mention we have an existing solution that would be a good starting point, but don't actually detail it. Then send that to xdg and Gnome and Unity and anyone else asking who are the right pople to talk to. Hopefully those people then decide it's a good thing and agree to work together to develop a standard. If they're not interested then we get to draft it ourselves knowing there can be no complaints. On the other hand, what's the point of creating a cross-desktop standard without anyone involved from other desktops? We're just creating a KDE standard and slapping a cross-desktop label on it, which is kind of missing the point. Although KGlobalAccel could really do with a nicer D-Bus API. It wouldn't be the first time someone pushes a spec without a second user of it. But the point is that we should open up the discussion and do the work of elaborating a spec. We have identified a need and we have a solution for it. I'm sure others see the similar problem, even if they don't have the time for it now (à la status notifier spec). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: Review Request: Speed limit in ftp kio slave
On Aug. 10, 2011, 1:07 p.m., David Faure wrote: kioslave/ftp/speedController.h, line 24 http://git.reviewboard.kde.org/r/102267/diff/1/?file=31277#file31277line24 kde_file.h isn't used in this header - move the #include to the .cpp file. Tushar Mehta wrote: I have used it for usleep. If I am not including it then it give me this: error: ‘usleep’ was not declared in this scope usleep is in unistd.h. Include that instead. - Nicolas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102267/#review5593 --- 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: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sun, Aug 21, 2011 at 08:32:07PM +0200, Thiago Macieira wrote: On Sunday, 21 de August de 2011 19:13:43 Oswald Buddenhagen wrote: Considering the audience and considering that KDE has more deployments than GNOME, why can't it be the other way around? this is where we started from. gnome is now serious about making a complete platform. if they succeed, they will win. big time. that's how apple did it, at the technical level. and how kde won't, due to lack of interest (commercial or otherwise) in that area. You seem to imply that we're not serious about doing the same. it's not that we are not serious about it. we don't even try to. Your only argument so far was that we have less manpower than the GNOME team. no, my argument is the *complete* lack of manpower directed at creating a contemporary end-to-end experience for the user and 3rd party developer. we are doing a desktop and stuff on top of it. sometimes a bit of platform comes out of it as a side effect, but that's about it. If you count Canonical as the big driver for a cohesive desktop system, you should count them out already. i was actually thinking primarily of redhat. but that doesn't matter so much if the whole community buys into the idea. There's code that's barely maintained, true. I can think of KIO, for example. kio and kparts, just like qstyles and some other plugin systems we have are not *really* part of the os platform. as far as the user is concerned, only the settings which govern network behavior, widget looks, etc. and the url syntax are part of the platform; the implementations are exchangeable. from a 3rd party dev perspective a common programming platform would be desirable. but i cannot really assess how useful the ability to provide universally usable components would be. it always seemed a bit of a gimmick/niche market to me. Do you think all of Gtk and even glib is fully maintained? i don't consider the toolkits part of the os platform itself. they are available (the lsb says so) and some are used to build the os platform, but in principle they are exchangeable. Should we pull efforts together? Yeah. Not gonna happen, though. that's a rather sad conclusion.
Re: Git migration status (Was: Re: Where is kmix hidden?)
On 21 August 2011 14:05, Lukas Appelhans l.appelh...@gmx.de wrote: Hey! Cool... I see you go for a split up of kdenetwork (makes sense imo). Yup. Definitely. The problem I see at the moment you have to build all applications together in kdenetwork, otherwise they fail to compile. So this is a first thing which needs to change. Others have already answered this - some of the apps already build standalone, others will need a bit of cmake modifications first. What is missing are tags and branches right? Yes. I think I've got the whole trunk history sorted iirc. Haven't done the tags and branches though. -- George
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Monday, 22 de August de 2011 00:07:54 Oswald Buddenhagen wrote: kio and kparts, just like qstyles and some other plugin systems we have are not really part of the os platform. as far as the user is concerned, only the settings which govern network behavior, widget looks, etc. and the url syntax are part of the platform; the implementations are exchangeable. from a 3rd party dev perspective a common programming platform would be desirable. but i cannot really assess how useful the ability to provide universally usable components would be. it always seemed a bit of a gimmick/niche market to me. Do you think all of Gtk and even glib is fully maintained? i don't consider the toolkits part of the os platform itself. they are available (the lsb says so) and some are used to build the os platform, but in principle they are exchangeable. Should we pull efforts together? Yeah. Not gonna happen, though. that's a rather sad conclusion. I'm sorry, I think I've only *now* got your point: your argument is that we're not trying to make system services for the platform and we don't have a master plan on how to get there. The example of KIO being that it's a great technology, but restricted to KDE and there's no effort to expand its userbase. Akonadi, Solid, Phonon and others are counter-examples: they were designed to be part of a platform. They don't have KDE dependencies in their core. Akonadi is especially an example of our trying to build a platform, since it was proposed to fd.o -- Solid and Phonon are more C++ frameworks abstracting other technologies. Also, I agree that Red Hat is pushing a lot of work into improving the platform. Can't fault their engineers for using glib when doing that. But I still think you give the GNOME team too much credit for having a master plan for a platform. From my experience, it's more like us: let's fix what we find broken. But unlike us, they're willing to go to a deeper level and fix the platform -- HAL, udisks, upower, polkit, consolekit, systemd, etc. Sometimes it seems like arrogance that they feel they own it all so they can change everything. But it can also be called boldness: if it's broken, let's redo it. So I agree we're missing a bit of that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center 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: Git migration status (Was: Re: Where is kmix hidden?)
On Sunday 21 August 2011 23:13:30 George Goldberg wrote: On 21 August 2011 14:05, Lukas Appelhans l.appelh...@gmx.de wrote: Hey! Cool... I see you go for a split up of kdenetwork (makes sense imo). Yup. Definitely. The problem I see at the moment you have to build all applications together in kdenetwork, otherwise they fail to compile. So this is a first thing which needs to change. Others have already answered this - some of the apps already build standalone, others will need a bit of cmake modifications first. Yes. I will see what I can do about that in the next weeks. :) What is missing are tags and branches right? Yes. I think I've got the whole trunk history sorted iirc. Haven't done the tags and branches though. Okay. Lukas -- George signature.asc Description: This is a digitally signed message part.
Re: Review Request: Do not terminate threads
On Aug. 21, 2011, 10:29 a.m., David Faure wrote: I think this patch is almost ready, but Dawit's comment seems right about an improvement that should be done to it: - Move all the preemptive lookup logic from the thread's run function to HostInfo::lookupHost. [No need to create a thread when DNS is already cached]. I am a bit confused, as far as I can see, all the preemptive lookup logic is already in HostInfo::lookupHost, what more do you want me to move there? - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102179/#review5875 --- On Aug. 11, 2011, 10:10 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102179/ --- (Updated Aug. 11, 2011, 10:10 p.m.) Review request for kdelibs and Dawit Alemayehu. Summary --- Each time the terminate code triggers my Konqueror crashes, i'm substituting the terminate for just waiting the thread to finish and we just ignoring it. The code has a race condition in which wait() returns false, then we switch to the thread and m_autoDelete is still not set and thus noone will delete the thread. I can add a mutex if you guys think this is unacceptable. Diffs - kio/kio/hostinfo.cpp 344b1d8 Diff: http://git.reviewboard.kde.org/r/102179/diff Testing --- When the kDebug() Name look up for hostName failed; if triggers i do not get a crash anymore. Thanks, Albert
