Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 23:30, Michal Humpula michal.hump...@seznam.cz wrote: If I may post a little input here. I've implemented print preview in kate (KF5) with QPrintPreviewDialog, mainly for the reasons mentioned above. But what I'm missing is ability to add custom configuration tabs as in KdePrint::createPrintDialog. Though KPrintPreview doesn't seems to support them either:-) Yeap, neither allows on-the-fly use of the custom tabs in the preview, which is a short-coming, but QPrintPreviewDialog at least gives the possibility of doing so in future with a dynamic update of the preview, KPrintPreview really doesn't support such a work flow. The other issue is anyone clicking on the print dialog button in the menu of QPrintPreviewDialog gets a dialog without any custom tabs either, which was one reason for not using it before when we added our extra stuff. It should be easy enough for me to add Qt api to allow you to set them and have the preview pass them through to the dialog, but I'm not sure how I'd show the widgets in the preview itself. Perhaps a button to pop them up? Something to think about anyway. John. P.S. Not forgetting that the app widgets are not cross-platform, they don't work on Windows or Mac, but that's on my feature plan for 5.4/5.5 time-frame. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 8 January 2014 07:17, Kevin Ottens er...@kde.org wrote: For the record, if that depends on QtPrintSupport it can't make it to KGuiAddons (which should depend only on QtCore and QtGui). Good point :-) I'm fine keeping it even if it's small. OK, I'll take the chainsaw to it this weekend and see what we're left with. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114895: Guard against null QX11Info::connection()
On Jan. 7, 2014, 3:14 p.m., Martin Gräßlin wrote: checking obviously makes sense, though it shouldn't be needed. There must be something else which is wrong here, too. Could you try what the value of WId is in these cases? I wouldn't be surprised if it were 0. Oh and that code has unit tests, so I would appreciate if you extend the tests for that case. David Edmundson wrote: WId seems to be valid. If I check the dialog with xwininfo before closing plasmoidviewer it shows the same ID. Here is a full backtrace of it being needed: http://pastebin.kde.org/pxjhgw95d I can guard against it inside plasma with if (!QApplication::closingDown()) around the KWindowEffects calls. I changed to guarding in the library as I can imagine others hitting it in the future and in general library code shouldn't crash on reasonable inputs. Martin Gräßlin wrote: The backtrace includes QWindow::destroy which as the name says will do an xcb_destroy_window. After that the DialogProxy::onVisibleChanged will be invoked. At that point the window doesn't exist any more so the X calls are just wrong. I'd say this needs fixing in DialogProxy to not call the X specific calls for a destroyed window. Then one could think about whether invoking the methods without a valid xcb_connection is supposed to work. I'd say we should add asserts there instead of the null checks. What do you think? I just had a look at the QWindow implementation and whether it could provide us a useable way to figure out whether there is a window at all. Unfortunately it doesn't. So ShipIt! - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/#review46967 --- On Jan. 7, 2014, 2:57 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/ --- (Updated Jan. 7, 2014, 2:57 p.m.) Review request for KDE Frameworks, Martin Gräßlin and Marco Martin. Repository: kwindowsystem Description --- Guard against null QX11Info::connection() This can fail if the application is currently shutting down, this is currently causing a crash on closing plasma with dialogs open. Diffs - src/kwindoweffects_x11.cpp 72cbb71 Diff: https://git.reviewboard.kde.org/r/114895/diff/ Testing --- Opened plasmoidviewer -a org.kde.example.widgetgallery expanded the applet, then closed plasmoidviewer It used to crash, now it doesn't. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is unstable: ktexteditor_master_qt5 #1
See http://build.kde.org/job/ktexteditor_master_qt5/1/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On 7 January 2014 23:52, Alex Merry k...@randomguy3.me.uk wrote: If these additions are something that applications would need to be aware of, I see no issue with creating a wrapper class or some such as-and-when we find a use for one. If they are something that would be hidden to applications, would you consider having platform integration hooks in QPrinter for that sort of thing? The idea is to add things without the app needing to know or worry about, and without having to go through every app and re-code to use a new wrapper (I did that for 4.0 and 4.2, never again!). On the other hand, without knowing what those requirements might be it's a bit much to assume that the current wrapper will meet those needs. Platform hooks are possible, we have a QPA plugin for printing, but would need to be done in a cross-platform way, and until those needs arise we don't know what shape it would need to take. For color management, the idea was an extra tab would be automatically added to the dialog if color management was configured, which would then query the config for the colorspace to use and do some magic to apply it. However the proposal we discussed at the Color Management hack-fest does rely on an obscure build-time dependency and a PDF based workflow using Ghostscript that I'm really not keen on. It's also requires a decision to support Oyranos and/or colord in the core that I don't think we're ready to make yet, or indeed have the abstraction classes to do so. I think for now it's better if the Oyranos and colord camps provide their own tab widgets that apps can choose to use to configure things, and then the app takes care of deciding on color management support and workflow. I'll look again at adding the color OutputIntent to Qt's PDF support, but I'd have to do that using a QString for the ICC Profile name, when I'd rather wait until we have a proper QIccProfile class to use. Sigh, so may tasks, so little time... Anyway, far too much detail for here, I think I'm convincing myself that it's less useful to keep the empty wrapper around for now, it may be better moved to KDE4Support, along with KPrintPreview, leaving an empty repo. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114895: Guard against null QX11Info::connection()
On Jan. 7, 2014, 2:14 p.m., Martin Gräßlin wrote: checking obviously makes sense, though it shouldn't be needed. There must be something else which is wrong here, too. Could you try what the value of WId is in these cases? I wouldn't be surprised if it were 0. Oh and that code has unit tests, so I would appreciate if you extend the tests for that case. David Edmundson wrote: WId seems to be valid. If I check the dialog with xwininfo before closing plasmoidviewer it shows the same ID. Here is a full backtrace of it being needed: http://pastebin.kde.org/pxjhgw95d I can guard against it inside plasma with if (!QApplication::closingDown()) around the KWindowEffects calls. I changed to guarding in the library as I can imagine others hitting it in the future and in general library code shouldn't crash on reasonable inputs. Martin Gräßlin wrote: The backtrace includes QWindow::destroy which as the name says will do an xcb_destroy_window. After that the DialogProxy::onVisibleChanged will be invoked. At that point the window doesn't exist any more so the X calls are just wrong. I'd say this needs fixing in DialogProxy to not call the X specific calls for a destroyed window. Then one could think about whether invoking the methods without a valid xcb_connection is supposed to work. I'd say we should add asserts there instead of the null checks. What do you think? Martin Gräßlin wrote: I just had a look at the QWindow implementation and whether it could provide us a useable way to figure out whether there is a window at all. Unfortunately it doesn't. So ShipIt! I had a try at making a unit test but couldn't reproduce the crash I was seeing in Plasma; deleting the m_widget and m_window before calling KWindowEffect::whatever didn't seem to be enough. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/#review46967 --- On Jan. 7, 2014, 1:57 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/ --- (Updated Jan. 7, 2014, 1:57 p.m.) Review request for KDE Frameworks, Martin Gräßlin and Marco Martin. Repository: kwindowsystem Description --- Guard against null QX11Info::connection() This can fail if the application is currently shutting down, this is currently causing a crash on closing plasma with dialogs open. Diffs - src/kwindoweffects_x11.cpp 72cbb71 Diff: https://git.reviewboard.kde.org/r/114895/diff/ Testing --- Opened plasmoidviewer -a org.kde.example.widgetgallery expanded the applet, then closed plasmoidviewer It used to crash, now it doesn't. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114895: Guard against null QX11Info::connection()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/ --- (Updated Jan. 8, 2014, 12:18 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Martin Gräßlin and Marco Martin. Repository: kwindowsystem Description --- Guard against null QX11Info::connection() This can fail if the application is currently shutting down, this is currently causing a crash on closing plasma with dialogs open. Diffs - src/kwindoweffects_x11.cpp 72cbb71 Diff: https://git.reviewboard.kde.org/r/114895/diff/ Testing --- Opened plasmoidviewer -a org.kde.example.widgetgallery expanded the applet, then closed plasmoidviewer It used to crash, now it doesn't. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114895: Guard against null QX11Info::connection()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/#review47047 --- This review has been submitted with commit 11775f9351b9fe944d522039400d0bb118fc4733 by David Edmundson to branch master. - Commit Hook On Jan. 7, 2014, 1:57 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/ --- (Updated Jan. 7, 2014, 1:57 p.m.) Review request for KDE Frameworks, Martin Gräßlin and Marco Martin. Repository: kwindowsystem Description --- Guard against null QX11Info::connection() This can fail if the application is currently shutting down, this is currently causing a crash on closing plasma with dialogs open. Diffs - src/kwindoweffects_x11.cpp 72cbb71 Diff: https://git.reviewboard.kde.org/r/114895/diff/ Testing --- Opened plasmoidviewer -a org.kde.example.widgetgallery expanded the applet, then closed plasmoidviewer It used to crash, now it doesn't. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kwindowsystem_master_qt5 #12
See http://build.kde.org/job/kwindowsystem_master_qt5/12/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114888: Avoid // in path in generated headers
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114888/ --- (Updated Jan. 8, 2014, 1:22 p.m.) Review request for Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- When the RELATIVE parameter in ECMGenerateHeaders is empty or not set, the _actualheader variable would be defined to /cmake/current/source/dir//lowercaseclassname.h. The double slash breaks RPM's debug symbols extraction, because it canonicalizes the path, so it's shortened by one /. The shortening is done to avoid double-slash in the beginning of the path, which is non-POSIX. However from my understanding it's not possible to truncate the size of directory table by 1 byte, so the debugedit utility aborts and the entire rpmbuild fails. See a relevant bug report with further information: https://bugzilla.redhat.com/show_bug.cgi?id=304121 (comment #2) This patch simply makes sure that EGH_RELATIVE is either empty, or non-empty and terminated with slash. With this patch we are able to build solid and kdnssd frameworks with RPM build tools. Diffs - modules/ECMGenerateHeaders.cmake f72b1c0 Diff: https://git.reviewboard.kde.org/r/114888/diff/ Testing --- Successfully built solid and kdnssd frameworks with rpmbuild, other frameworks still build too. Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Reviewboard and maintainers
Just a note that if you are the maintainer of a framework, you may want to add the following line to the .reviewboardrc file of the git repo: TARGET_PEOPLE = 'kde_username' For example, I would put TARGET_PEOPLE = 'alexmerry' This means that you get CC'd on every review request posted using RBTools; currently, it just goes to the kdeframeworks group. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114895: Guard against null QX11Info::connection()
On Jan. 7, 2014, 3:14 p.m., Martin Gräßlin wrote: checking obviously makes sense, though it shouldn't be needed. There must be something else which is wrong here, too. Could you try what the value of WId is in these cases? I wouldn't be surprised if it were 0. Oh and that code has unit tests, so I would appreciate if you extend the tests for that case. David Edmundson wrote: WId seems to be valid. If I check the dialog with xwininfo before closing plasmoidviewer it shows the same ID. Here is a full backtrace of it being needed: http://pastebin.kde.org/pxjhgw95d I can guard against it inside plasma with if (!QApplication::closingDown()) around the KWindowEffects calls. I changed to guarding in the library as I can imagine others hitting it in the future and in general library code shouldn't crash on reasonable inputs. Martin Gräßlin wrote: The backtrace includes QWindow::destroy which as the name says will do an xcb_destroy_window. After that the DialogProxy::onVisibleChanged will be invoked. At that point the window doesn't exist any more so the X calls are just wrong. I'd say this needs fixing in DialogProxy to not call the X specific calls for a destroyed window. Then one could think about whether invoking the methods without a valid xcb_connection is supposed to work. I'd say we should add asserts there instead of the null checks. What do you think? Martin Gräßlin wrote: I just had a look at the QWindow implementation and whether it could provide us a useable way to figure out whether there is a window at all. Unfortunately it doesn't. So ShipIt! David Edmundson wrote: I had a try at making a unit test but couldn't reproduce the crash I was seeing in Plasma; deleting the m_widget and m_window before calling KWindowEffect::whatever didn't seem to be enough. I think it must be really shutting down and that might not be a testable case in the unit tests. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/#review46967 --- On Jan. 7, 2014, 2:57 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114895/ --- (Updated Jan. 7, 2014, 2:57 p.m.) Review request for KDE Frameworks, Martin Gräßlin and Marco Martin. Repository: kwindowsystem Description --- Guard against null QX11Info::connection() This can fail if the application is currently shutting down, this is currently causing a crash on closing plasma with dialogs open. Diffs - src/kwindoweffects_x11.cpp 72cbb71 Diff: https://git.reviewboard.kde.org/r/114895/diff/ Testing --- Opened plasmoidviewer -a org.kde.example.widgetgallery expanded the applet, then closed plasmoidviewer It used to crash, now it doesn't. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114888: Avoid // in path in generated headers
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114888/#review47048 --- modules/ECMGenerateHeaders.cmake https://git.reviewboard.kde.org/r/114888/#comment33532 Since CMake has somewhat unexpected behaviour when using MATCHES with an empty string (I would expect (NOT MATCHES ^.*/$) to be true), it might be worth putting a comment in. - Alex Merry On Jan. 8, 2014, 12:22 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114888/ --- (Updated Jan. 8, 2014, 12:22 p.m.) Review request for Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- When the RELATIVE parameter in ECMGenerateHeaders is empty or not set, the _actualheader variable would be defined to /cmake/current/source/dir//lowercaseclassname.h. The double slash breaks RPM's debug symbols extraction, because it canonicalizes the path, so it's shortened by one /. The shortening is done to avoid double-slash in the beginning of the path, which is non-POSIX. However from my understanding it's not possible to truncate the size of directory table by 1 byte, so the debugedit utility aborts and the entire rpmbuild fails. See a relevant bug report with further information: https://bugzilla.redhat.com/show_bug.cgi?id=304121 (comment #2) This patch simply makes sure that EGH_RELATIVE is either empty, or non-empty and terminated with slash. With this patch we are able to build solid and kdnssd frameworks with RPM build tools. Diffs - modules/ECMGenerateHeaders.cmake f72b1c0 Diff: https://git.reviewboard.kde.org/r/114888/diff/ Testing --- Successfully built solid and kdnssd frameworks with rpmbuild, other frameworks still build too. Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [PATCH] Fail early if libsm is not installed
Le dimanche 29 décembre 2013 14:42:53 David Faure a écrit : On Thursday 19 December 2013 18:10:11 Aurélien Gâteau wrote: Hi, Attached patch causes cmake to fail early if libsm is not installed, rather than waiting until we try to build code using it. This patch also removes buggy calls to set_package_properties(). I found out calling set_package_properties() with something which is not a package as the first argument is currently silently ignored. Note that this means the TYPE argument is ignored as well, so marking something as REQUIRED has no effect. As a result I put together a poor-man feature_summary() implementation at the end of the CMakeLists.txt for X11 components. It's a bit overkill for the needs of kde4support, but can be duplicated or factorized later. I can't comment on whether there's a better way to do this, but anyway, the patch improves things so it should go in IMHO. Thanks, I just committed a simpler version of the patch, handling missing X11 features the same way kidletime does. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Wednesday 08 January 2014 12:21:10 John Layt wrote: it may be better moved to KDE4Support, along with KPrintPreview, leaving an empty repo. If that's the conclusion, then an option is just to leave everything in the current repo, and mark the whole repo (and its individual classes) as deprecated? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: sonnet_master_qt5 #7
See http://build.kde.org/job/sonnet_master_qt5/7/changes Changes: [martin.sandsmark] Start adding back language detection from SVN branch. [martin.sandsmark] Add trigrams. [martin.sandsmark] Add the TextBreaks class. [martin.sandsmark] Add support for finding paragraph breaks to TextBreaks. [martin.sandsmark] Add Tokenizer class. [martin.sandsmark] add a ParagraphTokenizer [martin.sandsmark] Improve detectLanguage. [martin.sandsmark] Add LanguageFilter class. [martin.sandsmark] add autodetectlanguage to settings, make backgroundchecker user tokenizer [martin.sandsmark] add warning in loader if no plugins found [martin.sandsmark] Improve debug output when trying to load trigrams [martin.sandsmark] add myself to copyright in settings file [martin.sandsmark] the C locale should lead to a english spell check [martin.sandsmark] add missing private implementation for backgroundchecker [martin.sandsmark] merge in language detection changes to highlighter [martin.sandsmark] remove unused BackgroundEngine class [martin.sandsmark] remove unuased unicode data [martin.sandsmark] Port Sonnet::Dialog from Filter to the Tokenizer [martin.sandsmark] Store and load language autodetect in config file. [martin.sandsmark] Add autodetect option for language in config widget [martin.sandsmark] Add : to heading for ignored words [martin.sandsmark] Fix slot name for adding/removing ignored words [martin.sandsmark] clear input for ignored words when add button is clicked [martin.sandsmark] Remove Filter class [martin.sandsmark] disable autotest for removed Filter class [martin.sandsmark] Fix install paths for plugins [martin.sandsmark] fix loading of plugins [martin.sandsmark] fix iterating of characters in the string [martin.sandsmark] make tokenizer handle items, not just start positions [martin.sandsmark] both japanese and chinese may use han characters [martin.sandsmark] Add more trigram models. [martin.sandsmark] remember to add button box to layout in sonnet dialog [martin.sandsmark] C means en_US, tiny fixes in dialog [martin.sandsmark] disable enchant backend, it is buggy [martin.sandsmark] clean up Highlighter [martin.sandsmark] remove deprecated signal Highlighter::newSuggestions [martin.sandsmark] Add some common KDE words to ignore list by default [martin.sandsmark] add more documentation in highlighter [martin.sandsmark] clean up [martin.sandsmark] refix rehighlight when changing language [martin.sandsmark] Update readme [martin.sandsmark] remove debug output [martin.sandsmark] use markdown in readme [martin.sandsmark] Remove implicit casting from ascii [martin.sandsmark] update the doxygen mainpage [martin.sandsmark] mention language detection in doxygen mainpage [martin.sandsmark] fix build with -DQT_NO_CAST_TO_ASCII/-DQT_NO_CAST_FROM_ASCII [martin.sandsmark] implement storage of special words in hspell plugin [martin.sandsmark] I think I deserve at least some credit now [martin.sandsmark] remove unused, slow function [martin.sandsmark] move all language detection into a separate class [martin.sandsmark] save config when values are set [martin.sandsmark] Fix name of language [martin.sandsmark] more explanation for the ye, yeyo and yo variants of russian [martin.sandsmark] remove unused paragraph tokenizer [martin.sandsmark] fix script type counting [martin.sandsmark] save and restore if language should be autodetected [martin.sandsmark] remove superflous break statements [martin.sandsmark] only load the language detection model on demand [martin.sandsmark] style fixes [martin.sandsmark] symbols are not part of words [martin.sandsmark] clean up backgroundtest [martin.sandsmark] rename plugins [martin.sandsmark] rename hunspell files [martin.sandsmark] rename aspell files [martin.sandsmark] rename hspell plugin files [martin.sandsmark] Add copy constructor, delete d pointer in LanguageFilter [martin.sandsmark] small style fixes [martin.sandsmark] Add nepomuk to known KDE words [martin.sandsmark] refs to qchars are stupid, thanks to dfaure for notifying me -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 3 in workspace http://build.kde.org/job/sonnet_master_qt5/ws/ Running Prebuild steps [sonnet_master_qt5] $ /bin/sh -xe /tmp/hudson4132319359808416582.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/sonnet * [new branch] langdet- origin/langdet 110fef7..5bc8746 master - origin/master From git://anongit.kde.org/sonnet * [new tag] v4.95.0- v4.95.0 Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 110fef7 Add README.md and yaml files Removing build/ Removing install/ Success build forhudson.tasks.Shell@22885f Fetching changes from the remote Git repository Fetching upstream
Review Request 114917: KDE Frameworks 5 should have kde5rc naming convention instead of kde4rc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114917/ --- Review request for KDE Frameworks. Repository: kconfig Description --- KDE Frameworks 5 should have kde5rc naming convention instead of kde4rc Diffs - docs/README.kiosk 4974ace src/core/kconfig.cpp 4f5553d Diff: https://git.reviewboard.kde.org/r/114917/diff/ Testing --- Thanks, Siddharth Sharma ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Tuesday 07 January 2014 20:48:39 David Faure wrote: The checklist for new frameworks can be extracted from http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation which gives: * make new repo using script (done, in your case) * run astyle-kdelibs (requires some patching, so I can do it if you want) * adjust kde-build-metadata * get the job set up on build.kde.org (Ben or Aurélien) * ensure green ;) * add to bugs.kde.org (d_ed: how?) * add to reviewboard.kde.org (sysadmin request I suppose) Any wiki page where I add this list? Maybe it should go at the end of the list from definition of done in http://community.kde.org/Frameworks/Epics/Splitting_kdelibs ? Following this discussion I added the following page: http://community.kde.org/Frameworks/CreationGuidelines I also modified a bit one of the policies: http://community.kde.org/Frameworks/Policies#Frameworks_buildsystem_is_consistent (was saying installation rules but it's really more about style of the buildsystem, we might want to reference aurélien's template there if someone feels like adding that). Seems to me that this is the only useful thing left from that wiki page, which we can otherwise delete, no? I'd keep it for reference, but yes it's more archives at that point. 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 114917: KDE Frameworks 5 should have kde5rc naming convention instead of kde4rc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114917/#review47089 --- I'll leave someone who knows this better (David Faure?) to say yes or no to this change. docs/README.kiosk https://git.reviewboard.kde.org/r/114917/#comment33562 Hmm... this all looks very out-of-date. We no longer have KStandardDirs (or, at least, KConfig does not use it). src/core/kconfig.cpp https://git.reviewboard.kde.org/r/114917/#comment33563 Missed one - kde4rc appears twice on this line. - Alex Merry On Jan. 8, 2014, 10:24 p.m., Siddharth Sharma wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114917/ --- (Updated Jan. 8, 2014, 10:24 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- KDE Frameworks 5 should have kde5rc naming convention instead of kde4rc Diffs - docs/README.kiosk 4974ace src/core/kconfig.cpp 4f5553d Diff: https://git.reviewboard.kde.org/r/114917/diff/ Testing --- Thanks, Siddharth Sharma ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On 08/01/14 22:24, Kevin Ottens wrote: I also modified a bit one of the policies: http://community.kde.org/Frameworks/Policies#Frameworks_buildsystem_is_consistent (was saying installation rules but it's really more about style of the buildsystem, we might want to reference aurélien's template there if someone feels like adding that). Done. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114917: KDE Frameworks 5 should have kde5rc naming convention instead of kde4rc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114917/ --- (Updated Jan. 8, 2014, 11:23 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kconfig Description --- KDE Frameworks 5 should have kde5rc naming convention instead of kde4rc Diffs - docs/README.kiosk 4974ace src/core/kconfig.cpp 4f5553d Diff: https://git.reviewboard.kde.org/r/114917/diff/ Testing --- Thanks, Siddharth Sharma ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
