Re: kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)
On Saturday 01 March 2014 12:49:02 Aurélien Gâteau wrote: I had a look at the CMake code in KJSEmbed: it does not link to any target provided by KDocTools, so CMake Graphviz code does not list it as a dependency. You can declare the dependency manually. I documented how to do it here: http://techbase.kde.org/Policies/KDE_Frameworks_Documentation_Policy#.24fram ework.yaml I can do it if you prefer, but I am interested in finding out whether my doc is understandable :) Done. Let's see if it works :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
reviews
On Sunday 23 February 2014 16:12:58 Albert Astals Cid wrote: El Dissabte, 22 de febrer de 2014, a les 16:52:38, Luigi Toscano va escriure: Hi all, these are the steps of plan for bumping the default DocBook XML version to 4.5 while keeping the compatibility on the old 4.2-based when kde4support is used: 1) commit rename/changes of FindDocBookXML (RR 115876 and 115879); 2) kde4support: copy files FindDocBookXML, catalog.xml, kdex.dtd to kde4support (with history, help or script from Alex Merry needed :) from kdoctools, remove the old compatibility variables, do not install kdex.dtd and catalog.xml for now, rename catalog.xml as catalog4.xml and remove the old content (leave only the definition of 4.2-based DTD). 3a) kdoctools: change the default DTD by renaming kdex.dtd and bumping DocBookXML version number to 4.5; 3b) kde4support: install catalog4.xml and kdex.dtd from kde4support 3c) other modules: fix the documentation of all ported modules to use the new DTD (4.5-based) (temporary breakages in Jenkins are possible). My question is: given the strict time before alpha2, do I need to sent out a RR for every step above (especially 3c), or can I just go and do the changes if you think the plan is fine? I'm not a huge part of the frameworks team, so feel free to ignore me, but sometimes i feel we're overdoing the review thing, i've seen changes that seem trivial to me and that seem to originate from the person that knows most of the code posted to reviewboard. And that's fine if there's people reivewing it in a timely manner but for some not so well known/reviewed places it can stall the flow a bit so personally I wouldn't mind if some things just are commited directly. I tend to agree. Initially it was a good thing because most frameworks committers were newcomers to that code, but by now some of them know what they are doing :-) OTOH it works this way in Qt and it increases quality overall, so I'm a bit on the fence. At least I don't mind if trivial changes go in directly, especially since I also read commits... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116830: Replace use of QPA headers with optional dep on QX11Extras.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116830/ --- Review request for KDE Frameworks, Kevin Ottens and Martin Gräßlin. Repository: kguiaddons Description --- Replace use of QPA headers with optional dep on QX11Extras. If QX11Extras is unavailable, fall-back to dummy implementation, just like when xcb libs are not available, or on Mac/Windows/... Diffs - src/CMakeLists.txt a269b9eadf5ef1119320ced26157530cf8de src/util/kmodifierkeyinfoprovider_x11.cpp f5d2d1a6e5af13e07ed4f184f4222c96347bd70b Diff: https://git.reviewboard.kde.org/r/116830/diff/ Testing --- Compiling kguiaddons with and without qtx11extras available, on Linux/X11. Works. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGuiAddons Review
On Tuesday 04 March 2014 18:46:53 John Layt wrote: Hi, Here's my first pass through KGuiAddons, focussing on the public api. KColorCollection - Should probably become a QSharedDataPointer Maybe. But OTOH it's just a QList, two QStrings and a an enum. KWorkdWrap - // KDE5 TODO: return a value, not a pointer, and use QSharedDataPointer. Done. KModifierKeyInfo - Generally looks OK - Has lots of bool isKeyPressed(Qt::Key) style methods and keyPressed(Qt::Key, bool) style signals when perhaps a KeyState enum would be better? If it's just false/true it seems fine to me, the meaning is in the method name (so this is not the API boolean trap). - Uses X11 / XKB / XCB, will need Wayland backend eventually? Yes, and Mac, and Windows. - Perhaps really belongs in Qt? Yes, but this requires providing implementations for all tier1 platforms in one go... [snip] -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Query: Possible code contribution
On Sunday, 2014-03-16, 00:16:45, Lydia Pintscher wrote: On Fri, Mar 14, 2014 at 2:40 PM, Ganesh Kumar gp29111...@gmail.com wrote: Hi. This is Ganesh P Kumar, doing my B.Tech in Computer Science and Engineering in IIT Madras. As part of our curriculum we must contribute code to an open source project. There is a deadline of 40 days for the project submission. Given this small deadline, I would like to ask for suggestions from the KDE Developer group about what would be a viable project during this time. We are ok with working either with the KDE UI as such, or with any KDE subproject. Also, I would like to add that none of us have any dev experience in KDE before. Would a project to fix several small little issues be viable? Then you could maybe work with the designers/usability team and help them out a bit. 40 days is really not much. One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. CCing the frameworks development list. Cheers, Kevin [1] https://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out [2] http://community.kde.org/Frameworks -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote: Hello all, This week, Aaron brought to my attention (thx!) that we would be releasing 5.0 with modules which would be immediately deprecated. Indeed that's a potential maintenance and messaging problem. Do you have a list of such modules? From Aleix's reply I kind of guess that krunner is one of them? I didn't know it was deprecated. Also, to make things worse, it looks like it makes the definition of Tier 4 harder. I know David and I often end up arguing about it. As a way out I'm putting on the table several options in order to gather feedback about them and see which cocktail we'll apply going forward. Note that we probably want to figure that out soon in order to not make the release of beta 1 more difficult than necessary. Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). Yes. 2) Release the deprecated content as a separate product This one kind of depend on (1). If we redefine Tier 4 and have a separate group of deprecated APIs, maybe we shouldn't make the deprecated content official part of KDE Frameworks. In which case we'd release two products: KDE Frameworks for everyone and KDE Porting Aids (in lack of a better name) containing the deprecated APIs. Clearly they are not of interest to the same audience and that could warrant having two products. Yes. 3) Roll all the deprecated modules into KDE4Support Instead of having several modules containing deprecated APIs as porting aids, and since we have already a module labelled as a porting aid, why not merge everything into a single module? That module obviously would be kde4support. I admit I'm not sure how practical it would be to merge such a large beast like khtml in there, it seems doable though. No. A tier can contain multiple frameworks, that's the difference between a tier and a framework :-) It especially means the tier of a framework can change if necessary, while this is much harder when everything is bundled together. I want to leave the khtml option open (it still has contributors, and could be considered useful in some use cases). 4) Announce the deprecated modules will only be released three times Probably easier if we also apply it with (2). But since they are a porting aid, it might not make sense to keep the release burden throughout the whole KDE Frameworks 5 lifetime, to finally stop releasing them in the distant future of KDE Frameworks 6. That's especially true because of the limited manpower, and it's not exactly easy on the morale to actively maintain and release something that everyone is running from. So, what about being honest with ourselves and limit the number of releases the deprecated modules would have? If we go that route, I propose only three releases (5.0, 5.1 and 5.2) and then we stop, that should give plenty of time for people to port away, especially since it would probably keep working longer (KDE Porting Aids 5.2 would likely work on top of KDE Frameworks 5.4 for instance), it's just that we won't make any special effort anymore to keep it working. I would say we'll see. As it is written above, all it means is that we're closing the door to fixing bugs after 5.2. I don't see any benefit in that, only downsides. The effort in releasing one more module amongst 57+ is negligible. There's a middle ground between actively maintain and we made it completely impossible to even fix one bug. ... or to follow a change in ECM, or whatever. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Unknown media types
On Saturday 15 March 2014 19:24:08 Michael Palimaka wrote: Hi, kcoreaddons installs /usr/share/mime/packages/kde5.xml which causes the following warnings when update-mime-database is executed: Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' This has been around for a long time, but are they actually used by anything anymore and if not, is this a good opportunity to clean it up? The question comes up regularly, but it would be useful if you could actually do some research on who uses these uri/ mimetypes. For all/all and all/allfiles I can answer it: all/allfiles can be removed and replaced with application/octet-stream, all/all is basically application/octet-stream+inode/directory (everything is either a file or a directory). You can adjust the code below, and then document the change in the porting docs, and then remove the mimetypes from kde5.xml. ./kde4support/tests/kfstest.cpp:63:filter all/allfiles text/plain; ./kde4support/tests/kfstest.cpp:64:dlg-setMimeFilter(filter, all/allfiles); ./kde4support/tests/kfstest.cpp:142:filter all/allfiles text/plain; ./kde4support/tests/kfstest.cpp:143:dlg-setMimeFilter(filter, all/allfiles); ./kde4support/src/kio/kfiledialog.h:243: * To add a filter item for all files matching @c '*', add @c all/allfiles ./kservice/src/kbuildsycoca/kbuildservicefactory.cpp:172:// TODO do the same for all/all and all/allfiles, if (!KServiceTypeProfile::configurationMode()) ./kservice/src/services/kservicetypeprofile.h:66: * This method activates a special mode of KServiceTypeProfile, in which all/all ./kservice/src/services/kservicetypeprofile.h:67: * and all/allfiles are excluded from the results of the queries. ./kio/src/filewidgets/kfilefiltercombo.cpp:190: d-m_filters.append(QLatin1String(all/allfiles)); -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks book
On Saturday 15 March 2014 02:08:52 Valorie Zimmerman wrote: Hello frameworks developers, It has been discussed on the KDE-Community list that some of you would like a Frameworks book. I would strongly suggest that this is not ONLY a paper book but also an online book where updates get published, e.g. like the french Qt5 book works. Otherwise in 2 years it's only good for lighting a fire. /me remembers writing chapters in a book about KDE 2.0 which never got updated... quite a waste. Anyhow - no time for writing. At most I can review some text about the frameworks I know most about. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks book
On Sunday, 2014-03-16, 11:50:26, David Faure wrote: On Saturday 15 March 2014 02:08:52 Valorie Zimmerman wrote: Hello frameworks developers, It has been discussed on the KDE-Community list that some of you would like a Frameworks book. I would strongly suggest that this is not ONLY a paper book but also an online book where updates get published, e.g. like the french Qt5 book works. Not sure this would work here but a couple of months back I bought a NodeJS book on LeanPub [1] and since then I get notification emails when a new version has been published and can be downloaded again. Cheers, Kevin [1] https://leanpub.com/ -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116689: KCoreConfigSkeleton: delay parsing until the call to readConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116689/ --- (Updated March 16, 2014, 11:03 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- KCoreConfigSkeleton: delay parsing until the call to readConfig() Diffs - src/core/kconfig.h d27eebe7c41cb433b1808882c53cbf7b4c870950 src/core/kconfig.cpp 5b51cce8c62c2c4de91baddcd3fb2893b842326d src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f Diff: https://git.reviewboard.kde.org/r/116689/diff/ Testing --- strace -e open kate | grep -v NOENT | grep oxygenrc goes from 4 to 3 (still three because the same KSharedConfig is used in 3 skeletons - 3 * readConfig calling reparseConfiguration) To go further down we could add a flag to readConfig() Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 8:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Re: KF5 alpha2
On Wednesday 12 March 2014 12:21:36 Christoph Cullmann wrote: David Faure wrote: On Wednesday 05 March 2014 19:29:34 Michael Palimaka wrote: Hi, KTextEditor is listed as tier 3, but is missing from this (and previous) releases. It is not part of the KF 5.0 release, it targets 5.1. Hi, is there any reason for that? Would delay us from releasing some KF 5 port of Kate for common consumption after the KF 5.0 release. No idea, please ask the KTextEditor maintainers. Wait, that's you... I thought this was a request from you, because it wouldn't be ready for 5.0? I'm confused. What made me think so is that it's under 5.1 in the wiki page http://community.kde.org/Frameworks/Epics and that it still has many SIC changes TODO there. So I thought this was intentional. If it's not, let's fix that quickly. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kde4support won't compile against today's qtbase-stable
src/CMakeFiles/KF5KDE4Support.dir/kio/kfiledialog.cpp.o: In function `KFileDialogQtOverride::~KFileDialogQtOverride()': kfiledialog.cpp: (.text._ZN21KFileDialogQtOverrideD2Ev[_ZN21KFileDialogQtOverrideD5Ev]+0x3): undefined reference to `qt_filedialog_existing_directory_hook' kfiledialog.cpp: (.text._ZN21KFileDialogQtOverrideD2Ev[_ZN21KFileDialogQtOverrideD5Ev]+0x16): undefined reference to `qt_filedialog_open_filename_hook' kfiledialog.cpp: (.text._ZN21KFileDialogQtOverrideD2Ev[_ZN21KFileDialogQtOverrideD5Ev]+0x29): undefined reference to `qt_filedialog_open_filenames_hook' kfiledialog.cpp: (.text._ZN21KFileDialogQtOverrideD2Ev[_ZN21KFileDialogQtOverrideD5Ev]+0x3c): undefined reference to `qt_filedialog_save_filename_hook' src/CMakeFiles/KF5KDE4Support.dir/kio/kfiledialog.cpp.o: In function `_GLOBAL__sub_I_kfiledialog.cpp': kfiledialog.cpp:(.text.startup+0x2d): undefined reference to `qt_filedialog_existing_directory_hook' kfiledialog.cpp:(.text.startup+0x3a): undefined reference to `qt_filedialog_open_filename_hook' kfiledialog.cpp:(.text.startup+0x47): undefined reference to `qt_filedialog_open_filenames_hook' kfiledialog.cpp:(.text.startup+0x54): undefined reference to `qt_filedialog_save_filename_hook' ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
[: John Layt :] Or do we list all languages regardless of whether they are installed or not (probably way too many)? [: Chusslove Illich :] I would rather go this way, have this finished once and for all. I would only try to clearly present it not as you will get this language when you choose it but as this is the list of your preferred languages, you get first there is. [: Albert Astals Cid :] Is this really usable? I could choose three languages just to see i still get my text in english and then say this is crap, KDE is not translated to any language without realizing i actually have to install those languages translations. With standard Gettext approach it was always like this: user language selection are preferred languages, not necessarily available. The user sets LANG for the locale and the single main language, and possibly LANGUAGES for special order of preference. In GUI context, the login manager lets user chose one of the locales and that's it. If some translation is available but not installed, no hand-holding. With the intention being that the KCM now controls LANGUAGES, i.e. that it can set the language for all Gettext-using software in the session, I don't see how we could even define available languages. Looking through usual system locations with MO files does not mean all MO files will be found; even for those that are found and languages collected, the user might use entirely different set of software, that has no translation in the chosen language. The related problem for me is this: why are there still standalone language packages for some of KDE software (the SC)? Other than historical reasons, the only advantage I see is installation space. But I don't see anyone complaining about all the other Gettext-using software coming with all translations. In fact, for me installing the standalone language package is always one more thing to remember to do, or to explain to people that they should do. I think that the only reasonable thing for Frameworks themselves is to ship with translations as part of each framework. Some packaging scripts will have to be adapted to make this easy on the release person. I would suggest using the same system for everything else that was so far covered by standalone language packages, and doing away with them. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kde4support won't compile against today's qtbase-stable
On Sunday 16 March 2014 14:48:34 Treeve Jelbert wrote: kfiledialog.cpp:(.text.startup+0x47): undefined reference to `qt_filedialog_open_filenames_hook' kfiledialog.cpp:(.text.startup+0x54): undefined reference to `qt_filedialog_save_filename_hook' Right. Fixed. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: reviews
On Sunday 16 March 2014 10:16:17 David Faure wrote: On Sunday 23 February 2014 16:12:58 Albert Astals Cid wrote: I tend to agree. Initially it was a good thing because most frameworks committers were newcomers to that code, but by now some of them know what they are doing :-) OTOH it works this way in Qt and it increases quality overall, so I'm a bit on the fence. Note that review doesn't necessarily means go through reviewboard, that's in fact something we thought about: http://community.kde.org/Frameworks/Policies#Frameworks_commits_are_reviewed At least I don't mind if trivial changes go in directly, especially since I also read commits... That means defining what is trivial though. :-) Now, I think it's also more a question of are you the maintainer of what you're touching? For instance, Luigi is obviously our kdoctools master... Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Meta key and Qt (Re: kglobalaccel fixes)
On Tuesday 11 March 2014 13:54:56 Sebastian Kügler wrote: One thing is a bit puzzling, perhaps someone knows how to go about this: The meta key behaves different now, when I edit a shortcut, it's accepted as soon as I press the meta key, so it's not seen as a modifier, but as a key of its own. This means that one can effectively (through the GUI) only assign meta to an action, but not, for example meta+arrow_left. Any ideas how to best fix this? Could be a bug in the XKB code inside Qt. I tried to look into it, but how do you actually get a meta key in the first place? I tried rebinding the Windows key to Meta in xmodmap [*], and it works in `xev`, but the keyval in Qt is Qt::Key_Multi_key which activates compose sequences in this file: qtbase/src/plugins/platforminputcontexts/compose/qcomposeplatforminputcontext.cpp Looks like this code works on keycodes, not keysyms, so it basically ignores my xmodmap configuration. [*] keycode 133 = Meta_L Meta_L Meta_L Meta_L -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116087: remove usage of strlcpy
On March 16, 2014, 9:12 a.m., David Faure wrote: src/kcrash.cpp, line 56 https://git.reviewboard.kde.org/r/116087/diff/3/?file=254139#file254139line56 I just realized that this requires qpa-private headers, which is a problem (breaks compat when upgrading Qt, too). See k-f-d thread kguiaddons uses qpa headers?. We could add a QX11Info::startupId() instead? Makes me wonder how startup notification is supposed to work on wayland though - and whether I should resurrect the idea of a DBus-based startup notification at the upcoming freedesktop meeting. Kevin Krammer queried just how private the private headers really are in that thread... WRT the D-Bus startup notification, I'm greatly in favour. I think Martin Gräßlin is as well, from previous email/reviewboard threads. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/#review53028 --- On March 15, 2014, 3:31 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/ --- (Updated March 15, 2014, 3:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kcrash Description --- remove usage of strlcpy We can get the startupId from the QPlatformNativeInterface. Additionally this means we no longer need to link to KWindowSystem. REVIEW: 116087 Diffs - src/CMakeLists.txt d19b97f98e057d5537cf0eb6a8e1997d2a24cb1e KF5CrashConfig.cmake.in dcde84376e7ea69e53a26dc2bcba8137ee28a2a4 CMakeLists.txt b9a6f441abed3c88bf428869c30ef5aebd72fc74 src/strlcpy-fake.c 9b2dc68c466908d11370ba0c4bbe8d315962da5d src/kcrash.cpp 6c41022206130f186d52ddbb77afd58c429f368f src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8 Diff: https://git.reviewboard.kde.org/r/116087/diff/ Testing --- Compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116830: Replace use of QPA headers with optional dep on QX11Extras.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116830/#review53079 --- Looks good to me, but someone else has to approve - Martin Gräßlin On March 16, 2014, 10:32 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116830/ --- (Updated March 16, 2014, 10:32 a.m.) Review request for KDE Frameworks, Kevin Ottens and Martin Gräßlin. Repository: kguiaddons Description --- Replace use of QPA headers with optional dep on QX11Extras. If QX11Extras is unavailable, fall-back to dummy implementation, just like when xcb libs are not available, or on Mac/Windows/... Diffs - src/CMakeLists.txt a269b9eadf5ef1119320ced26157530cf8de src/util/kmodifierkeyinfoprovider_x11.cpp f5d2d1a6e5af13e07ed4f184f4222c96347bd70b Diff: https://git.reviewboard.kde.org/r/116830/diff/ Testing --- Compiling kguiaddons with and without qtx11extras available, on Linux/X11. Works. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 3:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 8:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Re: Review Request 116798: Rewrite KUser/KUserGroup Widows implementation + introduce KUserId/KGroupId
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/#review53141 --- This review has been submitted with commit 1adb574a6118a19060dbcf243f0a4fbbc0f0518d by Alex Richardson to branch master. - Commit Hook On March 16, 2014, 9:55 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/ --- (Updated March 16, 2014, 9:55 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- This was all started in order to get KIO to compile on Windows (uses uid_t/gid_t, getpwent, getpwuid, getuid, etc.) This patchset introduces KUserId/KGroupId which is a no-overhead wrapper around uid_t/gid_t and implicitly shares a SID on Windows. Also introduced a maxCount paramter to all listing functions of KUser/KUserGroup so that the manual calls to getpwent() in KIO can be replaced Finally added a unit test for KUser, KUserGroup, KUserId, KGroupId to ensure that these changes are safe Windows only changes: - KUser::homeDirectory() works properly, before it always returned the home directory of the current user - KUser::faceIconPath() is now implemented on Windows - Use scoped pointers everywhere - no memory leaks (at least one was fixed) This is actually a series of commits, if you think that is easier to review I can push them somewhere. Diffs - autotests/CMakeLists.txt 30ac97822a77e4b12b0e81a4a5c93fe9a768d915 autotests/kusertest.cpp PRE-CREATION src/lib/util/kuser.h 42c81156831d0269c89435c76c3572dcf2e085b5 src/lib/util/kuser_unix.cpp aa2f9073015c7f9feb8f74e3646928d2fa2de007 src/lib/util/kuser_win.cpp 06759afa34ea7015a44cf9b38f541f944f8126d4 Diff: https://git.reviewboard.kde.org/r/116798/diff/ Testing --- Wrote new unit test, passes on Linux and Windows, KIO is closer to compiling on windows Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116798: Rewrite KUser/KUserGroup Widows implementation + introduce KUserId/KGroupId
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/#review53140 --- This review has been submitted with commit 43e2a658d1f1053c4c0ee7ae739f1645405e0de8 by Alex Richardson to branch master. - Commit Hook On March 15, 2014, 4:02 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/ --- (Updated March 15, 2014, 4:02 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- This was all started in order to get KIO to compile on Windows (uses uid_t/gid_t, getpwent, getpwuid, getuid, etc.) This patchset introduces KUserId/KGroupId which is a no-overhead wrapper around uid_t/gid_t and implicitly shares a SID on Windows. Also introduced a maxCount paramter to all listing functions of KUser/KUserGroup so that the manual calls to getpwent() in KIO can be replaced Finally added a unit test for KUser, KUserGroup, KUserId, KGroupId to ensure that these changes are safe Windows only changes: - KUser::homeDirectory() works properly, before it always returned the home directory of the current user - KUser::faceIconPath() is now implemented on Windows - Use scoped pointers everywhere - no memory leaks (at least one was fixed) This is actually a series of commits, if you think that is easier to review I can push them somewhere. Diffs - autotests/CMakeLists.txt 30ac97822a77e4b12b0e81a4a5c93fe9a768d915 autotests/kusertest.cpp PRE-CREATION src/lib/util/kuser.h 42c81156831d0269c89435c76c3572dcf2e085b5 src/lib/util/kuser_unix.cpp aa2f9073015c7f9feb8f74e3646928d2fa2de007 src/lib/util/kuser_win.cpp 06759afa34ea7015a44cf9b38f541f944f8126d4 Diff: https://git.reviewboard.kde.org/r/116798/diff/ Testing --- Wrote new unit test, passes on Linux and Windows, KIO is closer to compiling on windows Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116798: Rewrite KUser/KUserGroup Widows implementation + introduce KUserId/KGroupId
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/ --- (Updated March 16, 2014, 9:55 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- This was all started in order to get KIO to compile on Windows (uses uid_t/gid_t, getpwent, getpwuid, getuid, etc.) This patchset introduces KUserId/KGroupId which is a no-overhead wrapper around uid_t/gid_t and implicitly shares a SID on Windows. Also introduced a maxCount paramter to all listing functions of KUser/KUserGroup so that the manual calls to getpwent() in KIO can be replaced Finally added a unit test for KUser, KUserGroup, KUserId, KGroupId to ensure that these changes are safe Windows only changes: - KUser::homeDirectory() works properly, before it always returned the home directory of the current user - KUser::faceIconPath() is now implemented on Windows - Use scoped pointers everywhere - no memory leaks (at least one was fixed) This is actually a series of commits, if you think that is easier to review I can push them somewhere. Diffs - autotests/CMakeLists.txt 30ac97822a77e4b12b0e81a4a5c93fe9a768d915 autotests/kusertest.cpp PRE-CREATION src/lib/util/kuser.h 42c81156831d0269c89435c76c3572dcf2e085b5 src/lib/util/kuser_unix.cpp aa2f9073015c7f9feb8f74e3646928d2fa2de007 src/lib/util/kuser_win.cpp 06759afa34ea7015a44cf9b38f541f944f8126d4 Diff: https://git.reviewboard.kde.org/r/116798/diff/ Testing --- Wrote new unit test, passes on Linux and Windows, KIO is closer to compiling on windows Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 3:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Jenkins build became unstable: kcoreaddons_master_qt5 #39
See http://build.kde.org/job/kcoreaddons_master_qt5/39/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116087: remove usage of strlcpy
On March 16, 2014, 10:12 a.m., David Faure wrote: src/kcrash.cpp, line 56 https://git.reviewboard.kde.org/r/116087/diff/3/?file=254139#file254139line56 I just realized that this requires qpa-private headers, which is a problem (breaks compat when upgrading Qt, too). See k-f-d thread kguiaddons uses qpa headers?. We could add a QX11Info::startupId() instead? Makes me wonder how startup notification is supposed to work on wayland though - and whether I should resurrect the idea of a DBus-based startup notification at the upcoming freedesktop meeting. Alex Merry wrote: Kevin Krammer queried just how private the private headers really are in that thread... WRT the D-Bus startup notification, I'm greatly in favour. I think Martin Gräßlin is as well, from previous email/reviewboard threads. Should I then commit the first version of this patch until we have a proper solution? - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/#review53028 --- On March 15, 2014, 4:31 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/ --- (Updated March 15, 2014, 4:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kcrash Description --- remove usage of strlcpy We can get the startupId from the QPlatformNativeInterface. Additionally this means we no longer need to link to KWindowSystem. REVIEW: 116087 Diffs - src/CMakeLists.txt d19b97f98e057d5537cf0eb6a8e1997d2a24cb1e KF5CrashConfig.cmake.in dcde84376e7ea69e53a26dc2bcba8137ee28a2a4 CMakeLists.txt b9a6f441abed3c88bf428869c30ef5aebd72fc74 src/strlcpy-fake.c 9b2dc68c466908d11370ba0c4bbe8d315962da5d src/kcrash.cpp 6c41022206130f186d52ddbb77afd58c429f368f src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8 Diff: https://git.reviewboard.kde.org/r/116087/diff/ Testing --- Compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 8:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Re: Review Request 116087: remove usage of strlcpy
On March 16, 2014, 9:12 a.m., David Faure wrote: src/kcrash.cpp, line 56 https://git.reviewboard.kde.org/r/116087/diff/3/?file=254139#file254139line56 I just realized that this requires qpa-private headers, which is a problem (breaks compat when upgrading Qt, too). See k-f-d thread kguiaddons uses qpa headers?. We could add a QX11Info::startupId() instead? Makes me wonder how startup notification is supposed to work on wayland though - and whether I should resurrect the idea of a DBus-based startup notification at the upcoming freedesktop meeting. Alex Merry wrote: Kevin Krammer queried just how private the private headers really are in that thread... WRT the D-Bus startup notification, I'm greatly in favour. I think Martin Gräßlin is as well, from previous email/reviewboard threads. Alexander Richardson wrote: Should I then commit the first version of this patch until we have a proper solution? We just got rid of qpa private headers in kguiaddons, I'm not sure that creating the same issue in kcrash is a good idea, especially since the code works right now, without that. We could instead add QX11Info::startupId() and ifdef based on the Qt version? - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/#review53028 --- On March 15, 2014, 3:31 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/ --- (Updated March 15, 2014, 3:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kcrash Description --- remove usage of strlcpy We can get the startupId from the QPlatformNativeInterface. Additionally this means we no longer need to link to KWindowSystem. REVIEW: 116087 Diffs - src/CMakeLists.txt d19b97f98e057d5537cf0eb6a8e1997d2a24cb1e KF5CrashConfig.cmake.in dcde84376e7ea69e53a26dc2bcba8137ee28a2a4 CMakeLists.txt b9a6f441abed3c88bf428869c30ef5aebd72fc74 src/strlcpy-fake.c 9b2dc68c466908d11370ba0c4bbe8d315962da5d src/kcrash.cpp 6c41022206130f186d52ddbb77afd58c429f368f src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8 Diff: https://git.reviewboard.kde.org/r/116087/diff/ Testing --- Compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116845: Add KCoreConfigSkeleton::read() which doesn't call reparseConfiguration.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116845/ --- Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- Add KCoreConfigSkeleton::read() which doesn't call reparseConfiguration. Call it from generated singletons, since the constructor creates a KConfig from a filename, which already loads from disk. This removes the need for using DelayedParsing. Diffs - autotests/kconfig_compiler/test4main.cpp 8f1c1ec8d41ea123893a59526c52cdbd0b5ee075 autotests/kconfig_compiler/test5.cpp.ref 088cc78f4dc96a719628ece342e149553c1d22aa autotests/kconfig_compiler/test8b.cpp.ref dcd61693ff86f02eaeb93b4c4da9e6ed20463469 autotests/kconfig_compiler/test_dpointer.cpp.ref e50bf8aa29a2d009c4156dabf429c3ffb74eb7ba autotests/kconfig_compiler/test_signal.cpp.ref 35b5cba2736761753d1ba32baa6f9fc2e7808ba1 autotests/kconfigskeletontest.cpp 31278e767655f7e3d25a4ed9984345e8c4e67d82 src/core/kcoreconfigskeleton.h a2b828a4ef3f881b551049901d4bc26bb23a014b src/core/kcoreconfigskeleton.cpp 0c1a96faaa9c511d349a26ad8af4b7b2c9bf313e src/kconfig_compiler/kconfig_compiler.cpp 7d84cfbc28b1648ca999116726455183d88a7f0a autotests/kconfig_compiler/test4.cpp.ref 66d0357f114b0aca6148a2091880dd2f62fbf624 autotests/kconfig_compiler/test1main.cpp d7dc038d91d2f8babcd281960100d1c6fa264d7c autotests/kconfig_compiler/test10.cpp.ref 21aea9d87af5fce01e64032257283e0883af2d81 Diff: https://git.reviewboard.kde.org/r/116845/diff/ Testing --- Added two unittests (which is how I discovered I had to remove DelayedParsing, so the tests were useful). The bool ok + qWarning thing is a bit clumsy, maybe we want to port these main() to qtestlib too, even though they are themselves executed by a unittest :-) Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kxmlgui_master_qt5 #73
See http://build.kde.org/job/kxmlgui_master_qt5/73/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 3:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Re: Review Request 116087: remove usage of strlcpy
On March 16, 2014, 10:12 a.m., David Faure wrote: src/kcrash.cpp, line 56 https://git.reviewboard.kde.org/r/116087/diff/3/?file=254139#file254139line56 I just realized that this requires qpa-private headers, which is a problem (breaks compat when upgrading Qt, too). See k-f-d thread kguiaddons uses qpa headers?. We could add a QX11Info::startupId() instead? Makes me wonder how startup notification is supposed to work on wayland though - and whether I should resurrect the idea of a DBus-based startup notification at the upcoming freedesktop meeting. Alex Merry wrote: Kevin Krammer queried just how private the private headers really are in that thread... WRT the D-Bus startup notification, I'm greatly in favour. I think Martin Gräßlin is as well, from previous email/reviewboard threads. Alexander Richardson wrote: Should I then commit the first version of this patch until we have a proper solution? David Faure wrote: We just got rid of qpa private headers in kguiaddons, I'm not sure that creating the same issue in kcrash is a good idea, especially since the code works right now, without that. We could instead add QX11Info::startupId() and ifdef based on the Qt version? I mean the version where the QByteArray is just stored on the stack to increase the refcount. Adding QX11Info::startupId() is obviously the better solution, but that will only be useful once we depend on Qt 5.4 - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/#review53028 --- On March 15, 2014, 4:31 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/ --- (Updated March 15, 2014, 4:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kcrash Description --- remove usage of strlcpy We can get the startupId from the QPlatformNativeInterface. Additionally this means we no longer need to link to KWindowSystem. REVIEW: 116087 Diffs - src/CMakeLists.txt d19b97f98e057d5537cf0eb6a8e1997d2a24cb1e KF5CrashConfig.cmake.in dcde84376e7ea69e53a26dc2bcba8137ee28a2a4 CMakeLists.txt b9a6f441abed3c88bf428869c30ef5aebd72fc74 src/strlcpy-fake.c 9b2dc68c466908d11370ba0c4bbe8d315962da5d src/kcrash.cpp 6c41022206130f186d52ddbb77afd58c429f368f src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8 Diff: https://git.reviewboard.kde.org/r/116087/diff/ Testing --- Compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
how to write kded module in framework 5
Hello fellow developers ! :) I am noob in kde and hacking keyboard module these days ! I tried to instantiate object of class keyboardDaemon and I got this error : In file included from /home/amourphious/kde-workspace/kcontrol/keyboard/kcm_keyboard.cpp:37:0: /home/amourphious/kde-workspace/kcontrol/keyboard/keyboard_daemon.h:27:24: fatal error: kdedmodule.h: No such file or directory #include kdedmodule.h I using KDEDModule instead of kdemodule.h which resulted into : In file included from /home/amourphious/kde-workspace/kcontrol/keyboard/keyboard_daemon.h:23:0, from /home/amourphious/kde-workspace/kcontrol/keyboard/kcm_keyboard.cpp:37: /home/amourphious/kf5/inst/include/KF5/KDE4Support/KDE/KDEDModule:1:24: fatal error: kdedmodule.h: No such file or directory #include kdedmodule.h in Kf5 install directory the kdedmodule.h and KDEDModule can be found at /home/amourphious/kf5/inst/include/KF5/KDBusAddons but code is looking at /home/amourphious/kf5/inst/include/KF5/KDE4Support/KDE/KDEDModule *is there any different way to write kded module in framework 5 ?oris there a way by which I can make the code look at right place to find kdedmodule ?or am I doing something wrong ?* keyboard module is not functioning properly due to this. Thanking you ! Regards Shivam Makkar amourphious.appspot.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next - Translations KCM - What Languages?
El Diumenge, 16 de març de 2014, a les 15:49:02, Chusslove Illich va escriure: [: John Layt :] Or do we list all languages regardless of whether they are installed or not (probably way too many)? [: Chusslove Illich :] I would rather go this way, have this finished once and for all. I would only try to clearly present it not as you will get this language when you choose it but as this is the list of your preferred languages, you get first there is. [: Albert Astals Cid :] Is this really usable? I could choose three languages just to see i still get my text in english and then say this is crap, KDE is not translated to any language without realizing i actually have to install those languages translations. With standard Gettext approach it was always like this: user language selection are preferred languages, not necessarily available. The user sets LANG for the locale and the single main language, and possibly LANGUAGES for special order of preference. In GUI context, the login manager lets user chose one of the locales and that's it. If some translation is available but not installed, no hand-holding. With the intention being that the KCM now controls LANGUAGES, Is that happening? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116845: Add KCoreConfigSkeleton::read() which doesn't call reparseConfiguration.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116845/#review53151 --- The unit test situation seems far from ideal, but since it fits with the current setup it can be left for now. Changing them can be left for another patch :) Otherwise, I imagined readConfig would become a regular method, and read is the new virtual method to implement to override the KConfig parsing. I've opened some issues about that below. Also, I'd like to get the usrReadConfig function renamed in this patch, as we were discussing in RR #116461, unless we decide to leave the name alone. src/core/kcoreconfigskeleton.h https://git.reviewboard.kde.org/r/116845/#comment37415 Regarding the virtual methods, once they change this needs to be updated. src/core/kcoreconfigskeleton.h https://git.reviewboard.kde.org/r/116845/#comment37412 Can you remove the virtual from readConfig, since there isn't a reason to override readConfig, and may in fact break if other code uses read() instead. src/core/kcoreconfigskeleton.h https://git.reviewboard.kde.org/r/116845/#comment37414 Regarding the virtual methods, once they change this needs to be updated. src/core/kcoreconfigskeleton.h https://git.reviewboard.kde.org/r/116845/#comment37413 I can't find any instances (lxr.kde.org returns way too many results to thoroughly check) where readConfig() was overridden and I don't know why you would want to override it, but since some users may have anyways I'd prefer if read() stayed a virtual for compatibility, since it replaces readConfig. src/core/kcoreconfigskeleton.cpp https://git.reviewboard.kde.org/r/116845/#comment37416 I'd prefer to keep the same behaviour we implemented before. This allows for applications to make use of the optimization if they haven't been ported yet. It also reduces developer thought in the simple case, as they can just always call readConfig/loadConfig, and be ensured they get the latest values from disk, while avoiding an extra read off disk. That leaves the read() function there as an optimization for the more advanced cases. src/core/kcoreconfigskeleton.cpp https://git.reviewboard.kde.org/r/116845/#comment37410 Since we are modifying this function, can you also kill this line please? - Matthew Dawson On March 16, 2014, 7:08 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116845/ --- (Updated March 16, 2014, 7:08 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- Add KCoreConfigSkeleton::read() which doesn't call reparseConfiguration. Call it from generated singletons, since the constructor creates a KConfig from a filename, which already loads from disk. This removes the need for using DelayedParsing. Diffs - autotests/kconfig_compiler/test4main.cpp 8f1c1ec8d41ea123893a59526c52cdbd0b5ee075 autotests/kconfig_compiler/test5.cpp.ref 088cc78f4dc96a719628ece342e149553c1d22aa autotests/kconfig_compiler/test8b.cpp.ref dcd61693ff86f02eaeb93b4c4da9e6ed20463469 autotests/kconfig_compiler/test_dpointer.cpp.ref e50bf8aa29a2d009c4156dabf429c3ffb74eb7ba autotests/kconfig_compiler/test_signal.cpp.ref 35b5cba2736761753d1ba32baa6f9fc2e7808ba1 autotests/kconfigskeletontest.cpp 31278e767655f7e3d25a4ed9984345e8c4e67d82 src/core/kcoreconfigskeleton.h a2b828a4ef3f881b551049901d4bc26bb23a014b src/core/kcoreconfigskeleton.cpp 0c1a96faaa9c511d349a26ad8af4b7b2c9bf313e src/kconfig_compiler/kconfig_compiler.cpp 7d84cfbc28b1648ca999116726455183d88a7f0a autotests/kconfig_compiler/test4.cpp.ref 66d0357f114b0aca6148a2091880dd2f62fbf624 autotests/kconfig_compiler/test1main.cpp d7dc038d91d2f8babcd281960100d1c6fa264d7c autotests/kconfig_compiler/test10.cpp.ref 21aea9d87af5fce01e64032257283e0883af2d81 Diff: https://git.reviewboard.kde.org/r/116845/diff/ Testing --- Added two unittests (which is how I discovered I had to remove DelayedParsing, so the tests were useful). The bool ok + qWarning thing is a bit clumsy, maybe we want to port these main() to qtestlib too, even though they are themselves executed by a unittest :-) Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: krunner_master_qt5 #33
See http://build.kde.org/job/krunner_master_qt5/33/changes Changes: [scripty] SVN_SILENT made messages (.desktop file) -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 1 (PACKAGER LINBUILDER) in workspace http://build.kde.org/job/krunner_master_qt5/ws/ Running Prebuild steps [krunner_master_qt5] $ /bin/sh -xe /tmp/hudson7827232217656112022.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/krunner 02459be..4b9a2c6 master - origin/master From git://anongit.kde.org/krunner * [new tag] v4.97.0- v4.97.0 Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 02459be SVN_SILENT made messages (.desktop file) Removing build/ Removing install/ Success build forhudson.tasks.Shell@7dde938f Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/krunner Checking out Revision 4b9a2c63e2bc82a36b5183db4fcf90e0abc7b30b (refs/heads/jenkins) Run condition [File exists] enabling prebuild for step [Publish JUnit test result report] Run condition [File exists] enabling prebuild for step [Publish Cppcheck results] [krunner_master_qt5] $ /bin/sh -xe /tmp/hudson6699161004508333553.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: krunner - Branch master == Build Dependencies: kcrash - Branch master kdesupport-svn - Branch master kauth - Branch master knotifications - Branch master kxmlgui - Branch master kbookmarks - Branch master kcodecs - Branch master polkit-qt-1 - Branch qt5 kservice - Branch master threadweaver - Branch master qt5 - Branch stable extra-cmake-modules - Branch master ktextwidgets - Branch master kwidgetsaddons - Branch master karchive - Branch master kprintutils - Branch master kio - Branch master kconfigwidgets - Branch master kjs - Branch master kcoreaddons - Branch master kiconthemes - Branch master kdnssd-framework - Branch master kglobalaccel - Branch master kjobwidgets - Branch master solid - Branch master phonon - Branch master kdbusaddons - Branch master kdoctools - Branch master kidletime - Branch master kguiaddons - Branch master kactivities - Branch master plasma-framework - Branch master kitemmodels - Branch master kwallet - Branch master kunitconversion - Branch master kross - Branch master cmake - Branch master kparts - Branch master sonnet - Branch master kitemviews - Branch master kcompletion - Branch master ki18n - Branch master ktexteditor - Branch master kconfig - Branch master kwindowsystem - Branch master kdeclarative - Branch master == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Warning (dev) at src/declarative/CMakeLists.txt:1 (project): Policy CMP0048 is not set: project() command manages VERSION variables. Run cmake --help-policy CMP0048 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The following variable(s) would be set to empty: PROJECT_VERSION_MAJOR PROJECT_VERSION_MINOR PROJECT_VERSION_PATCH This warning is for project developers. Use -Wno-dev to suppress it. -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success -- Performing Test COMPILER_HAS_DEPRECATED_ATTR -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success -- -- The following REQUIRED packages have been found: * Qt5Gui * Qt5Network (required version = 5.3.0) * Qt5Qml (required version = 5.3.0) * Qt5Quick * KF5Config (required version = 4.97.0) * KF5CoreAddons (required version = 4.97.0) * KF5I18n (required version = 4.97.0) * KF5KIO (required version = 4.97.0) * KF5Service (required version = 4.97.0) * Qt5Core (required version = 5.2.0) * ECM (required version = 0.0.9) * KF5Plasma (required version = 4.97.0) * KF5Solid (required version = 4.97.0) * KF5ThreadWeaver (required version = 4.97.0) * Qt5Test * Qt5 (required version = 5.2.0)
Re: Review Request 116570: Ask user for confirmation before doing POST - POST redirection in KIO
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116570/#review53047
---
First of all it's worth to mention about th proposed update for rfc2616
(http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26) that makes
asking user confirmation optional (see
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#page-53 and
subsequents). It states: ...the user agent MAY automatically redirect its
request to the URI referenced by the Location field value...
I tested some other clients and it seems that only Firefox prompts the user
about redirection when method of subsequent request is considered unsafe
(namely DELETE, POST, PUT).
About the patch i can see two issues.
1) I think real method string sent in the request should be checked instead,
as for example http_post + CustomHTTPMethod can have been used.
2) When the user do not approve the redirection no data is sent back to client
(data == server's redirection response payload).
May be prompting the user *before* the redirection handling code take place
(and only if the server have sent back a valid a Location header) is a way to
solve these issues.
What i mean is something like that (proof of concept patch):
diff --git a/kioslave/http/http.cpp b/kioslave/http/http.cpp
index e4f1eba..33fbda6 100644
--- a/kioslave/http/http.cpp
+++ b/kioslave/http/http.cpp
@@ -2925,6 +2925,7 @@ try_again:
char buffer[maxHeaderSize];
bool cont = false;
bool bCanResume = false;
+bool askRedirectionConfirm = false;
if (!isConnected()) {
kDebug(7113) No connection.;
@@ -3105,6 +3106,8 @@ try_again:
case 302: // Found
if (m_request.sentMethodString == POST) {
setMetaData(QLatin1String(redirect-to-get),
QLatin1String(true));
+} else if (m_request.sentMethodString == DELETE ||
m_request.sentMethodString == PUT) {
+ askRedirectionConfirm = true;
}
break;
case 303: // See Other
@@ -3112,8 +3115,16 @@ try_again:
setMetaData(QLatin1String(redirect-to-get),
QLatin1String(true));
}
break;
+ case 307:
+if (m_request.sentMethodString == POST ||
m_request.sentMethodString == DELETE || m_request.sentMethodString == PUT) {
+ askRedirectionConfirm = true;
+}
+break;
case 308: // Permanent Redirect
setMetaData(QLatin1String(permanent-redirect),
QLatin1String(true));
+if (m_request.sentMethodString == POST ||
m_request.sentMethodString == DELETE || m_request.sentMethodString == PUT) {
+ askRedirectionConfirm = true;
+}
break;
default:
break;
@@ -3484,8 +3495,18 @@ endParsing:
if (tIt.hasNext() m_request.responseCode 299
m_request.responseCode 400) {
locationStr = QString::fromUtf8(tIt.next().trimmed());
}
-// We need to do a redirect
-if (!locationStr.isEmpty())
+
+// Should we redirect?
+bool shouldRedirect = !locationStr.isEmpty();
+
+if (shouldRedirect askRedirectionConfirm) {
+const int userWish = messageBox(WarningYesNo, i18nc(@info redir,
redir), i18nc(@title:window, Confirm Redir));
+if (userWish == KMessageBox::No) {
+shouldRedirect = false;
+}
+}
+
+if (shouldRedirect)
{
KUrl u(m_request.url, locationStr);
if(!u.isValid())
- Andrea Iacovitti
On March 7, 2014, 6:07 a.m., Dawit Alemayehu wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116570/
---
(Updated March 7, 2014, 6:07 a.m.)
Review request for kdelibs, Andrea Iacovitti and David Faure.
Repository: kdelibs
Description
---
This patch is a companion to the recent POST-POST redirection implementation
in KIO, https://git.reviewboard.kde.org/r/116017/. It prompts the user to
approve the redirection as explicitly required in sections 10.3.[2|3] of RFC
2616:
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Please note that this patch only prompts the user for confirmation on
POST-POST redirections. It can be expanded to include redirections for other
requests such as PUT.
There is also an issue of whether this
Re: Review Request 109792: Update 'dim display' algorithm.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/109792/#review53070 --- What's the status here? Please mark as shipped, discarded or update otherwise. Thanks... - Sebastian Kügler On April 13, 2013, noon, Danny Baumann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/109792/ --- (Updated April 13, 2013, noon) Review request for kde-workspace, Solid, Dario Freddi, and Oliver Henshaw. Bugs: 304696 http://bugs.kde.org/show_bug.cgi?id=304696 Repository: kde-workspace Description --- This change does two things: - No longer dim display before the dim time set by the user elapses. This fixes bug #304696 - No longer assume that 0% display brightness produces a visible result. This doesn't work with the intel-backlight backlight interface (as it turns off the backlight at 0% brightness). According to the kernel developers (see [1] and [2]), this isn't a safe assumption to make for other backlight interfaces either. Instead of always dimming to 0%, make the amount of dimming configurable. [1] http://lists.freedesktop.org/archives/intel-gfx/2013-March/026152.html [2] http://lists.freedesktop.org/archives/intel-gfx/2013-March/026140.html Diffs - powerdevil/daemon/actions/bundled/dimdisplay.cpp 11554e3ba5d2f67d4d1de9d61c744c6c40a32d27 Diff: https://git.reviewboard.kde.org/r/109792/diff/ Testing --- Thanks, Danny Baumann
Re: What to test for 4.13?
Hi Marko, On Saturday, 2014-03-15, 16:04:24, mk-li...@email.de wrote: Hi Kevin, And I won’t consider MacPorts' installation from sources as a design flaw, it is partly just a development state on the way to become an open-source software distribution system (not only) for Apple’s MacOSX. If I am not mistaken you can run MacPorts also on Linux. :-) I didn't mean to imply or suggest that the design was flawed or anything like that. I was just wondering if the group was targetting a different audience. Ian wrote something about build dependencies and building which kind of didn't go well with my mental model of Mac users. I hardly know any Mac user who would build software so they would not be affected by build dependencies. Several postings later my understanding is that Macports do have binary packages as well, which would solve Ian's concerns and be more in line with what my Mac users would be looking for. Also one has to point out that MacPorts DELIBERATELY does not distribute port binaries which use code with a licence which isn’t allowing binary distribution. This is good and considerate design in my eyes. Right. Doesn't apply to KDE software but certainly the right thing to do in the wider scope. Maybe there are some non-KDE packages which require the libsdl library and they require the +x11 variant, so then everybody gets it. Just as KGoldrunner gets Nepomuk, et al. … ;-) That is a serious packaging problem then. Yes, it’s hugely difficult to get KDE applications to build without any X11 deps. Any idea why? Most applications should not have any X11 dependency, those available on Windows definitely don't. Or rather there seems to be a huge gap between the target audience of the mac packaing effort and the people wanting to use it. Has anyone pointed that out to them? Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as up-to-date as possible, so that no-one misses anything later. Back then - when there were no port binaries distributed - this would mean hours and hours and hours of building X11 and Qt and KDE… A pain to get started with any Qt[34] application, I tell you! usual OSX user and hours of building just don't match in my experience. hours of building and usual user doesn't match on any platform I know of. Hence my assumption that the target audience was not the audience that the packaging effort actually catered for. That assumption seemed to have been wrong with Macports actually having pre- built software and having building as a separate option. My updated understanding is now that it is very much like a Linux package repository, where users can just install and run the software without having to care about building and dependencies. Basically a FOSS app store. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Query: Possible code contribution
On Sunday, 2014-03-16, 00:16:45, Lydia Pintscher wrote: On Fri, Mar 14, 2014 at 2:40 PM, Ganesh Kumar gp29111...@gmail.com wrote: Hi. This is Ganesh P Kumar, doing my B.Tech in Computer Science and Engineering in IIT Madras. As part of our curriculum we must contribute code to an open source project. There is a deadline of 40 days for the project submission. Given this small deadline, I would like to ask for suggestions from the KDE Developer group about what would be a viable project during this time. We are ok with working either with the KDE UI as such, or with any KDE subproject. Also, I would like to add that none of us have any dev experience in KDE before. Would a project to fix several small little issues be viable? Then you could maybe work with the designers/usability team and help them out a bit. 40 days is really not much. One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. CCing the frameworks development list. Cheers, Kevin [1] https://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out [2] http://community.kde.org/Frameworks -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi Kevin, On 16 Mar 2014, at 11:07 , Kevin Krammer kram...@kde.org wrote: I didn't mean to imply or suggest that the design was flawed or anything like that. ok. Ian wrote something about build dependencies and building which kind of didn't go well with my mental model of Mac users. I see. I hardly know any Mac user who would build software so they would not be affected by build dependencies. Neither do I, personally I mean. But there are many on MacPorts! Also one has to point out that MacPorts DELIBERATELY does not distribute port binaries which use code with a licence which isn’t allowing binary distribution. This is good and considerate design in my eyes. Right. Doesn't apply to KDE software but certainly the right thing to do in the wider scope. Hmm, it does apply also to KDE software, since it may use a library which isn’t permitting binary-only distribution. Yes, it’s hugely difficult to get KDE applications to build without any X11 deps. Any idea why? Most applications should not have any X11 dependency, those available on Windows definitely don’t. Well, good question! Unfortunately I am not knowledgeable enough to answer this easily now. I am busy with all of this since about 3 years and I haven’t dived into the depths of X11 on MacOSX (XQuartz), Cocoa and the vast dependency tree of MacPorts’ ports. I just know that I did my best trying to remove all dependencies to X11 for KMyMoney back then, but had a really hard time, because some tools in these many dependencies might need some little GTK application or so… It’s a major undertaking to unwind all these dependencies and figure out where and why exactly a certain X11 lib is needed. But there is a dependency tree view possible for any application. By using that one can locate which lib needs what. An example of that can be seen in my post from March 12th @ 21:31. Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as up-to-date as possible, so that no-one misses anything later. Back then - when there were no port binaries distributed - this would mean hours and hours and hours of building X11 and Qt and KDE… A pain to get started with any Qt[34] application, I tell you! usual OSX user and hours of building just don't match in my experience. hours of building and usual user doesn't match on any platform I know of. You are absolutely right. MacPorts doesn’t target those who can only manage to go to the AppStore and click on icons. It’s merely for geeks, I guess. But it does a pretty good job already, once you’ve understood the needed workflows. Their website explains everything sufficiently to get started - if you’re not afraid of the command line. That assumption seemed to have been wrong with Macports actually having pre- built software and having building as a separate option. As I said, the pre-built ports came up only a year ago or so, but MacPorts is far older. I think it just shows the evolution of the project. It was time to switch from solely port building from scratch to binary distribution wherever possible. And they made it happen. :) My updated understanding is now that it is very much like a Linux package repository, where users can just install and run the software without having to care about building and dependencies. Correct, let me cite their website’s 1st sentence: cite The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the OS X operating system. /cite Basically a FOSS app store. Yep, driven by a perhaps a dozen very active MacPorts infrastructure developers and a few hundred port maintainers. Have a look at their port repository which contains about 18000 ports! You’d find almost everything you wish for if you have a Linux background. When I switched to MacOSX I missed so many tools (Qt, KDE, MySQL, mercurial, git, cctools, boost, autojump, doxygen, xsltproc, mc, recode), but MacPorts gave them back to me almost pain-free! Your system gets updated whenever a port maintainer decides to commit an updated portfile. So, one does not need to worry about how to deinstall old software versions from the depths of your iMac’s file system, but instead can sit back and rely on MacPorts’ logic to keep everything up-to-date, which generally works fine and with very little interactive user action. The plus is that you usually have stable and up-to-date software installed. For KMyMoney 4.6 - for instance - there are two ports kmymoney4 and kmymoney4-devel. The first is always the latest release version, whereas the devel port distributes a version which I try to keep as close as possible to its git's HEAD version, i.e. is always bleeding edge. The user decides what she/he wants. And thanks to the buildbots the MacPorts infrastructure can make sure that a a new version of any
Re: What to test for 4.13?
Hi Marko, On Sunday, 2014-03-16, 13:23:35, mk-li...@email.de wrote: Hi Kevin, On 16 Mar 2014, at 11:07 , Kevin Krammer kram...@kde.org wrote: Also one has to point out that MacPorts DELIBERATELY does not distribute port binaries which use code with a licence which isn’t allowing binary distribution. This is good and considerate design in my eyes. Right. Doesn't apply to KDE software but certainly the right thing to do in the wider scope. Hmm, it does apply also to KDE software, since it may use a library which isn’t permitting binary-only distribution. I find this hard to believe. That would mean this is a KDE application that is not available on Linux distributions. Yes, it’s hugely difficult to get KDE applications to build without any X11 deps. Any idea why? Most applications should not have any X11 dependency, those available on Windows definitely don’t. Well, good question! Unfortunately I am not knowledgeable enough to answer this easily now. I have no clue about that either but my naive approach would have been to check the build input files for Windows branches and check if the deviation is something compiler specific (or similar like paths), or non-X11 platform stuff. Also the recent porting efforts to Wayland should help there as well since it is another non-X11 platform. Your system gets updated whenever a port maintainer decides to commit an updated portfile. So, one does not need to worry about how to deinstall old software versions from the depths of your iMac’s file system, but instead can sit back and rely on MacPorts’ logic to keep everything up-to-date, which generally works fine and with very little interactive user action. The plus is that you usually have stable and up-to-date software installed. For KMyMoney 4.6 - for instance - there are two ports kmymoney4 and kmymoney4-devel. The first is always the latest release version, whereas the devel port distributes a version which I try to keep as close as possible to its git's HEAD version, i.e. is always bleeding edge. The user decides what she/he wants. Nice! And thanks to the buildbots the MacPorts infrastructure can make sure that a a new version of any committed portfile will always be build immediately and thus explicitly verify for all four supported versions of MacOSX that the port binaries can be build just fine. THAT is very close to CI, isn’t it?! Are the build results published somewhere? A website or mailinglist one can subscribe to? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
mk-li...@email.de wrote: $ sudo port install kdesdk4 --- Computing dependencies for kdesdk4 --- Dependencies to be installed: cervisia dolphin-plugins kde4-baseapps nepomuk-widgets kapptemplate kcachegrind4 kde-dev-scripts kde-dev-utils kdesdk-kioslaves kdesdk-strigi-analyzers kdesdk-thumbnailers kompare libkomparediff2 lokalize okteta poxml antlr umbrello --- where only cervisia and antlr needed to be built from sources (certainly due to some license issues). :-) It would be interesting to know what are those issues. All the dependencies for those packages are regularly packaged in many Linux distributions where the licenses have been properly checked. Ciao -- Luigi Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi Kevin, Hmm, it does apply also to KDE software, since it may use a library which isn’t permitting binary-only distribution. I find this hard to believe. That would mean this is a KDE application that is not available on Linux distributions. hmmm, well, I remember there was some discussions a while ago concerning those license issues… MacPort’s infrastructure checks whether the license settings defined permit the distribution. I’ll check these issue and post the information I can find here. (Just now also Luigi asked for it.) I have no clue about that either but my naive approach would have been to check the build input files for Windows branches and check if the deviation is something compiler specific (or similar like paths), or non-X11 platform stuff. Well, I guess it’s worth exploring those dependencies to check where code is pulled in which is not really needed for KDE with a qt4-mac-based Qt installation. And thanks to the buildbots the MacPorts infrastructure can make sure that a a new version of any committed portfile will always be build immediately and thus explicitly verify for all four supported versions of MacOSX that the port binaries can be build just fine. THAT is very close to CI, isn’t it?! Are the build results published somewhere? A website or mailinglist one can subscribe to? Yes, the buildbots (see e.g. [1]) keep all the logs, so that each port maintainer can figure out what went wrong on which buildbot. Let’s take [2] as an example where I had committed a new version of the port for AqBanking version 5. The waterfall graph [3] (scroll down to 14:46:03) shows that only one of the four buildbots (Snow Leopard) was a able to successfully build the port. Its orange compile stage even gives you a list of warnings and errors during the build. The other three failing buildbots turn out to have trouble due to SVN: --- svn: OPTIONS of 'https://svn.macports.org/repository/macports/contrib/mpab': Server certificate verification failed: issuer is not trusted (https://svn.macports.org) — which was due to maintenance work being carried out at the time of the commit. OK, that’s all regarding CI on MacPorts for now. Will try to find the information concerning the licenses now. Greets, Marko [1] https://build.macports.org/buildslaves [2] https://build.macports.org/changes/34958 [3] https://build.macports.org/waterfall?last_time=1394457731 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Submit your proposals for GSoC 2014!
Hey everyone :) If you plan to work with KDE for GSoC 2014 please submit your proposal on google-melange.com now. Do not wait until the deadline. It is better to have the proposal in the system early so that more mentors can start giving you feedback. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors / KDE Community Working Group http://kde.org - http://open-advice.org Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi Luigi, On 16 Mar 2014, at 14:14 , Luigi Toscano luigi.tosc...@tiscali.it wrote: It would be interesting to know what are those issues. All the dependencies for those packages are regularly packaged in many Linux distributions where the licenses have been properly checked. OK, with this — $ bash mp-distributable.sh cervisia cervisia is not distributable because its license lglp is not known to be distributable $ bash mp-distributable.sh antlr antlr is distributable — it turns out that: 1) cervisia’s portfile just doesn’t use a proper identifier for the license, which needs to be fixed. 2) probably there wasn’t any binary port yet on the buildbot server for some reason, since it is marked as distributable. So there wasn’t actually a license conflict. (Mind that I was just speculating about it in my previous post.) Greets, Marko Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: kpeople
Man, I don't know why, but you ended up in my spam (gmail filters) 2014-03-14 12:59 GMT+01:00 Rupanjana Mitra mrupanj...@gmail.com: I am trying to do a project on people where I have to build an interface for collecting address information of people and connect it with databases .i am understanding it.How should I go about it? Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe -- Matteo Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On 16 Mar 2014, at 20:34 , Kevin Krammer kram...@kde.org wrote: A dependency in two versions of GTK? For a non-GUI program? I even had a case with a port (don’t remember which one though) where actually LaTeX was required just because there was some documentation stuff to be converted from tex to pdf… Imagine to have to build LaTeX just for generating a piece of documentation. LaTeX’s tools then also pull in X11 due to ImageMagick and poplar! (It never ends.) Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On Sunday, 2014-03-16, 20:45:49, mk-li...@email.de wrote: On 16 Mar 2014, at 20:34 , Kevin Krammer kram...@kde.org wrote: A dependency in two versions of GTK? For a non-GUI program? I even had a case with a port (don’t remember which one though) where actually LaTeX was required just because there was some documentation stuff to be converted from tex to pdf… Imagine to have to build LaTeX just for generating a piece of documentation. LaTeX’s tools then also pull in X11 due to ImageMagick and poplar! (It never ends.) Yes, but those are build dependencies, right? The binary packages are not affected by this, are they? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
KDevelop on Apple OS X
Hi devs, after having installed kdesdk4 successfully MacPorts needed only about 30s to install the residual handful of ports required by KDevelop. Now there is KDevelop 1.6.0 up and running. :) Well, before going further with questions I wonder whether I should address them to KDevelop’s mailing list (which seems to be quite dead) or rather stay here on KDE-DEVEL for the moment, since I am not sure whether it is a Mac specific issue or not. What I did was that I set up a project via “Project/New From Template…/Project Type/Graphical”. After running into a little issue with the temlate [1] I was able build the generated code with some warnings, but without a real error. :-) When I now start the application from the built app package I unfortunately get an error: — $ ./testgraphical file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/: File not found Killed: 9 — I am surprised to see a message like this on the console. What does this mean? Which file does the app try to load and why does it fail to do so? KDevelop doesn’t allow me to step through the code in debug mode, so that I cannot say where exactly the issue occurred. I could imagine that the app tries to access its configuration which is stored on MacOSX in ~/Library/Preferences/KDE : — $ pwd /Users/marko/Library/Preferences/KDE/share/apps $ ls -1 RecentDocuments desktoptheme dolphin Kate kdenlive kdevappwizard kdevelop kfileplaces khelpcenter kssl plasma remoteview — As one can see, kdevelop itself already stores its stuff in there. I am clueless right now about how to further proceed. Hope you can push me into the right direction. Greets, Marko [1] https://bugs.kde.org/show_bug.cgi?id=329392 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KDevelop on Apple OS X
On Sun, Mar 16, 2014 at 10:02 PM, mk-li...@email.de wrote: Hi devs, after having installed kdesdk4 successfully MacPorts needed only about 30s to install the residual handful of ports required by KDevelop. Now there is KDevelop 1.6.0 up and running. :) Well, before going further with questions I wonder whether I should address them to KDevelop’s mailing list (which seems to be quite dead) or rather stay here on KDE-DEVEL for the moment, since I am not sure whether it is a Mac specific issue or not. What I did was that I set up a project via “Project/New From Template…/Project Type/Graphical”. After running into a little issue with the temlate [1] I was able build the generated code with some warnings, but without a real error. :-) When I now start the application from the built app package I unfortunately get an error: — $ ./testgraphical file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/: File not found Killed: 9 — I am surprised to see a message like this on the console. What does this mean? Which file does the app try to load and why does it fail to do so? KDevelop doesn’t allow me to step through the code in debug mode, so that I cannot say where exactly the issue occurred. I could imagine that the app tries to access its configuration which is stored on MacOSX in ~/Library/Preferences/KDE : — $ pwd /Users/marko/Library/Preferences/KDE/share/apps $ ls -1 RecentDocuments desktoptheme dolphin Kate kdenlive kdevappwizard kdevelop kfileplaces khelpcenter kssl plasma remoteview — As one can see, kdevelop itself already stores its stuff in there. I am clueless right now about how to further proceed. Hope you can push me into the right direction. Greets, Marko [1] https://bugs.kde.org/show_bug.cgi?id=329392 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Hi Marko, First of all, KDevelop mailing lists are not dead, we did change our mailing list to kde.org infrastructure, you might have looked at the wrong place [1]. We have some people already using KDevelop through homebrew on Mac OS X [2], maybe using the same tools Alexander used will help, at least with the first bug. Regarding the second one, it clearly seems like it's a bug in the cmake integration. It hasn't been tested on Mac before so it can be just as well that you're the first person trying that. Some further investigation will be very much welcome. I would suggest following up in the kdevelop-devel mailing list would be the best. Cheers! Aleix [1] http://kdevelop.org/mailinglists [2] https://github.com/adymo/homebrew-kde Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [Kde-hardware-devel] [GSoC] Project: Make Libbluedevil Async
Those are some sexy apis! Please submit the proposal to Melange, it looks good to me. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] [GSoC] Project: Make Libbluedevil Async
Thanks! Here is a public url for the proposal: https://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/nowrep/5662278724616192 David 2014-03-16 15:44 GMT+01:00 Àlex Fiestas afies...@kde.org: Those are some sexy apis! Please submit the proposal to Melange, it looks good to me. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
