Re: Scripting/Extensions BoF at Akademy?
On Saturday, 2014-08-09, 17:34:04, Kevin Krammer wrote: > Greetings all, > > I'd like to ask if there is any interest of having a BoF around the topic of > script language based extensions for KDE applications. I've added the BoF to the timetable for Monday, but we can still easily change that if anyone can't make it then. https://community.kde.org/Akademy/2014/Monday#Room_1_-_8_September We should probably also start a wiki page for the agenda and link it from there. I can probably do that tomorrow if nobody beats me to it :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [kdepim/frameworks] /: Port khbox
On Wednesday 30 July 2014 08:26:23 Montel Laurent wrote: > -KHBox *hb = new KHBox( this ); > +QWidget *hb = new QWidget( this ); > +QHBoxLayout *hbHBoxLayout = new QHBoxLayout(hb); > +hbHBoxLayout->setMargin(0); Note that when porting from K*Box to Q*BoxLayout, that the old KDE class defaulted to margin=0 and spacing=0, so in this case, you introduced spacing. > -hbox->setSpacing( KDialog::spacingHint() ); > +QWidget *hbox = new QWidget( mDateDisplay ); > +QHBoxLayout *hboxHBoxLayout = new QHBoxLayout(hbox); > +hboxHBoxLayout->setMargin(0); > +hboxHBoxLayout->setSpacing( KDialog::spacingHint() ); In this case, the K*Box needed a setSpacing() call to get rid of the zero spacing. Since old Qt versions did not offer default layout spacing values, we used KDialog::spacingHint() so that we do not need to hardcode a value. When porting to Q*BoxLayout, it is probably best to let the platform style decide about the actual spacing between elements, so simply remove the setSpacing() call in this case. > -KHBox *hb = new KHBox( this ); > -hb->setSpacing( 4 ); > +QWidget *hb = new QWidget( this ); > +QHBoxLayout *hbHBoxLayout = new QHBoxLayout(hb); > +hbHBoxLayout->setMargin(0); > +hbHBoxLayout->setSpacing( 4 ); Please do not use hard coded spacings. If you feel the default spacing provided by the Qt layouts is too big, use some fraction of the font height as a reference. Christoph Feck (kdepepo)
Re: Killing kdelibs master branch
On Dienstag, 12. August 2014 21:20:41 CEST, Albert Astals Cid wrote: Is git symbolic-ref refs/heads/master refs/heads/KDE/4.14 an option? Maybe, what does it do? Create a symbolic ref "master" that like the symbolic ref HEAD would (then) point KDE/4.14 Locally this just works "fine" - whatever you do using "master" applies to KDE/4.14 (including deleting the branch!) The question is whether you can do that on the remote (to have it for everybody). Doing it locally and pushing the ref afair isn't possible. Cheers, Thomas
Re: Killing kdelibs master branch
El Dimarts, 12 d'agost de 2014, a les 20:39:07, Thomas Lübking va escriure: > On Dienstag, 12. August 2014 14:41:31 CEST, Sebastian Kügler wrote: > > Reason, if I'm building kdelibs from git, my "autopilot" way > > would be cloning > > (which gives you the master branch, dunno what'd happen if > > there's no remote > > master in the origin), see master, and assume that I now have "latest" and > > that it is what I should do patches against. > > Is > > git symbolic-ref refs/heads/master refs/heads/KDE/4.14 > > an option? Maybe, what does it do? Cheers, Albert > > Cheers, > Thomas
Re: Killing kdelibs master branch
On Dienstag, 12. August 2014 14:41:31 CEST, Sebastian Kügler wrote: Reason, if I'm building kdelibs from git, my "autopilot" way would be cloning (which gives you the master branch, dunno what'd happen if there's no remote master in the origin), see master, and assume that I now have "latest" and that it is what I should do patches against. Is git symbolic-ref refs/heads/master refs/heads/KDE/4.14 an option? Cheers, Thomas
Re: Closing the kde-core-devel mailing list
On Monday 04 August 2014, Vishesh Handa wrote: > Hello people > > Random Idea: How about we close the k-c-d mailing list? It's main purpose > used to be to discuss kdelibs changes, but now since we have > kde-frameworks, the mailing list seems less useful. We already have > kde-devel for other generic kde stuff. hmm, I would maybe have seen a reason in doing like the other way around, closing kde-frameworks, merge the mails and move all on k-c-d, since frameworks is released and is the main target of development now -- Marco Martin
Re: Killing kdelibs master branch
El Dimarts, 12 d'agost de 2014, a les 14:41:31, Sebastian Kügler va escriure: > On Monday, August 11, 2014 00:23:15 Albert Astals Cid wrote: > > Hi there, I'm sending this e-mail to propose removing the master branch of > > kdelibs. > > > > We kind of already tried that when we froze it, but i am proposing to > > actually delete it (and enforce with hooks it doesn't come back) from > > git. > > > > Why I want to kill it now? > > > > Next release is not going to be "KDE SC 4.15" but simply "KDE Applications > > 2014.12". > > > > It does not make sense to release kdelibs 4.15 as part of "KDE > > Applications 2014.12", since it kind of defeats the purpose of the name. > > > > So we should not have a kdelibs 4.15 release, we should just be killing > > master and just doing some further releases of 4.14.x as bugfix, this way > > we avoid people using a branch of kdelibs that will never be released > > again. > > > > In the past we argued about the need to have new kdelibs versions since > > some applications use KDE_VERSION_NUMBER as their version number and we > > didn't want to break those apps. > > > > Well, applications using KDE_VERSION_NUMBER as their > > version number "are doing it wrong", as it will stop working once we move > > to KF5, since there's no such concept as "KDE VERSION" there, so we may > > as > > well fix them now. > > > > Any objection? > > No objection, since I don't commit to the kdelibs repo that much, but a > "but". > > Not having a master branch would be confusing to me. It would be much more > logical (and making kdelibs less special) to make the master branch what is > currently KDE/4.14 and branch releases off of that, so KDE/4.15 would be > branched off of master again. The policy of no features would still be in > place, just that master always has all the latest patches, and releases come > from that. There won't be "KDE SC 4.15" so no KDE/4.15 branch for kdelibs, it just dies in KDE/4.14, we can do as many 4.14.x releases of kdelibs as bugfixes we get and need. > Reason, if I'm building kdelibs from git, my "autopilot" way would be > cloning (which gives you the master branch, dunno what'd happen if there's > no remote master in the origin), see master, and assume that I now have > "latest" and that it is what I should do patches against. cloning after i killed the master branch will give you the 4.14 branch by default. Cheers, Albert > > Just a thought, ignore at will.
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 05, 2014 21:28:14 Kevin Krammer wrote: > On Tuesday, 2014-08-05, 20:29:05, Albert Astals Cid wrote: > > El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: > > > > > > Random Idea: How about we close the k-c-d mailing list? It's main > > > purpose > > > used to be to discuss kdelibs changes, but now since we have > > > kde-frameworks, the mailing list seems less useful. We already have > > > kde-devel for other generic kde stuff. > > > > kde-core-devel main purpose may had been discuss kdelibs changes, but it > > has trascended that purspose a while ago. > > I agree with Albert. > > k-c-d is the list to for things that happen in development, like kde-review > requests, inter-module coordination, etc. > It is more like a "kde-community-technical" list. > > kde-devel is more a list for question regarding developing with the KDE > platform. > If there is really a need to fold one list with kde-frameworks its this one. Assuming you mean "folding frameworks-devel", I'd agree. (We could "merge" these lists, of course.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Killing kdelibs master branch
On Monday, August 11, 2014 00:23:15 Albert Astals Cid wrote: > Hi there, I'm sending this e-mail to propose removing the master branch of > kdelibs. > > We kind of already tried that when we froze it, but i am proposing to > actually delete it (and enforce with hooks it doesn't come back) from git. > > Why I want to kill it now? > > Next release is not going to be "KDE SC 4.15" but simply "KDE Applications > 2014.12". > > It does not make sense to release kdelibs 4.15 as part of "KDE > Applications 2014.12", since it kind of defeats the purpose of the name. > > So we should not have a kdelibs 4.15 release, we should just be killing > master and just doing some further releases of 4.14.x as bugfix, this way > we avoid people using a branch of kdelibs that will never be released > again. > > In the past we argued about the need to have new kdelibs versions since > some applications use KDE_VERSION_NUMBER as their version number and we > didn't want to break those apps. > > Well, applications using KDE_VERSION_NUMBER as their > version number "are doing it wrong", as it will stop working once we move > to KF5, since there's no such concept as "KDE VERSION" there, so we may as > well fix them now. > > Any objection? No objection, since I don't commit to the kdelibs repo that much, but a "but". Not having a master branch would be confusing to me. It would be much more logical (and making kdelibs less special) to make the master branch what is currently KDE/4.14 and branch releases off of that, so KDE/4.15 would be branched off of master again. The policy of no features would still be in place, just that master always has all the latest patches, and releases come from that. Reason, if I'm building kdelibs from git, my "autopilot" way would be cloning (which gives you the master branch, dunno what'd happen if there's no remote master in the origin), see master, and assume that I now have "latest" and that it is what I should do patches against. Just a thought, ignore at will. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Scripting/Extensions BoF at Akademy?
Nice idea to do a BoF about this topic! Since we use a lot of QtScript in Rocs for scripting (and I really would like to also offer Python support), I am also quite interested. Do you want to suggest a time slot for the BoF? cheers, Andreas
[qca] /: cmake: install export targets to lib dir
Git commit f3b284f5654372adec44dbc6863b8434b6b4f3ce by Ivan Romanov.
Committed on 10/08/2014 at 10:38.
Pushed by iromanov into branch 'master'.
cmake: install export targets to lib dir
share/cmake is wrong place for generated cmake files. For such files
should be used lib/cmake dir.
CCMAIL: aleix...@kde.org
CCMAIL: kde-core-devel@kde.org
CCMAIL: kde-frameworks-de...@kde.org
M +4-4CMakeLists.txt
http://commits.kde.org/qca/f3b284f5654372adec44dbc6863b8434b6b4f3ce
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 24d8ab3..2838ecf 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -328,14 +328,14 @@ include(CMakePackageConfigHelpers)
configure_package_config_file(
"${CMAKE_CURRENT_SOURCE_DIR}/QCA2Config.cmake.in"
"${CMAKE_CURRENT_BINARY_DIR}/QCA2Config.cmake"
- INSTALL_DESTINATION "share/cmake/QCA2"
+ INSTALL_DESTINATION ${QCA_LIBRARY_INSTALL_DIR}/cmake/${QCA_LIB_NAME}
)
write_basic_config_version_file(QCA2ConfigVersion.cmake VERSION
${QCA_LIB_VERSION_STRING} COMPATIBILITY AnyNewerVersion)
-install(EXPORT QCATargets DESTINATION "share/cmake/QCA2" FILE
QCA2Targets.cmake NAMESPACE QCA:: )
+install(EXPORT QCATargets DESTINATION
${QCA_LIBRARY_INSTALL_DIR}/cmake/${QCA_LIB_NAME} FILE QCA2Targets.cmake
NAMESPACE QCA:: )
install(FILES
"${CMAKE_CURRENT_BINARY_DIR}/QCA2Config.cmake"
"${CMAKE_CURRENT_BINARY_DIR}/QCA2ConfigVersion.cmake"
- DESTINATION "share/cmake/QCA2"
+ DESTINATION ${QCA_LIBRARY_INSTALL_DIR}/cmake/${QCA_LIB_NAME}
COMPONENT Devel
-)
\ No newline at end of file
+)
Writing a unit test to test support for proxied connections in a computer that is not behind a proxy?
“I’m trying to maintain the KDE MediaWiki Library, so far only used by KIPI plugins, but I have some pet projects that rely on it as well. As part of that, I aim to keep the list of bug reports and feature requests (https://bugs.kde.org/buglist.cgi?product=libmediawiki&component=general&resolution=---&list_id=1061346) empty. As the library is barely used it is a fairly easy task, however I can’t figure out how to start with the only reported issue (feature request) so far: proxy support. I’m confident that I will be able to figure out how to implement the feature reading the API docs. I’m sure that there are several ways for me to make my computer think that it is behind a proxy, or to actually put it behind a proxy somehow (I can probably do something to the router to achieve that). But since I’m not usually behind a proxy myself, what I want first is to write a unit test for this feature, to make sure that I do not break it in the future. Has anyone here ever written a unit test to test support for proxied connections in a computer that is not behind a proxy? Do you think that it is possible? Specifically testing that the software uses the (KDE) system-wide proxy settings?” I sent the message above back in June to kde-testing: http://mail.kde.org/pipermail/kde-testing/2014-June/000395.html It was suggested to me at https://bugs.kde.org/show_bug.cgi?id=302598 to send it to this mailing list instead, and see if I got luckier.
