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/#review52955 --- Looks OK overall. I'll admit to getting coincidentally tired right as I got to kuser_win.cpp, so I hope that all works (it's been a very long time since I coded for Windows, although I'm surprised how familiar it looks). There are some minor issues that would need to be fixed before the KDE and UNIX parts can go in. Especially on the documentation side, our docs are bad enough as it is without adding more undocumented exported library classes. :) Hopefully someone else can look as well though. I'm only reviewing this because I promised ervin I'd maintain kcoreaddons. :P autotests/kusertest.cpp https://git.reviewboard.kde.org/r/116798/#comment37263 The year seems a bit off here (and in other files). src/lib/util/kuser.h https://git.reviewboard.kde.org/r/116798/#comment37264 Same issue with the year (copy 'n' paste is the best, no?) ;) src/lib/util/kuser.h https://git.reviewboard.kde.org/r/116798/#comment37265 I think you can also add @internal or a similar Doxygen tag to note the same effect. src/lib/util/kuser.h https://git.reviewboard.kde.org/r/116798/#comment37266 The TODO is appropriate, but this would actually need to be documented before it goes in. ;) src/lib/util/kuser.h https://git.reviewboard.kde.org/r/116798/#comment37267 Ditto. src/lib/util/kuser.h https://git.reviewboard.kde.org/r/116798/#comment37268 Should this be deprecated in favor of the new userId()? Or are they both appropriate for applications to use? src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116798/#comment37269 I know this one isn't your fault, but there should probably be a call to setpwent() here to reset the /etc/passwd file pointer if some other code had called getpwent() earlier. src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116798/#comment37270 I think you can just do return d-users.mid(0, (int)maxCount) here. (You'd want to check that (int)maxCount isn't negative first, of course). Although ::mid() uses int instead of uint for the length, it's also true that QList itself doesn't seem to hold more than int elements if you look at the return type of QListT::size(). src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116798/#comment37271 Again, might want to put a setgrent() here. src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116798/#comment37272 And a setgrent() here. - Michael Pyne On March 14, 2014, 2:30 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/ --- (Updated March 14, 2014, 2:30 p.m.) Review request for KDE Frameworks and kdewin. 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 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review52957 --- looks good to me, just a few minor nitpicks. Most is: prefer using XCB_WINDOW_NONE instead of XCB_NONE if it's a window type. Similar there is XCB_ATOM_NONE, etc. etc. Would you mind adding a unit test for it? Would be nice to have this covered and I wouldn't be surprised if that will become an issue for other platforms, too. Thus a unit test will catch it before the implementation is finished. src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37276 nitpick: Q_NULLPTR src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37275 nitpick: XCB_WINDOW_NONE src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37273 nitpick: XCB_WINDOW_NONE src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/116787/#comment37274 nitpick: XCB_WINDOW_NONE - Martin Gräßlin On March 14, 2014, 11:36 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 14, 2014, 11:36 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - src/kwindowsystem.cpp 4c17baa src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Unknown media types
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? Best regards, Michael ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Default emoticons theme
Currently, kde-runtime installs an emoticons theme called kf5, and the kemoticons framework looks for a theme called kde4 by default. I suggest that either: - the kde-runtime theme moves to the Oxygen repo, gets renamed to oxygen, and kemoticons selects this by default, or - it moves to kemoticons (where it will be guaranteed to be installed), retains its current name, and kemoticons selects kf5 by default. Or it could be kemoticons-default or something (as a side-note, there doesn't appear to be a way of specifying a friendly name for the theme - the name is just the name of the directory). Thoughts? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Default emoticons theme
Hello, On Saturday 15 March 2014 11:30:22 Alex Merry wrote: - it moves to kemoticons (where it will be guaranteed to be installed), retains its current name, and kemoticons selects kf5 by default. It has my preference, so that you don't need an obscure (from 3rd party devs POV) dependency to have a usable framework by default. Or it could be kemoticons-default or something (as a side-note, there doesn't appear to be a way of specifying a friendly name for the theme - the name is just the name of the directory). Right, renaming it to something more friendly probably makes sense too. 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
Frameworks book
Hello frameworks developers, It has been discussed on the KDE-Community list that some of you would like a Frameworks book. While I've co-authored a book for KDE, the Developer Guide for our GSoC students, I'm no coder. So I need co-authors. Mario has asked me to head up the book sprint at Randa this August, and if enough of you are interested, we can write the book that week, Saturday, 9th to Friday, 15th of August 2014. We'll need a minimum of three writers, and more would be good. Don't worry about your skill in writing; what we need are energy, knowledge of the subject, and the ability to focus. My role will be to keep us on track, and to polish the writing. And of course we can copy from the wikis, emails and blog posts -- there is no need to have every word written in Randa. The most important part of this effort is narrowing the focus of the book by deciding for whom we are writing. I'm guessing other developers, but the more precise we are, the better the book will be. A great book will be wonderful advertising for the amazing effort you devels have put in transforming KDE-libs into KDE Frameworks. If you have time to come to Randa this August, please respond here on the list, and register for the sprint. For more information, see: http://randa-meetings.ch/2014/02/19/randa-meetings-2014-the-date-is-set-please-register/ https://sprints.kde.org/sprint/212 Valorie -- http://about.me/valoriez ___ 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 Divendres, 14 de març de 2014, a les 22:34:27, Chusslove Illich va escriure: [: John Layt :] Or do we list all languages regardless of whether they are installed or not (probably way too many)? 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. 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. Cheers, Albert ___ 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 15, 2014, 4:25 p.m.) Review request for KDE Frameworks. Changes --- - Fixed issues - Improved documentation - added qHash for KUserId/KGroupId - Deprecated KUser::uid()/gid() and KUserGroup::gid() 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 (updated) - 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 115916: Fix MSVC build of kprintpreview_test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115916/ --- (Updated March 15, 2014, 4:31 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kprintutils Description --- Fix MSVC build of kprintpreview_test I am not sure whether this is the best solution, but I don't want to make the Linux code less efficient. However it is a test application so it probably doesn't matter... Diffs - tests/kprintpreview_test.cpp 79cac037ab38bce89b97e4ede58eb58d821b25f3 Diff: https://git.reviewboard.kde.org/r/115916/diff/ Testing --- 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 116087: remove usage of strlcpy
--- 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 (updated) - 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 116090: Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116090/ --- (Updated March 15, 2014, 4:31 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kde4support Description --- Use $TARGET_FILE:... instead of get_target_property(... LOCATION) This means CMake no longer warns about Policy CMP0026 is not set when building projects that need kde4support Diffs - cmake/modules/ECMQt4To5Porting.cmake 4204fa541790aa38c74b9d6f0b2111af2157b2bc cmake/modules/KDE4Macros.cmake 192094b1c5c6877cd9dfa18dc27338c491d753f3 src/CMakeLists.txt 6bda0996c118ce212860e02d0505fd3bdc026833 src/KDEUIMacros.cmake 1570df340a672a597a0b7480885c340faca0069d Diff: https://git.reviewboard.kde.org/r/116090/diff/ Testing --- kde4support compiles, kde-workspace 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 115918: Fix kservice_desktop_to_json for Visual Studio
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/ --- (Updated March 15, 2014, 4:37 p.m.) Review request for KDE Frameworks and Stephen Kelly. Repository: kservice Description --- Fix kservice_desktop_to_json for Visual Studio The CMake generator for Visual Studio cannot handle the new build-time kservice_desktop_to_json macro - fall back to configure-time generation Diffs (updated) - KF5ServiceMacros.cmake 55fba4288dd16a97bf388f77c5c923c6136fab81 Diff: https://git.reviewboard.kde.org/r/115918/diff/ Testing --- ktexteditor fails to build before this patch (because moc can't find the .json file), with the patch it compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC on framework localization
El Divendres, 14 de març de 2014, a les 03:48:49, Aurélien Gâteau va escriure: Hi, I started working on ensuring frameworks can be correctly localized and have some questions. # Messages.sh place I noticed some frameworks already have Messages.sh files in there. Most of them are in src/. Some are in subdirs of src/ (kio, plasma-framework, solid, kwallet, kactivities, kde4support). Are we OK with src/ being the default place, but then its up to the framework maintainer to adjust based on the framework needs? I already updated the framework template in kde:kdeexamples to put a Messages.sh in src/. # No translations Some frameworks have no translatable strings. I think in this case there should not be any Messages.sh file. Is it OK for everybody? Do we want to to guarantee they will keep having no translatable strings in future releases? How do we do it? Or just add a Messages.sh if they have translatable strings in the future? Cheers, Albert ___ 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 15, 2014, 4:52 p.m.) Review request for KDE Frameworks. Changes --- fix year 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 (updated) - 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
Releasing Deprecated modules and Tier 4 Definition
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. 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). 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. 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. 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. That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. Feedback and opinions are of course welcome. 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
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 15, 2014, 5: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 (updated) - 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: Default emoticons theme
On Sat, Mar 15, 2014 at 3:14 PM, Kevin Ottens er...@kde.org wrote: Hello, On Saturday 15 March 2014 11:30:22 Alex Merry wrote: - it moves to kemoticons (where it will be guaranteed to be installed), retains its current name, and kemoticons selects kf5 by default. It has my preference, so that you don't need an obscure (from 3rd party devs POV) dependency to have a usable framework by default. Or it could be kemoticons-default or something (as a side-note, there doesn't appear to be a way of specifying a friendly name for the theme - the name is just the name of the directory). Right, renaming it to something more friendly probably makes sense too. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, I do agree that having an emoticons set together with kemoticons can be very helpful and simplify the usage of the module. Also, it doesn't really make sense to use kf5 or kde4. It's not something linked to the library version, so it can be a theme name. Either way, I would appreciate if you could document whatever you decide in the wiki [1]. Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ 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 Sat, Mar 15, 2014 at 4:59 PM, Kevin Ottens er...@kde.org 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. 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). 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. 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. 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. That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. Feedback and opinions are of course welcome. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, First of all, I agree that the definition of Tier 4 is gray at the moment, escentially it's mostly things we don't want people to depend on. 1) Tier Deprecated would probably contain KRunner too, especially if sprinters ends up joining the frameworks party, which I'm unsure. Personally I think 1 and 2 would work just fine. It's mostly making sure that people doing the promotion will promote what we actually want people to rely on. Option 4 would work too, but we probably want to decide that once we have more applications ported and see what's the status. Aleix ___ 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/#review53017 --- Ship it! Looks good, seems to build, install, and work here, and all tests pass. - Michael Pyne 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
