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
Review Request 116808: RFC for fixing bug 332132
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116808/ --- Review request for kdelibs. Repository: kdelibs Description --- This patch aims to fix the bug 332132 (in the kde bug tracker). It delay the deletion of animation states thanks to QSharedPointer. Diffs - kio/kio/delegateanimationhandler.cpp 9055a98 kio/kio/delegateanimationhandler_p.h bd26006 kio/kio/kfileitemdelegate.cpp 50cc3b6 Diff: https://git.reviewboard.kde.org/r/116808/diff/ Testing --- Thanks, Paul Chavent
Re: Review Request 116097: No longer use strlcpy in kstartupconfig
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/#review52983 --- This review has been submitted with commit 9be2f82e549a6644967438b047270c62edd428d7 by Alex Richardson to branch master. - Commit Hook On Feb. 26, 2014, 6:11 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/ --- (Updated Feb. 26, 2014, 6:11 p.m.) Review request for kde-workspace. Repository: kde-workspace Description --- No longer use strlcpy in kstartupconfig This means we no longer need to find libbsd on Linux. kstartupconfig is now uses std::string instead of pure C strings, but the performance difference should be minimal (and it is less error-prone). Diffs - CMakeLists.txt bce3cd1de65b8420a859c342db981919965071ba cmake/modules/FindLibBSD.cmake 6383083023cdbfbeffcab0cef98f48102e593d38 kstartupconfig/CMakeLists.txt ceebd6a65af4cdaa717cfb0dcff5097121cf48d9 kstartupconfig/kstartupconfig.c d8e65f48a75dad49fe6c585f89260c2a6d483809 Diff: https://git.reviewboard.kde.org/r/116097/diff/ Testing --- compiles Thanks, Alexander Richardson
Re: Review Request 116097: No longer use strlcpy in kstartupconfig
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/ --- (Updated March 15, 2014, 3:40 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace. Repository: kde-workspace Description --- No longer use strlcpy in kstartupconfig This means we no longer need to find libbsd on Linux. kstartupconfig is now uses std::string instead of pure C strings, but the performance difference should be minimal (and it is less error-prone). Diffs - CMakeLists.txt bce3cd1de65b8420a859c342db981919965071ba cmake/modules/FindLibBSD.cmake 6383083023cdbfbeffcab0cef98f48102e593d38 kstartupconfig/CMakeLists.txt ceebd6a65af4cdaa717cfb0dcff5097121cf48d9 kstartupconfig/kstartupconfig.c d8e65f48a75dad49fe6c585f89260c2a6d483809 Diff: https://git.reviewboard.kde.org/r/116097/diff/ Testing --- compiles Thanks, Alexander Richardson
kdesrc-build complains about a dependency cycle in kdelibs..
Hi, If i use the default config[1] i get this[2] error. This is in an attempt to build parts of KDE 4.13 git. My kdesrc-build is at git branch 598ad6225ddf1fa1d9701eaa0eb350b57eb337fc (fresh clone). Any idea what might be causing this? Cheers, Mark [1] http://quickgit.kde.org/?p=kdesrc-build.gita=blobh=8682bf03e34341513aea029691f198c6469ce20ahb=598ad6225ddf1fa1d9701eaa0eb350b57eb337fcf=kdesrc-buildrc-sample [2] http://pastebin.com/raw.php?i=xyubWkQ1
Re: kdesrc-build complains about a dependency cycle in kdelibs..
On Sun, Mar 16, 2014 at 6:18 AM, Mark Gaiser mark...@gmail.com wrote: Hi, Hi Mark, If i use the default config[1] i get this[2] error. This is in an attempt to build parts of KDE 4.13 git. My kdesrc-build is at git branch 598ad6225ddf1fa1d9701eaa0eb350b57eb337fc (fresh clone). Any idea what might be causing this? It looks like you might be trying to build both Frameworks and KDE 4 together in the same build setup. While i'm not familiar with how kdesrc-build handles this, at least for the CI scripts, this is not a supported configuration. Can you try setting up separate builds? Cheers, Mark Thanks, Ben [1] http://quickgit.kde.org/?p=kdesrc-build.gita=blobh=8682bf03e34341513aea029691f198c6469ce20ahb=598ad6225ddf1fa1d9701eaa0eb350b57eb337fcf=kdesrc-buildrc-sample [2] http://pastebin.com/raw.php?i=xyubWkQ1
Re: kdesrc-build complains about a dependency cycle in kdelibs..
On Sat, Mar 15, 2014 at 9:04 PM, Ben Cooksley bcooks...@kde.org wrote: On Sun, Mar 16, 2014 at 6:18 AM, Mark Gaiser mark...@gmail.com wrote: Hi, Hi Mark, If i use the default config[1] i get this[2] error. This is in an attempt to build parts of KDE 4.13 git. My kdesrc-build is at git branch 598ad6225ddf1fa1d9701eaa0eb350b57eb337fc (fresh clone). Any idea what might be causing this? It looks like you might be trying to build both Frameworks and KDE 4 together in the same build setup. While i'm not familiar with how kdesrc-build handles this, at least for the CI scripts, this is not a supported configuration. Can you try setting up separate builds? Hi Ben, At first i was indeed trying to build both under the same user (but different prefixes and configs). I was expecting that to be likely an issue so i moved to a different user (nothing of frameworks is there) and still the same error.. The mentioned error is from a clean build, clean user and no frameworks and just the default. Cheers, Mark Cheers, Mark Thanks, Ben [1] http://quickgit.kde.org/?p=kdesrc-build.gita=blobh=8682bf03e34341513aea029691f198c6469ce20ahb=598ad6225ddf1fa1d9701eaa0eb350b57eb337fcf=kdesrc-buildrc-sample [2] http://pastebin.com/raw.php?i=xyubWkQ1
Re: kdesrc-build complains about a dependency cycle in kdelibs..
On Sat, March 15, 2014 21:47:39 Mark Gaiser wrote: Can you try setting up separate builds? Hi Ben, At first i was indeed trying to build both under the same user (but different prefixes and configs). I was expecting that to be likely an issue so i moved to a different user (nothing of frameworks is there) and still the same error.. The mentioned error is from a clean build, clean user and no frameworks and just the default. I can reproduce. Without better debugging on my part to print out what the cycle actually *is* it's hard to be sure. But uncommenting the branch-group latest-qt4 in the sample-rc file does work to break the cycle(s) so I've gone that route for now. Regards, - Michael Pyne
Re: kdesrc-build complains about a dependency cycle in kdelibs..
On Sat, Mar 15, 2014 at 10:50 PM, Michael Pyne mp...@kde.org wrote: On Sat, March 15, 2014 21:47:39 Mark Gaiser wrote: Can you try setting up separate builds? Hi Ben, At first i was indeed trying to build both under the same user (but different prefixes and configs). I was expecting that to be likely an issue so i moved to a different user (nothing of frameworks is there) and still the same error.. The mentioned error is from a clean build, clean user and no frameworks and just the default. I can reproduce. Without better debugging on my part to print out what the cycle actually *is* it's hard to be sure. But uncommenting the branch-group latest-qt4 in the sample-rc file does work to break the cycle(s) so I've gone that route for now. Regards, - Michael Pyne Nice and simple fix :)
MacPorts: Running KDE ports on Apple OS X
Hi MacPorts guys, especially KDE port developers, Over at the main KDE developers' mailing list, kde-devel@kde.org I have been inadvertently stirring things up re the status of KDE ports on Apple OS X. It started with one of the KDE Promotion guys asking us to suggest things that need volunteers to test them during the Beta phase of KDE 4.13, which is current. He has written a news article about it. Of course I suggested the Palapeli jigsaw puzzle app on which I have been doing a lot of work lately. But then I wrote another mail asking how much testing is done of KDE's cross-platform and cross-desktop implementations and commenting on some of the problems we experience with KDE over here at MacPorts. I suggested that maybe it was time some KDE guys had a get-together with some MacPorts and KDE Windows guys and got to the bottom of such problems. And I said it would be nice to have some regular testing of Apple and Windows implementations of KDE. Well … the response was quite antagonistic at first, but I am old and thick-skinned and I stood my ground … :-) So now some of the KDE guys are coming round to my way of thinking, particularly some KDE sysadmin guys and a guy who is organising a workshop (a KDE sprint) at Randa, in August, a nice little village in Switzerland just down the valley from Zermatt and the Matterhorn. See http://randa-meetings.ch/ He wants to schedule a group at Randa on KDE cross-platform implementation. And he is looking for MacPorts and Homebrew representatives to attend. So now I am looking for some support over here. Marko Kaening (KMyMoney4 guy) is already over at kde-devel@kde.org banging the drum on our behalf. First I would like you to have look at the two threads on kde-devel@kde.org 1. What to test for 4.13? starts here … it is the more controversial of the two. http://lists.kde.org/?l=kde-core-develm=139418788102916w=2 2. Running KDE apps on Apple OS X starts here .. http://lists.kde.org/?l=kde-develm=139450777202393w=2 If there is anything I have said wrong please let me know on this MacPorts list. If you agree or disagree with what I am trying to achieve, please also let me know. Please do not get upset by anything that was written. Every group tends to think that the people on the other side of the river have two heads, but I have found in the course of a long career, that building bridges is a good way to solve problems. I also discovered, in the course of all this, that there are two well-known former KDE developers working over at Homebrew. I do not know if there are any at MacPorts, but if there are, please stand up. All the best, Ian W. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
kpeople
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
Query: Possible code contribution
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. Thanks in advance, Regards, Ganesh P Kumar 3rd year Undergraduate Dept. of CSE, IIT-M Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [Kde-pim] Review Request 116692: Lower memory usage of akonadi_baloo_indexer with frequent commits
On Monday 10 March 2014 10:08:29 Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116692/ --- Review request for Akonadi and Baloo. Repository: baloo Description --- Baloo is using Xapian for storing processed results from data fed to it by akonadi; in doing so it processes all the data it is sent to index and only once this is complete is the data committed to the Xapian database. From http://xapian.org/docs/apidoc/html/classXapian_1_1WritableDatabase.html#acb ea2163142de795024880a7123bc693 we see: For efficiency reasons, when performing multiple updates to a database it is best (indeed, almost essential) to make as many modifications as memory will permit in a single pass through the database. To ensure this, Xapian batches up modifications. This means that *all* the data to be stored in the Xapian database first ends up in RAM. When indexing large mailboxes (or any other large chunk of data) this results in a very large amount of memory allocation. On one test of 100k mails in a maildir folder this resulted in 1.5GB of RAM used. In normal daily usage with maildir I find that it easily balloons to several hundred megabytes within days. This makes the Baloo indexer unusable on systems with smaller amounts of memory (e.g. mobile devices, which typically have only 512MB-2GB of RAM) Making this even worse is that the indexer is both long-lived *and* the default glibc allocator is unable to return the used memory back to the OS (probably due to memory fragmentation, though I have not confirmed this). Use of other allocators shows the temporary ballooning of memory during processing, but once that is done the memory is released and returned back to the OS. As such, this is not a memory leak .. but it behaves like one on systems with the default glibc allocator with akonai_baloo_indexer taking increasingly large amounts of memory on the system that never get returned to the OS. (This is actually how I noticed the problem in the first place.) The approach used to address this problem is to periodically commit data to the Xapian database. This happens uniformly and transparently to the AbstractIndexer subclasses. The exact behavior is controlled by the s_maxUncommittedItems constant which is set arbitrarily to 100: after an indexer hits 100 uncommitted changes, the results are committed immediately. Caveats: * This is not a guaranteed fix for the memory fragmentation issue experienced with glibc: it is still possible for the memory to grow slowly over time as each smaller commit leaves some % of un-releasable memory due to fragmentation. It has helped with day to day usage here, but in the 100k mails in a maildir structure test memory did still balloon upwards. * It make indexing non-atomic from akonadi's perspective: data fed to akonadi_baloo_indexer to be indexed may show up in chunks and even, in the case of a crash of the indexer, be only partially added to the database. Alternative approaches (not necessarily mutually exclusive to this patch or each other): * send smaller data sets from akonadi to akonadi_baloo_indexer for processing. This would allow akonadi_baloo_indexer to retain the atomic commit approach while avoiding the worst of the Xapian memory usage; it would not address the issue of memory fragmentation * restart akonadi_baloo_indexer process from time to time; this would resolve the fragmentation-over-time issue but not the massive memory usage due to atomically indexing large datasets * improve Xapian's chert backend (to become default in 1.4) to not fragment memory so much; this would not address the issue of massive memory usage due to atomically indexing large datasets * use an allocator other than glibc's; this would not address the issue of massive memory usage due to atomically indexing large datasets Diffs - src/pim/agent/abstractindexer.h 8ae6f5c src/pim/agent/abstractindexer.cpp fa9e96f src/pim/agent/akonotesindexer.h 83f36b7 src/pim/agent/akonotesindexer.cpp ac3e66c src/pim/agent/contactindexer.h 49dfdeb src/pim/agent/contactindexer.cpp a5a6865 src/pim/agent/emailindexer.h 9a5e5cf src/pim/agent/emailindexer.cpp 05f80cf Diff: https://git.reviewboard.kde.org/r/116692/diff/ Testing --- I have been running with the patch for a couple of days and one other person on irc has tested an earlier (but functionally equivalent) version. Rather than reaching the common 250MB+ during regular usage it now idles at ~20MB (up from ~7MB when first started; so some fragmentation remains as noted in the description, but with far better long-term results) Just curious - did this get into Beta2? I just had to restart Akonadi with a akonadi-baloo-feeder process of 2.2 gb... (I just
Re: MacPorts: Running KDE ports on Apple OS X
Hi Ian, 2014-03-15 7:10 GMT+01:00 Ian Wadham: [...] And I said it would be nice to have some regular testing of Apple and Windows implementations of KDE. Well ... the response was quite antagonistic at first, but I am old and thick-skinned and I stood my ground ... :-) [...] First I would like you to have look at the two threads on kde-devel@kde.org 1. What to test for 4.13? starts here ... it is the more controversial of the two. http://lists.kde.org/?l=kde-core-develm=139418788102916w=2 2. Running KDE apps on Apple OS X starts here .. http://lists.kde.org/?l=kde-develm=139450777202393w=2 If there is anything I have said wrong please let me know on this MacPorts list. If you agree or disagree with what I am trying to achieve, please also let me know. Please do not get upset by anything that was written. Every group tends to think that the people on the other side of the river have two heads, but I have found in the course of a long career, that building bridges is a good way to solve problems. I greatly appreciate that the Improve KDE on Mac initiative is getting going! I'm sorry for sending one last mail about this issue. One might argue that it will not help much, but seeing that I am now blamed in public for being antagonistic, and that people have to be warned to not get upset by my earlier responses, I just have to. So, to explain why I wrote my antagonistic responses to the What to test for 4.13 thread: 1. In your second mail to the thread, you said that Dolphin does discredit to KDE because it crashes before showing any window. To be honest, I consider making such statements in public without telling what the crashing version is extremely inappropriate, in particular considering that you admitted later that the problematic version is 1 year old, and you never bothered to report the problem at bugs.kde.org. 2. Also in your second mail to the thread, but also later mails, you say that too little testing is being done on Mac (which is probably true). However, instead of questioning if the people who try to use KDE on Mac actually report their problems upstream and try to help fix them, you blame the KDE developers (a group which I consider myself part of) for not doing enough testing on Mac, and even suggest that the KDE developers who work exclusively on Linux get Mac hardware. The number of people of people who work to make KDE better is far too small, so the result of that work is not always as good as we would like it to be. Just to be clear: I fully understand that users are dissatisfied if a developer introduces bugs all the time and doesn't care about them, or if a bug report with many duplicates is ignored for a long time. However, in most other situations, pointing fingers at the few people who do the work and saying you are not doing enough is not exactly helpful. In fact, seeing this attitude over and over again in mailing lists, forums, etc., is slowly ruining my motivation to do any work on KDE at all. This is the reason why I sometimes get a bit upset when I see someone say The KDE developers have to/are not doing enough/ I apologize to anyone who felt bothered by my mails the the What to test for 4.13 thread. I hope I made it clear why I felt bothered by Ian's mails. I will try to ignore any future messages about Dolphin and my work if I consider them inappropriate. Best regards, Frank Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Running KDE apps on Apple OS X
On Fri, Mar 14, 2014 at 8:56 PM, Ian Wadham iandw...@gmail.com wrote: Hi Ben, Hi Ian, On 13/03/2014, at 7:15 AM, Ben Cooksley wrote: On Thu, Mar 13, 2014 at 7:44 AM, John Layt jl...@kde.org wrote: What to do at the KDE end? We have a wiki at http://community.kde.org/Mac that we need to keep updated as things change, as that is where mac.kde.org redirects. We also have the forum at http://forum.kde.org/viewforum.php?f=60, but for devs please use the list at https://mail.kde.org/mailman/listinfo/kde-mac. I can't emphasise enough: if everyone who's doing stuff with KDE-on-Mac were to talk to each other there, there would be a lot less work needed! Qt5/KF5 may improve things, but we still need to build infrastructure to support Mac. We need CI Mac builds to test KF5 stuff and prevent Linuxisms and build breakers from creeping in over time, e.g. to ensure the creation of Mac Frameworks (a special type of library) works as you need to follow strict include rules that Linux or Windows don't need. It's part of our KF5 everywhere Qt is strategy. Advanced Mac platform integration will also need CI builds to check they don't get broken by Linux-focussed devs :-) In terms of the bare minimum requirements of the CI system itself (not taking into account anything being built) the following is needed. I'm assuming it is all available? - Java (either Oracle or IcedTea) - Python (with lxml support) - RSync - SSH - Git - Subversion - Bazaar I think all of those are available. Attached is a summary of search results for bazaar and lxml, on the latest Macports index. More detail on any of those packages can be provided by port info if you need it. I have certainly used git and Subversion on Mac OS X to maintain and check in my code. I am also using Java and mysql to run a business administration app that was developed by a friend of mine on Windows. Okay, excellent. Please note that if we do purchase such systems then we need to find a place to host them - and someone to look after them should they need to be moved or require hardware maintenance (disk failures, etc). Ideally we would hire them from a DC which offers that. I do not think they would need much hosting. Each Mac Mini is only about the size of 3 or 4 CD cases. The network connections would be another matter. Apple support at the Apple Store for Macs, MacBooks, iPads and iPhones is excellent, and free. I am amazed how much time they are prepared to spend with my wife and me without any complaining ... For a Mac Mini you might need to hook into the Genius Bar guys though ... :-) We'll await the results of the Macports collaboration thread before continuing further. Ideally though the datacenter operator would look after the hardware aspect - this has worked very well for us with Hetzner and our Linux systems. You might also like to look at the new Mac Pro, which is more expensive but extremely powerful (Intel Xeon). It is cylindrical with a hole in the top. You'd just have to be careful nobody pours their coffee into it ... :-) Cheers, Ian W. Regards, Ben Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
Not exactly a KDE developer, but having spent quite some time getting KDE on my MBP, including the Calligra suite, I cannot but agree with Ian. The KDE apps that work do so looking great on OS X, it be nice to improve matters. Things that occur to me include menubar integration, the correct preferences/settings dialog in the App menu, sending possible on kmail, a robust way to start and stop all the background services and remove the UI from daemons that don't need them, and who knows maybe even support KWin for those of us using X11 apps ... Re X11: PyKDE4 needs to become aware of non-X11 KDE versions. On 15 Mar 2014, at 07:10, Ian Wadham iandw...@gmail.com wrote: Hi MacPorts guys, especially KDE port developers, Over at the main KDE developers' mailing list, kde-devel@kde.org I have been inadvertently stirring things up re the status of KDE ports on Apple OS X. It started with one of the KDE Promotion guys asking us to suggest things that need volunteers to test them during the Beta phase of KDE 4.13, which is current. He has written a news article about it. Of course I suggested the Palapeli jigsaw puzzle app on which I have been doing a lot of work lately. But then I wrote another mail asking how much testing is done of KDE's cross-platform and cross-desktop implementations and commenting on some of the problems we experience with KDE over here at MacPorts. I suggested that maybe it was time some KDE guys had a get-together with some MacPorts and KDE Windows guys and got to the bottom of such problems. And I said it would be nice to have some regular testing of Apple and Windows implementations of KDE. Well … the response was quite antagonistic at first, but I am old and thick-skinned and I stood my ground … :-) So now some of the KDE guys are coming round to my way of thinking, particularly some KDE sysadmin guys and a guy who is organising a workshop (a KDE sprint) at Randa, in August, a nice little village in Switzerland just down the valley from Zermatt and the Matterhorn. See http://randa-meetings.ch/ He wants to schedule a group at Randa on KDE cross-platform implementation. And he is looking for MacPorts and Homebrew representatives to attend. So now I am looking for some support over here. Marko Kaening (KMyMoney4 guy) is already over at kde-devel@kde.org banging the drum on our behalf. First I would like you to have look at the two threads on kde-devel@kde.org 1. What to test for 4.13? starts here … it is the more controversial of the two. http://lists.kde.org/?l=kde-core-develm=139418788102916w=2 2. Running KDE apps on Apple OS X starts here .. http://lists.kde.org/?l=kde-develm=139450777202393w=2 If there is anything I have said wrong please let me know on this MacPorts list. If you agree or disagree with what I am trying to achieve, please also let me know. Please do not get upset by anything that was written. Every group tends to think that the people on the other side of the river have two heads, but I have found in the course of a long career, that building bridges is a good way to solve problems. I also discovered, in the course of all this, that there are two well-known former KDE developers working over at Homebrew. I do not know if there are any at MacPorts, but if there are, please stand up. All the best, Ian W. ___ macports-users mailing list macports-us...@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
On Samstag, 15. März 2014 12:07:46 CEST, René JV Bertin wrote: and who knows maybe even support KWin for those of us using X11 apps ... What's your concern here? X11 on OSX should be provided by XQuartz which should provide native OSX titlebars (and integration into the OSX WM) I do not see how it would be ever possible (or reasonable) to have a second WM (let alone compositor) run on OSX (or Windows) - what would you expect it to do? Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
On 15 Mar 2014, at 13:35 , Thomas Lübking thomas.luebk...@gmail.com wrote: On Samstag, 15. März 2014 12:07:46 CEST, René JV Bertin wrote: and who knows maybe even support KWin for those of us using X11 apps ... What's your concern here? X11 on OSX should be provided by XQuartz which should provide native OSX titlebars (and integration into the OSX WM) Actually Qt4 gets installed in its native version as port qt4-mac these days. This means that XQuartz (X11.app) isn’t started at all to run KDE apps, if I am not mistaken. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
On Samstag, 15. März 2014 14:35:15 CEST, mk-li...@email.de wrote: On 15 Mar 2014, at 13:35 , Thomas Lübking thomas.luebk...@gmail.com wrote: On Samstag, 15. März 2014 12:07:46 CEST, René JV Bertin wrote: and who knows maybe even support KWin for those of us using X11 apps ... What's your concern here? X11 on OSX should be provided by XQuartz which should provide native OSX titlebars (and integration into the OSX WM) Actually Qt4 gets installed in its native version as port qt4-mac these days. This means that XQuartz (X11.app) isn’t started at all to run KDE apps, if I am not mistaken. I guess he was referring to actual X11 clients (xeyes ;-) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi, 2014-03-15 16:04 GMT+01:00: So, e.g. KDE is at version 4.12.2!!! (My SuSE's were never as current as MacPorts has been in years.) And, I want to underline that the building of almost all KDE4 ports seems to have been going flawless in the last while. Which is amazing, given there are almost no KDE core developers on MacOSX. === So, stating we should seriously consider dropping MacOS support IMHO, to prevent further discredit being done to KDE is doing neither side any good! :-) Quite the opposite - I think the fact that KDE is still alive on MacPorts is an amazing example of what Open Source can achieve and that should be cherished and praised - which is what I do herewith. :-) I apologize for making this statement then. It was done in response to a message which described at least some parts of KDE on Mac as severely broken, said that Mac users use 4-letter words when talking about KDE, and specifically mentioned the application that I work on and care about in the This sort of thing does discredit to KDE context (the latter was the reason why I responded to the message at all). It's good to know that the situation is not as bad as it seemed. Thanks for your message that clarified this. Regards, Frank Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi Frank, On 15 Mar 2014, at 17:30 , Frank Reininghaus frank7...@googlemail.com wrote: I apologize for making this statement then. It was done in response to :) Accepted. a message which described at least some parts of KDE on Mac as severely broken, said that Mac users use 4-letter words when talking I wasn’t aware of any 4-letter words. Sad that people who invest their spare time into giant project like this have to be faced with stuff like that. I absolutely understand where you are coming from. It's good to know that the situation is not as bad as it seemed. Thanks for your message that clarified this. Yep, I simply had to shout it out loud and clear. :) Certainly there are broken things every now and then, but luckily there are people dealing with it, investing time and effort to fix things by patches and if they can’t be sorted out sending bug reports and alike. I don’t know if the KDE developers know about the patches being used for the various KDE ports at MacPorts… Perhaps these would also be a good starting point for improving KDE step by step by communicating these patches upstream if that hadn’t happened up to now, so that they can be introduced in your code after review. Greets, Marko Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: MacPorts: Running KDE ports on Apple OS X
Hi folks, although it’s not KDE, but “only” pure Qt, still I thought it is worth mentioning: Thanks to support by its developer I was able to bring AT-Transfers [1] seamlessly via MacPorts to MacOSX [2] with only a few tweaks to make the Qt-Creator project build no problem. This shall support what has been said about the usability of Qt/KDE applications on Apple’s OS. Greets, Marko [1] http://schmufu.dyndns.org/dokuwiki/ab_transfer:start [2] http://www.macports.org/ports.php?by=namesubstr=abtransfers Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
video audio preview dolphin
Hi i have modified a little dolphin like you can see here http://www.youtube.com/watch?v=-zHatr2_xHQ but the sick stuff it's the video that is not shown can someone help me ? i get this message here QLayout: Attempting to add QLayout to PhononWidget , which already has a layout diff file http://wklej.org/id/1300553 this is the file phononwidget.cpp http://wklej.org/id/1300532 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
