Re: KIO / KWebView and PrivateBrowsing (Cookies)
Hi Dawit, Are there any news on this? 2013-04-22 3:51 GMT+04:00 Dawit A : > Started working on this to try and get it in for 4.11. Hopefully my solution > will work out as intended and discussed in this thread. > > > On Sat, Apr 13, 2013 at 5:10 PM, Àlex Fiestas wrote: >> >> Is there any news on this? >> >> >> On Thu, Apr 26, 2012 at 7:09 PM, Andrea Diamantini >> wrote: >>> >>> On 04/26/2012 05:17 PM, Alex Fiestas wrote: On Wednesday, April 25, 2012 04:26:28 PM Dawit A wrote: > > > If you wait a litte while I am going to fix this issue once and for all > since I want to add proper support for "Private browsing mode" in > kwebkitpart. I am sure the reKonq guys/gals will appreciate that as > well. Oookz ! >>> >>> WOW! >>> We surely are interested and we'll appreciate it a lot. So this is >>> something that can be implemented without touching actual kdelibs, right? So >>> a potential "next month" feature :D ?!
Re: KPeg (Board Game) moved to KDE Review
Hi Ronny, Please configure the i18n branches at [1], I guess "i18n trunk branch (KF5)" should be set up for extraction from branch master. Then you need to ask i18n maintainers in kde-i18n-doc (already in CC) to move the existing translations into trunk/l10n-kf5 so that we don't have to translate twice. Am I right that there will be no more KDELibs4-based releases of KPeg? [1] https://projects.kde.org/projects/kdereview/kpeg/settings -- Alexander Potashev 2015-05-27 13:43 GMT+03:00 Ronny Yabar Aizcorbe : > Hi all > > I was working on improving KPeg, an implementation of the Peg Solitaire > Game[0]. The game is designed for one player and consists of pegs on a board > with holes, the goal is to remove all pegs from the board except one. > > The game was in playground for some years, so I recently requested to move > it to KDE Review[1]. I think I fixed all the issues, added documentation, > added sounds and ported the game to KF5. The game is quite stable and uses > libkdegames classes like KGameRenderer, KgTheme, KgDifficulty and KgSound. > > I was reading the KDE Application Lifecycle, so I am copying this email to > kde-core-devel/kde-games-devel lists. > > The goal is that KPeg can be part of KDE Games and I am willing to maintain > it and continue adding new features. > > Can you please test the game and/or provide some feedback and make some > comments about the request? > > Thanks > > Ronny > > [0] http://en.wikipedia.org/wiki/Peg_solitaire > [1] https://projects.kde.org/projects/kdereview/kpeg
Re: KPeg (Board Game) moved to KDE Review
2015-06-03 21:35 GMT+03:00 Burkhard Lück : > Am Dienstag, 2. Juni 2015, 00:06:04 schrieb Alexander Potashev: >> >> Please configure the i18n branches at [1], I guess "i18n trunk branch >> (KF5)" should be set up for extraction from branch master. Then you >> need to ask i18n maintainers in kde-i18n-doc (already in CC) to move >> the existing translations into trunk/l10n-kf5 so that we don't have to >> translate twice. >> > translations moved Burkhard, Thanks for you effort, but it was too early: the project is still set up for extraction to trunk/l10n-kde4, so Scripty will keep recreating templates there. I don't know if anyone but Ronny can fix this configuration. -- Alexander Potashev
Re: Re: Frameworks compiler and Qt requirements after Qt 5.7?
Hi everyone,
2015-06-26 18:46 GMT+03:00 Martin Gräßlin :
> Thus I think the question about compiler requirement and Qt requirement are
> not coupled. Just because we raise the one or the other doesn't mean we should
> raise both.
Correct. Consider the following workflow: the user installs the latest
Qt 5.7 from binary packages and builds the latest KF5 from Git. He
will only need gcc-4.5. But if we bumped KF5 requirements to gcc-4.7,
then the user would need to update gcc for no good reason.
Mark,
In my opinion you had to start this kind of discussion with
emphasizing the new features in Qt 5.{6,7} and in new versions of
compilers that would help us make KF5 better. For me this is still
unclear.
--
Alexander Potashev
Re: KScreenGenie moved to KDE Review
2015-07-04 0:53 GMT+03:00 Albert Astals Cid : > For some reason /usr/include/x86_64-linux-gnu/qt5/QtX11Extras is not in the > include path. > > Any idea why? Fixed in http://commits.kde.org/kscreengenie/ace898e614d612a84ee12f22562d6d7365ee24bc Because when XCB_FOUND is not set, Qt5::X11Extras is not added to target_link_libraries(), see src/CMakeLists.txt. target_link_libraries() implicitly also adds respective include directories. When there is no target_link_libraries(... Qt5::X11Extras), [...]/QtX11Extras is not added as include path. -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
2015-07-04 12:43 GMT+03:00 Boudhayan Gupta : > You've gone ahead and moved all the includes from the header file to > the .cpp file? I'm going to revert that commit, since the decision to > keep all the #includes in the header is a coding style decision I > consciously made. I know this extends build times, but this keeps > things tidy - I can see exactly which components a single cpp file > depends on my looking at the headers, I don't have to look through > both the cpp and the header file. The cpp file should include one and > only one header file, and that's it's own header. > > I appreciate you fixing the build without XCB very much. However, > before making major coding style changes, please use the Review Board > or ask over e-mail. KScreenGenie does *not* use the kdelibs coding > style. Hi Boudhayan, A good practice is to not rely on the headers pulled transitively, see [1,2]. So, the .cpp file should have all these includes anyway; and when it does, there is no reason to keep unnecessary includes in the header. Projects use different coding styles because each has its pros and cons. But regarding this #include thing the solution recommended in the links below is much more advantageous than what you decided to do. [1] http://programmers.stackexchange.com/a/262020 [2] http://stackoverflow.com/a/15420950 -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
2015-07-04 13:11 GMT+03:00 Boudhayan Gupta : >> [1] http://programmers.stackexchange.com/a/262020 >> [2] http://stackoverflow.com/a/15420950 > > I'd seen both of these topics before. I'd obviously use minimal > headers in libraries and other projects where the headers could be > used by the public to build their own software, since cumulative > headers pull in headers that might be completely unnecessary to the > aforesaid software. > > However here, where all headers are private, it makes much more sense > from an organization point of view to have cumulative headers, at > least for me. Boudhayan, It doesn't seem right to apply different rules to headers that are exported and not exported. Are you going to rewrite the includes if/when the class ImageGrabber becomes a public library? (E.g. when someone wants to incorporate a screen grabber into his application.) You said "I can see exactly which components a single cpp file depends on my looking at the headers". If you follow the recommendation in the links [1,2], all the dependent components will be included in the .cpp file, so you can see exactly what you want there. Any other issue with it? And finally, why using distinct coding style while there's established Kdelibs coding style? Is your coding style documented somewhere? If not, then I'm sure KSG will become a mix of different coding styles in a while because people don't know what coding style to follow. -- Alexander Potashev
Re: KScreenGenie moved to KDE Review
Boudhayan, Please find my comment below. 2015-07-04 14:29 GMT+03:00 Boudhayan Gupta : >> You said "I can see exactly which components a single cpp file depends >> on my looking at the headers". If you follow the recommendation in the >> links [1,2], all the dependent components will be included in the .cpp >> file, so you can see exactly what you want there. Any other issue with >> it? > > No, some of them stay over in the header file. "Everything in one > place", for a small application such as this, which is not a public > library, takes precedence over minorly increased build times. Again, if you follow the links [1,2], then Foo.cpp should have #include even if Foo.h already contains it, in order to account for possible removal of that #include from Foo.h in the future. In this way, Foo.cpp acts like "one place for everything", the header #including only a minimal set files and minimal forward declarations to make it compile. > That said, having to go through the commitdiffs for *four* unannounced > commits, two of which were major, to find the *one* location where the > real fix was and isolating that, is a huge waste of time which I could > have otherwise used to make important pending fixes to the UI and > program behaviour. Sorry, I didn't expect the #include change to be questionable. Will try to make my future commits more atomic. -- Alexander Potashev
Adding kross-interpreters to KDE Applications 15.08
Hi, I would like to request addition of the Qt5/KF5 port of kross-interpreters [1] into KDE Applications 15.08.x. I didn't manage to fix the Java plugin yet (JNI linkage turns out to be broken at run-time), so the only language currently supported by kross-interpreters is Python 2. But this already enables Python scripting in Lokalize which may be really helpful. There is nothing to translate: krosspython does not contain i18n() calls. [1] http://quickgit.kde.org/?p=kross-interpreters.git&a=shortlog&h=frameworks -- Alexander Potashev
Re: Adding kross-interpreters to KDE Applications 15.08
2015-07-09 23:07 GMT+03:00 Albert Astals Cid :
> El Dijous, 9 de juliol de 2015, a les 05:23:27, Alexander Potashev va
> escriure:
>> Hi,
>>
>> I would like to request addition of the Qt5/KF5 port of
>> kross-interpreters [1] into KDE Applications 15.08.x.
>
> Are they co-installable with the ones we shipped in the KDE SC 4 series?
Albert,
The new krosspython installs only one file krosspython.so into
${KDE_INSTALL_PLUGINDIR}. It might depend on the distro, but here on
Gentoo two versions of krosspython.so go into different locations:
- /usr/lib/qt5/plugins/krosspython.so
- /usr/lib/kde4/krosspython.so
kross-interpreters is probably at the same level of co-installability
as kdelibs4 and KF5::Kross, because KF5::Kross contains krossqts.so
(plugin for QtScript support), ... except for installation path being
${KDE_INSTALL_QTPLUGINDIR} for krossqts.so.
What is the difference between KDE_INSTALL_QTPLUGINDIR and
KDE_INSTALL_PLUGINDIR?
--
Alexander Potashev
Re: Porting to frameworks 2: libkcompactdisc
2015-09-04 0:49 GMT+03:00 Jeremy Whiting : > Second project I took a quick stab at libkcompactdisc which > audiocd-kio will need (which amarok will need for playing audio cds > once it's ported to qt5/kf5 too). I pushed to a frameworks branch and > it builds, but the resulting library is called > libkcompactdisc.so.SOVERSION. I guess we need to set a specific > version for this library, probably bumped from what the old > qt4/kdelibs4 version was? Hi Jeremy, I think the new fancy library naming scheme is "libKF5Xxx.so.SOVERSION", regardless of it being part of KF5 or not. Thus libKF5CompactDisc.so.5. -- Alexander Potashev
Re: Porting to frameworks 2: libkcompactdisc
2015-09-04 14:59 GMT+03:00 Friedrich W. H. Kossebau : > Am Freitag, 4. September 2015, 02:28:49 schrieb Alexander Potashev: >> I think the new fancy library naming scheme is >> "libKF5Xxx.so.SOVERSION", regardless of it being part of KF5 or not. >> Thus libKF5CompactDisc.so.5. > > If that really is the scheme (is that noted somewhere?), I would ask to > reconsider it. For once, because it will result in clashes if a lib really > becomes part of KF5 (and thus becomes part of other packages which might be > installed together with a package where the lib was initially in, unless the > lib is the only content of the package, so that can be completely replaced by > the KF5 package) > > And also does it blur the hint by the name if something is part of KF5 or not. > This lib may be using KF5, but it is not KF5. That namespace should be left to > KF5 libs, like libQt* is left to Qt libs. > > I would rather propose libkcompactdisc2.so.SOVERSION here, so namespacing by > postfix number. There is also the pattern libkcompactdisc-qt5.so.SOVERSION, > which strikes out the dep to qt5, but not my favourite due to that > verboseness. :) Hi Friedrich, It won't clash when the library moves to KF5 if you bump the version to the next KF5 version to be released (e.g. 5.15 at the moment). It's even better to keep the same naming scheme when for the library when it joins KF5 because dependent projects won't need adaptation to the new library name. And I guess library users won't care if the library is part of KF5 or not. -- Alexander Potashev
Removal of ksaneplugin from KDE Applications
Hi, The only user for ksaneplugin used to be Kolourpaint in KDE Applications 15.08.x. I have now ported Kolourpaint from KScanDialog to libksane as suggested here [1,2] (same thread), thus ksaneplugin can be dropped from KDE Applications 15.12. BTW, is Kolourpaint ready for KF5 releases? I guess the only showstopper is qimageblitz-qt5 being unreleased. [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2013-August/004862.html [2] https://mail.kde.org/pipermail/kde-frameworks-devel/2013-September/004884.html -- Alexander Potashev
Re: Removal of ksaneplugin from KDE Applications
2015-09-25 9:53 GMT+03:00 Martin Koller :
> On Friday 25 September 2015 07:49:09 Alexander Potashev wrote:
>> Hi,
>>
>> The only user for ksaneplugin used to be Kolourpaint in KDE
>> Applications 15.08.x. I have now ported Kolourpaint from KScanDialog
>> to libksane as suggested here [1,2] (same thread), thus ksaneplugin
>> can be dropped from KDE Applications 15.12.
>
> thanks!
>
> hmmm... I'm trying to build kolourpaint now and get:
> /home/KDE5/source/kolourpaint/mainWindow/../scan/sanedialog.h:29:23: fatal
> error: KSane/KSane: No such file or directory
> #include
> I have installed libksane-devel-15.08.1-1.1 (openSuse 13.2) which contains
> just these includes
> /usr/include/libksane
> /usr/include/libksane/ksane.h
> /usr/include/libksane/libksane_export.h
> /usr/include/libksane/version.h
Hi Martin,
You must be on the frameworks branch. Then you need libksane/KF5 which
is not yet released, please install it from libksane repo's frameworks
branch.
But I have no idea why scandialog.{h.cpp} are even built when you
don't have libksane/kf5. Please try building from scratch, with a
clean build/CMakeCache.txt.
--
Alexander Potashev
Naming scheme for Qt5/KF5-based libraries outside of KF5
Hi everyone, We had a little discussion on how to name shared libraries in kde-core-devel@ thread "Porting to frameworks 2: libkcompactdisc" [1], but we did not come to consensus. The question is, if you release a shared library with deps on Qt5 and/or KF5, but the lib is not part of KF5, how should the .so file be named? 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so). 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so. 3. (probably some others?) Friedrikh said in [1] that using a KF5 prefix for all libraries will "blur the hint by the name if something is part of KF5 or not". Any thoughts? I believe we can have guidelines for library names. And another question that developers might ask in the future: These prefixes/suffixes are probably not necessary when the library is new, i.e. did not have a Qt4 version under the same name (e.g. KDb) - should such libraries still use a prefix/suffix? [1] http://comments.gmane.org/gmane.comp.kde.devel.core/87533 -- Alexander Potashev
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
2015-09-27 1:39 GMT+03:00 Albert Astals Cid : > El Diumenge, 27 de setembre de 2015, a les 04:01:26, Boudhayan Gupta va > escriure: >> On 27 September 2015 at 03:36, Albert Astals Cid wrote: >> > El Dissabte, 26 de setembre de 2015, a les 16:27:22, Sune Vuorela va > escriure: >> >> On 2015-09-26, Alexander Potashev wrote: >> >> > 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so). >> >> > 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so. >> >> > 3. (probably some others?) >> >> > >> >> > Friedrikh said in [1] that using a KF5 prefix for all libraries will >> >> > "blur the hint by the name if something is part of KF5 or not". >> >> > >> >> > Any thoughts? I believe we can have guidelines for library names. >> >> >> >> I do think that having things named KF5 that aren't actual frameworks is >> >> bad for several reasons. >> >> >> >> 1) It blurs what's a framework >> >> 2) We promise ABI and API compatibility for frameworks, but not for >> >> other things >> >> 3) Moving something from "not a KDE Framework" to "KDE Framework" gives >> >> a last chance for fixing up abi/api. >> >> >> >> so. foo-qt5 is fine for a qt5 version of foo. >> > >> > I agree, the problem is that there's few exceptions to copy from, so >> > that's >> > the exact reason libkdegames has that KF5 thing in the name, the guy that >> > did the port just copied what the frmeworks do. >> > >> > So anyone up for write what "a library that is not frameworks should do to >> > be nice in the KDE land"? >> >> We could kill two birds with one stone here, creating a new KDE module >> just for libraries (say, KDE Companion Libraries or something) and put >> everything in the KC5 (or whatever we decide) namespace. >> >> I'm all for just putting everything in KDE Support, using the KS5 >> namespace and removing the tier0 restriction from Support. > > I don't see which birds it kills, as far as I see it it only gives you the > problem of having yet another product to release. Sune, Boudhayan, Albert, Thanks for your feedback! I think we already have consensus on the "-qt5" suffix. I'll go rename the shared libraries in a few repos... :) Albert, do you mean you want a Techbase page with guidelines for libraries? Regarding the library product, Boudhayan almost repeated my proposal [1]. But using a namespace (e.g. KC5::) would not be a good idea because this product may contain completely disconnected libraries. "-qt5" suffixes should be enough. For KF5 the namespace makes sense because the frameworks have numerous dependencies between one another, thus KF5 feels and is promoted as an all-in-one product. [1] https://mail.kde.org/pipermail/release-team/2015-June/008628.html -- Alexander Potashev
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
2015-09-27 12:42 GMT+03:00 Boudhayan Gupta : > I'm still in favour of a new product, or reusing KDESupport, or even > Extragear libs. If you must use a suffix though, please consider using > Qt5, not -qt5, so that the lib becomes libSomeThingQt5, not > libSomeThing-qt5. Boudhayan, Camel case naming rule applies only to the frameworks already in KF5. If your library is not part of KF5, then you can name it in lowercase: libkcompactdisc-qt5, and the dash doesn't look ugly here IMO. -- Alexander Potashev
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
2015-09-27 21:05 GMT+03:00 Sune Vuorela : > On 2015-09-27, Boudhayan Gupta wrote: >> "Seen before" is no reason to not move forward if we can actually fix >> this. As I said, Extragear library developers will *have* to provide >> API/ABI guarantees. > > Good luck with that. > >> That's the ideal scenario, but isn't becoming a framework... hard? > > No. Once you have something useful, reviewed and wants to commit to > abi/api stability it is just a bit of paperwork. Sune, One does not simply commit to ABI/API stability. Look at kmime, kmbox, etc: KDE PIM team was about to submit these libraries into KF5, but now they have to bump SOVERSIONs [1] because of breaking ABI. And you can also look at the numbers: KF5 grows at the rate of less than one framework per month. We probably don't have enough manpower to review dozens/hundreds of libraries in a short period of time. [1] https://git.reviewboard.kde.org/r/125285/ -- Alexander Potashev
Re: Naming scheme for Qt5/KF5-based libraries outside of KF5
Hi David, 2015-09-28 23:21 GMT+03:00 David Faure : > Naming: "experimental" sounds like "it will be a framework at some point, > when it > stabilizes". Maybe we should say "internal" either, i.e. used internally by > apps > and workspace, don't use outside of that. Which still doesn't prevent a > framework > tagged "internal" from turning a proper public framework later. > > Maybe the "experimental" or "internal" should even be part of the tarball name > and distro package names, to make really sure app developers see that. Sounds good, I'm only worried about users/developers disregarding these libraries because they have "experimental" in their names, even though they may have been around and work OK for 5+ years already. We still need some distinct naming scheme/namespace for kf5-experimental, right? -- Alexander Potashev
Re: Dictionary KRunner Plugin
2010/7/31 Jason A. Donenfeld : > Hopefully at some point there will be the ability for the user to > define his own trigger word, but "define" will still be a translatable > default. There is a translatable string "Trigger Word" in dictionaryrunner_config.cpp, but I don't see the "Configure" button for the runner "Dictionary" (I expect the trigger word to be configurable). What am I doing wrong? -- Alexander Potashev
Replacement for Qt's Undo Framework
Hi,
The Qt's Undo Framework (QUndoCommand, QUndoStack, QUndoGroup,
QUndoView) has a few oddities:
1. The names of undo actions can only have a predefined prefix
(https://bugs.kde.org/show_bug.cgi?id=253459),
2. You can't use different strings for the name of undo action (Edit
-> Undo/Redo [some action]) and for the items in the undo history
(there is such panel, for example, in Step and Krita). The reason for
having different strings is to make grammatical cases of the names of
actions consistent with the context (in Russian and a few other
languages you should put %1 in accusative case in "Undo %1").
If I'm not mistaken, those problems can't be solved by just deriving
your own classes from QUndo*, because you need to override methods
like createUndoAction which are not "virtual" (sure, you can name
those methods differently, but then other problems may arise).
The solution is to fork QUndo* classes and fix the problems in the new
classes, so did I:
https://github.com/aspotashev/libkundo2
(the code looks like garbage, I only made it working, but didn't try
to clean it up)
At the first glance, the only way to use two strings for every
UndoCommand is to add yet another argument to the constructor of
UndoCommand. But then a huge amount of code would need changes, that's
not very good. Also, most languages don't really need different names
for undo actions and items in undo history.
I kept the arguments of UndoCommand() the same, but now if you put
something like "Create a document|-|creation of a document" as the
"text" into the constructor (or translate it with a similar string
with "|-|"), you'll get "Create a document" as the name of an item in
Undo History panel, and the "Undo ..." menu item will be called "Undo
creation of a document".
Screenshots:
http://ompldr.org/vOGYxaQ -- translation in Lokalize (into Russian)
http://ompldr.org/vOGYxag -- Step using different translations for
"Undo ..." command and undo history.
The patch I used for Step is attached.
What do you think about inclusion of KUndo*2 into kdelibs?
--
Alexander Potashev
From aec3a9f2fa6c16d46a5de10bb29441007245c676 Mon Sep 17 00:00:00 2001
From: Alexander Potashev
Date: Mon, 25 Apr 2011 19:46:51 +0400
Subject: [PATCH] use libkundo2
---
step/CMakeLists.txt |1 +
step/mainwindow.cc |4 ++--
step/undobrowser.cc |4 ++--
step/undobrowser.h |4 ++--
step/worldmodel.cc | 16
step/worldmodel.h | 10 +-
6 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/step/CMakeLists.txt b/step/CMakeLists.txt
index 4d571ea..e26dcd3 100644
--- a/step/CMakeLists.txt
+++ b/step/CMakeLists.txt
@@ -65,6 +65,7 @@ include_directories(${CMAKE_CURRENT_SOURCE_DIR})
kde4_add_executable(step ${step_SRCS})
target_link_libraries(step
stepcore
+kundo2
${KDE4_KHTML_LIBS}
${KDE4_KNEWSTUFF3_LIBS}
${QT_QTOPENGL_LIBRARY}
diff --git a/step/mainwindow.cc b/step/mainwindow.cc
index fdc0e50..cdc5169 100644
--- a/step/mainwindow.cc
+++ b/step/mainwindow.cc
@@ -177,9 +177,9 @@ void MainWindow::setupActions()
connect(worldModel->undoStack(), SIGNAL(canRedoChanged(bool)), actionRedo, SLOT(setEnabled(bool)));
connect(worldModel->undoStack(), SIGNAL(canUndoChanged(bool)), actionUndo, SLOT(setEnabled(bool)));
connect(worldModel->undoStack(), SIGNAL(cleanChanged(bool)), this, SLOT(updateCaption()));
-connect(worldModel->undoStack(), SIGNAL(undoTextChanged(const QString&)),
+connect(worldModel->undoStack(), SIGNAL(undoActionTextChanged(const QString&)),
this, SLOT(undoTextChanged(const QString&)));
-connect(worldModel->undoStack(), SIGNAL(redoTextChanged(const QString&)),
+connect(worldModel->undoStack(), SIGNAL(redoActionTextChanged(const QString&)),
this, SLOT(redoTextChanged(const QString&)));
actionDelete = actionCollection()->add("edit_delete", worldModel, SLOT(deleteSelectedItems()));
diff --git a/step/undobrowser.cc b/step/undobrowser.cc
index 05e6fdc..7979f44 100644
--- a/step/undobrowser.cc
+++ b/step/undobrowser.cc
@@ -20,7 +20,7 @@
#include "undobrowser.moc"
#include "worldmodel.h"
-#include
+#include
#include
#include
#include
@@ -28,7 +28,7 @@
UndoBrowser::UndoBrowser(WorldModel* worldModel, QWidget* parent, Qt::WindowFlags flags)
: QDockWidget(i18n("Undo history"), parent, flags), _worldModel(worldModel)
{
-_undoView = new QUndoView(_worldModel->undoStack(), this);
+_undoView = new KUndoView2(_worldModel->undoStack(), this);
setWidget(_undoView);
}
diff --git a/step/undobrowser.h b/step/undobrowser.h
index a60d679..c05629d 100644
--- a/step/undobrowser.h
+++ b/step/undobrowser.h
@@ -22,7 +22,7 @@
#include
c
Re: Replacement for Qt's Undo Framework
2011/4/26 Albert Astals Cid : >> I kept the arguments of UndoCommand() the same, but now if you put >> something like "Create a document|-|creation of a document" as the >> "text" into the constructor (or translate it with a similar string >> with "|-|"), you'll get "Create a document" as the name of an item in >> Undo History panel, and the "Undo ..." menu item will be called "Undo >> creation of a document". > > This approach seems a bit too fragile to "wrong/careless" translations, though > i guess we can always add it to the pology checks I didn't mention it, but traditional undo command names (w/o "|-|") work in KUndo2 exactly like in plain QUndoCommands (see the "else" block in https://github.com/aspotashev/libkundo2/blob/master/src/kundostack2.cpp#L267). Nothing is going to be broken unless you accidentally but "|-|" in your translation not knowing what that means (i.e. translators and developers can just ignore this functionality). -- Alexander Potashev
Re: Replacement for Qt's Undo Framework
2011/4/26 Aaron J. Seigo :
> On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote:
>> What do you think about inclusion of KUndo*2 into kdelibs?
>
> we really don't want more duplication of code and effort between Qt and
> kdelibs, and we certainly don't want forks of Qt code in kdelibs.
>
> please work on having this fixed in Qt itself, which is the correct/best place
> for this effort. it would be good to have this improved, and it's great that
> you're willing to work on it :)
Attempts to fix the bug in Qt are going to look very hacky (and those
hack will most likely not be accepted for inclusion in Qt), or even
break the Qt API (as Albert has also written).
Example: The prefix "Undo"/"Redo" is stored in an instance variable
(m_prefix) of QUndoAction. If we still allow custom prefixes
(otherwise it will be an API breakage), we need to keep m_prefix. This
will lead to unnecessary memory usage for it.
> in the code you've written, i see in the #includes KLocale as well as some
> "kis_" files. i didn't see any actual use of KLocale, however? is there any
> actual use of kdelibs in your work (hopefully not, as that would make a Qt
> target easier), are there any binary incompatible changes (again, hopefully
> not... :)
KLocale is here for i18n() (i18n("Undo %1"), i18n("Undo action"), etc).
The "kis_" includes were left over after copying KUndoView2 from
Krita's KisUndoView, they can be removed.
--
Alexander Potashev
Review Request: Add message contexts "@title:window" to all window and dialog titles
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101299/ --- Review request for KDE Base Apps. Summary --- Context strings added to 106 strings. Diffs - kdepasswd/kcm/chfacedlg.cpp 9fb8ab3 kdepasswd/passwddlg.cpp 27af7ee kdialog/kdialog.cpp b80ad9a keditbookmarks/actionsimpl.cpp 1a7e22e keditbookmarks/importers.cpp 777d8a5 keditbookmarks/main.cpp bd3cccd kfind/kfinddlg.cpp 28b6044 kfind/kfindtreeview.cpp c9fe034 kfind/kquery.cpp 8d67fab konq-plugins/adblock/adblock.cpp c2128d3 konq-plugins/adblock/adblockdialog.cpp f5357eb konq-plugins/akregator/pluginbase.cpp a88ca0f konq-plugins/autorefresh/autorefresh.cpp 57286b1 konq-plugins/babelfish/plugin_babelfish.cpp 90bb16d konq-plugins/domtreeviewer/domtreeview.cpp e648d29 konq-plugins/domtreeviewer/domtreewindow.cpp edab063 konq-plugins/khtmlsettingsplugin/settingsplugin.cpp a9414ca konq-plugins/kimgalleryplugin/imgallerydialog.cpp 61a68cb konq-plugins/kttsplugin/khtmlkttsd.cpp eaaee25 konq-plugins/shellcmdplugin/kshellcmdplugin.cpp 0bf58c3 konq-plugins/validators/plugin_validators.cpp e80696d konq-plugins/validators/reportdialog.cpp b40f82f konq-plugins/validators/validatorsdialog.cpp 72bfb2c konq-plugins/webarchiver/archivedialog.cpp 07e1d1e konq-plugins/webarchiver/plugin_webarchiver.cpp fa3422b konqueror/about/konq_aboutpage.cc 052b35d konqueror/settings/kio/kcookiespolicies.cpp 23d1a31 konqueror/settings/kio/kenvvarproxydlg.cpp c0086d4 konqueror/settings/kio/kmanualproxydlg.cpp 17a1944 konqueror/settings/kio/kproxydlg.cpp c611dfa konqueror/settings/kio/ksaveioconfig.cpp 8d4d18f konqueror/settings/kio/useragentdlg.cpp ff6a176 konqueror/settings/konq/kcustommenueditor.cpp 39192ba konqueror/settings/konqhtml/generalopts.cpp 1ccd6c8 konqueror/settings/konqhtml/javaopts.cpp 7120766 konqueror/settings/konqhtml/jsopts.cpp 3166126 konqueror/settings/konqhtml/pluginopts.cpp 366a885 konqueror/sidebar/history_module/kcmhistory.cpp 6e22423 konqueror/sidebar/sidebar_widget.cpp 9475fa7 konqueror/sidebar/trees/bookmark_module/bookmark_module.h 4403ce7 konqueror/sidebar/trees/bookmark_module/bookmark_module.cpp e39f2b4 konqueror/sidebar/trees/konq_sidebartree.cpp 40bd4a5 konqueror/sidebar/web_module/web_module.cpp 4663e56 konqueror/src/konqextensionmanager.cpp f9f231b konqueror/src/konqhistoryview.cpp 2b1e192 konqueror/src/konqmainwindow.cpp 1054569 konqueror/src/konqprofiledlg.cpp c968abc konqueror/src/konqsessiondlg.cpp 274fd5c konqueror/src/konqsessionmanager.cpp e31156e konqueror/src/konqview.cpp 16c9d29 konqueror/src/konqviewmanager.cpp a4dd00f lib/konq/konq_operations.cpp afefeef Diff: http://git.reviewboard.kde.org/r/101299/diff Testing --- Thanks, Alexander
Re: Replacement for Qt's Undo Framework
2011/4/26 Aaron J. Seigo : > it's bad practice if it can be fixed in Qt; it's not bad practice if it is > something that doesn't belong in Qt. kdelibs should be a value-add extension > of Qt for areas that make sense primarily/exclusively to the kinds of apps we > create and/or target. it should not be a collection of bug fixes or minor > improvements to Qt. Both problems fixed in Qt 4.8 with these patches: https://qt.gitorious.org/qt/qt/merge_requests/1212 https://qt.gitorious.org/qt/qt/merge_requests/2610 About "magic split" (i.e. different strings for "Undo %1" and QUndoView): 1. "\n" will be used as separator instead of "|-|". 2. Before using this new feature, translators will need to wait until KDE SC (or other software you translate) depends on Qt 4.8 (which hasn't been released yet, by the way). -- Alexander Potashev
Re: Review Request: Add message contexts "@title:window" to all window and dialog titles
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101299/#review3226 --- Review request timed out. kde-baseapps compiles after these changes. - Alexander On May 6, 2011, midnight, Alexander Potashev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101299/ > --- > > (Updated May 6, 2011, midnight) > > > Review request for KDE Base Apps. > > > Summary > --- > > Context strings added to 106 strings. > > > Diffs > - > > kdepasswd/kcm/chfacedlg.cpp 9fb8ab3 > kdepasswd/passwddlg.cpp 27af7ee > kdialog/kdialog.cpp b80ad9a > keditbookmarks/actionsimpl.cpp 1a7e22e > keditbookmarks/importers.cpp 777d8a5 > keditbookmarks/main.cpp bd3cccd > kfind/kfinddlg.cpp 28b6044 > kfind/kfindtreeview.cpp c9fe034 > kfind/kquery.cpp 8d67fab > konq-plugins/adblock/adblock.cpp c2128d3 > konq-plugins/adblock/adblockdialog.cpp f5357eb > konq-plugins/akregator/pluginbase.cpp a88ca0f > konq-plugins/autorefresh/autorefresh.cpp 57286b1 > konq-plugins/babelfish/plugin_babelfish.cpp 90bb16d > konq-plugins/domtreeviewer/domtreeview.cpp e648d29 > konq-plugins/domtreeviewer/domtreewindow.cpp edab063 > konq-plugins/khtmlsettingsplugin/settingsplugin.cpp a9414ca > konq-plugins/kimgalleryplugin/imgallerydialog.cpp 61a68cb > konq-plugins/kttsplugin/khtmlkttsd.cpp eaaee25 > konq-plugins/shellcmdplugin/kshellcmdplugin.cpp 0bf58c3 > konq-plugins/validators/plugin_validators.cpp e80696d > konq-plugins/validators/reportdialog.cpp b40f82f > konq-plugins/validators/validatorsdialog.cpp 72bfb2c > konq-plugins/webarchiver/archivedialog.cpp 07e1d1e > konq-plugins/webarchiver/plugin_webarchiver.cpp fa3422b > konqueror/about/konq_aboutpage.cc 052b35d > konqueror/settings/kio/kcookiespolicies.cpp 23d1a31 > konqueror/settings/kio/kenvvarproxydlg.cpp c0086d4 > konqueror/settings/kio/kmanualproxydlg.cpp 17a1944 > konqueror/settings/kio/kproxydlg.cpp c611dfa > konqueror/settings/kio/ksaveioconfig.cpp 8d4d18f > konqueror/settings/kio/useragentdlg.cpp ff6a176 > konqueror/settings/konq/kcustommenueditor.cpp 39192ba > konqueror/settings/konqhtml/generalopts.cpp 1ccd6c8 > konqueror/settings/konqhtml/javaopts.cpp 7120766 > konqueror/settings/konqhtml/jsopts.cpp 3166126 > konqueror/settings/konqhtml/pluginopts.cpp 366a885 > konqueror/sidebar/history_module/kcmhistory.cpp 6e22423 > konqueror/sidebar/sidebar_widget.cpp 9475fa7 > konqueror/sidebar/trees/bookmark_module/bookmark_module.h 4403ce7 > konqueror/sidebar/trees/bookmark_module/bookmark_module.cpp e39f2b4 > konqueror/sidebar/trees/konq_sidebartree.cpp 40bd4a5 > konqueror/sidebar/web_module/web_module.cpp 4663e56 > konqueror/src/konqextensionmanager.cpp f9f231b > konqueror/src/konqhistoryview.cpp 2b1e192 > konqueror/src/konqmainwindow.cpp 1054569 > konqueror/src/konqprofiledlg.cpp c968abc > konqueror/src/konqsessiondlg.cpp 274fd5c > konqueror/src/konqsessionmanager.cpp e31156e > konqueror/src/konqview.cpp 16c9d29 > konqueror/src/konqviewmanager.cpp a4dd00f > lib/konq/konq_operations.cpp afefeef > > Diff: http://git.reviewboard.kde.org/r/101299/diff > > > Testing > --- > > > Thanks, > > Alexander > >
Review Request: remove functions *Command::name() which are not used
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101343/ --- Review request for KDE Base Apps and David Faure. Summary --- konq-plugins/domtreeviewer builds without there functions. May be these functions were left for future integration of domtreeviewer undoable commands' into Konqueror's undo stack. But for now, they only add a few translatable strings the user won't ever see. Diffs - konq-plugins/domtreeviewer/domtreecommands.h df8272e konq-plugins/domtreeviewer/domtreecommands.cpp e4c7fff Diff: http://git.reviewboard.kde.org/r/101343/diff Testing --- konq-plugins/domtreeviewer compiles after this change. Thanks, Alexander
Re: Review Request: kcm-grub2
2011/5/25 Konstantinos Smanis :
> Any updates? The two week review period is over.
The following line should probably be simplified (see
http://websvn.kde.org/?revision=1184860&view=revision):
src/kcm_grub2.cpp:113:QTreeWidgetItem *item = new
QTreeWidgetItem(ui.treeWidget_recover, QStringList(QString()) << name
<< partition->filePath() << volume->label() << volume->fsType() <<
i18n("%1 GiB", QString::number(volume->size() / 1073741824)));
P.S.: I've fixed ellipsises:
http://commits.kde.org/kcm-grub2/bbc14f81c533e3b92799c1da90f535ba9f887180
--
Alexander Potashev
playground-libs/libkvkontakte has moved to kdereview
Hi, playground-libs/libkvkontakte moved to kdereview today. The next target for this project is extragear/libs. This project is a library for interaction with the most popular social network in Russia VKontakte.ru (also available at vk.com) using its public API documented at http://vkontakte.ru/pages.php?o=-1&p=Документация (only in Russian). libkvkontakte is already being used by playground-pim/akonadi-vkontakte and the KIPI export plugin for VKontakte which will be hopefully released with digiKam SC 2.1.0 in September. Some parts of code in libkvkontakte are based on playground-pim/akonadi-facebook written by Thomas McGuire and others. Please, review. Thanks. -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/9 Christoph Feck : > It doesn't compile because asserts reference undeclared variables. > Attached patch shows where the errors are. I've applied your patch to authenticationdialog.cpp and reworked error reporting in allnoteslistjob.cpp and also in allmessageslistjob.cpp. Thanks! -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/15 Albert Astals Cid : > You do not use d pointers in any of your classes thus maintaining Binary > Compatibility is going to be almost impossible if you need to expand them. How about adding a "QMap m_ext;" to *Info classes, so that I can store additional variables there? Most (but not all) *Job classes are unlikely to be expanded later, because they perform very simple operations. If I'll add just a forward declaration like "class NoteInfoPrivate;" and a "NoteInfoPrivate *p;" into the NoteInfo class, will it be OK? > I'd also like if you used KCatalogLoader to load your translation catalog. Done. -- Alexander Potashev
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/15 Albert Astals Cid : > A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure: >> How about adding a "QMap m_ext;" to *Info classes, >> so that I can store additional variables there? Most (but not all) >> *Job classes are unlikely to be expanded later, because they perform >> very simple operations. > > Why not simply use a d-pointer like it is explained in techbase? I thought about "QMap" as of an easier solution since you won't need to declare the NoteInfoPrivate class. >> If I'll add just a forward declaration like "class NoteInfoPrivate;" >> and a "NoteInfoPrivate *p;" into the NoteInfo class, will it be OK? > > I guess you mean using a d-pointer, yes, that's the suggested way of dealing > with this kind of issue. So, the NoteInfoPrivate class may not have any declaration (except for the forward declaration) until it will be necessary, right? -- Alexander Potashev
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/17 Alexander Potashev : > So, the NoteInfoPrivate class may not have any declaration (except for > the forward declaration) until it will be necessary, right? There is "Q_DECLARE_PRIVATE" macro, interesting... Should I use it instead? -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/17 Thomas Zander : > Most C++ libraries use this, but I suggest to take a look at kdelibs for > inspiration. Implementation of p-pointers not always the same in the whole kdelibs. I preferred not to use neither Q_DECLARE_PRIVATE nor inheritance of *Private classes (as described at http://techbase.kde.org/Policies/Library_Code_Policy/Shared_D-Pointer_Example). You can check what I've done: http://commits.kde.org/libkvkontakte/094b12d2e2f2b6c73e3721607a909079722f93a2 I still need to polish the code before "freezing" the ABI, for example I'm planning to remove a couple of classes. -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/9 Alexander Potashev : > playground-libs/libkvkontakte moved to kdereview today. The next > target for this project is extragear/libs. "libkvkontakte" has been in kdereview for more than two weeks already. Is it OK to move it into extragear-libs now? -- Alexander Potashev
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/25 Albert Astals Cid :
> I thought you were going to get rid of the private members and use a d-pointer
> instead?
What is the point of this? I think it will be OK to keep all class
members in the main ("public") classes and use d-ptr only in case of
real necessity.
--
Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/25 Albert Astals Cid : > The point is that usually you do not know what the library will end up doing > and by using d-pointers everywhere you make it easier for yourself to maintain > binary compatibility in the future. But in the case that most classes won't grow in the future by using my strategy (keeping d-ptr NULL when possible) we cut down the number of memory allocations, and also simplify the existing code that doesn't work with the private class' data. So, I'm going to keep following the current strategy. -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/26 David Faure : > A last argument, code is easier to maintain if it follows the same rules > everywhere. So in all "public library" code (Qt, kdelibs, and all other public > libs) we should do things the same way, to ease maintainance. This argument wins. Just give me a couple of days to get to changing all classes to "data only in private class" strategy. Don't know what to do with classes like UserInfo, NoteInfo, MessageInfo, etc. -- Alexander Potashev
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/29 Albert Astals Cid : > What's special in those classes? Well, nothing, nevermind ;) They are just much simpler than the *Job classes. -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/26 Alexander Potashev : > This argument wins. Just give me a couple of days to get to changing > all classes to "data only in private class" strategy. Done. -- Alexander Potashev
Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/29 Alexander Potashev : > 2011/8/26 Alexander Potashev : >> This argument wins. Just give me a couple of days to get to changing >> all classes to "data only in private class" strategy. > > Done. Is everything OK now to move into extragear/libs? Or I can release libkvkontakte from kdereview? -- Alexander Potashev
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/9/2 Albert Astals Cid : > Personally i prefer things not to be released from kdereview. Gilles Caulier (digiKam and KIPI-Plugins maintainer) told me that the tarball for KIPI-Plugins 2.1.0 will probably be created tomorrow. Therefore I hope to release libkvkontakte also tomorrow. Should now this library be moved to extragear/libs or playground/libs? -- Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/9/4 Albert Astals Cid : > Seems everyone was happy with review so move it to extragear? Anyway i prefer > things not to be released from playground either (yes i know lots of people do > it, that's why it is my personal opinion) so if you can not get it to be moved > or prefer to stay in kdereview a bit more please do not let my personal > opinion block you from doing a release. I've already decided that libkvkontakte will be released (i.e. tarball-ed) today as part of digiKam SC, because otherwise we either need to remove the VKontakte export plugin from kipi-plugins or release libkvkontakte later in a separate tarball making life harder for packagers. -- Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/9/4 Albert Astals Cid : > Seems everyone was happy with review so move it to extragear? Anyway i prefer > things not to be released from playground either (yes i know lots of people do > it, that's why it is my personal opinion) so if you can not get it to be moved > or prefer to stay in kdereview a bit more please do not let my personal > opinion block you from doing a release. digiKam SC 2.1.0 was released yesterday with libkvkontakte 1.0.0. I'll now request move of this library to extragear/libs. -- Alexander Potashev
Re: Review Request: optimize kcolorscheme consting time: avoid calculating luma for the same colors multiple times
> On Dec. 6, 2011, 5:58 p.m., Nick Shaforostoff wrote: > > I have an account called shaforo. i could push to kdepimlibs with it, but i > > couldn't push to kdelibs. is it because of lack of permissions? You need to clone the `kdelibs` repo from `g...@git.kde.org:kdelibs.git`. Check this in `kdelibs/.git/config` on your machine. - Alexander --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103348/#review8762 --- On Dec. 6, 2011, 5:53 p.m., Nick Shaforostoff wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103348/ > --- > > (Updated Dec. 6, 2011, 5:53 p.m.) > > > Review request for kdelibs. > > > Description > --- > > pretty straightforward and small optimization of kde apps startup time: > avoid calculating luma for the same colors multiple times. > > callgrind shows it is called 4503 times > instead of 12087 at startup of kwrite, which is 1.5%. > > > Diffs > - > > kdeui/colors/kcolorutils.cpp efe8cdd > > Diff: http://git.reviewboard.kde.org/r/103348/diff/diff > > > Testing > --- > > kwrite starts fine with the new kdeui lib > > > Thanks, > > Nick Shaforostoff > >
Re: Policy regarding QtWebKit and QtScript
2015-12-22 20:21 GMT+03:00 Ivan Čukić : > As for QtScript, I see two approaches: > - kross (what is the state of it?) > - qml engines Hi Ivan, I don't get what you are suggesting. QtScript support in Kross depends on Qt's QtScript. -- Alexander Potashev
Re: Product versions on bugs.kde.org
2016-03-09 1:09 GMT+03:00 Kevin Funk : > Added all versions from 5.5.0 to 5.19.0. > > I've used this little gem here to "hammer" BKO: > http://paste.ubuntu.com/15330672/ This was a wrong thing to do because e.g. bluez-qt did not have releases 5.5.0 through 5.10.0. -- Alexander Potashev
Re: Product versions on bugs.kde.org
2016-03-09 1:40 GMT+03:00 Kevin Funk : > On Wednesday, March 9, 2016 1:27:47 AM CET Alexander Potashev wrote: >> 2016-03-09 1:09 GMT+03:00 Kevin Funk : >> > Added all versions from 5.5.0 to 5.19.0. >> > >> > I've used this little gem here to "hammer" BKO: >> > http://paste.ubuntu.com/15330672/ >> >> This was a wrong thing to do because e.g. bluez-qt did not have >> releases 5.5.0 through 5.10.0. > > Fixed. If you know of other frameworks where this is the case, feel free to > fix them via the web UI. Thanks Kevin! I felt free and did the following: 1. Removed frameworks-package-5.5.0- [1]. 2. Removed frameworks-networkmanager-qt-5.5.0- [1], keeping frameworks-networkmanager-qt-5.1.2- because those versions also existed, but as part of Plasma. 3. Removed frameworks-kxmlrpcclient-5.7.0- [2]. 4. Removed frameworks-modemmanager-qt-5.8.0- [3], keeping frameworks-modemmanager-qt-5.2.2- because those versions also existed, but as part of Plasma. 5. Created product frameworks-kpeople and added versions 5.8.0+ [2]. Moved relevant bugs from the old product "kpeople". 6. Created product frameworks-kfilemetadata and added versions 5.13.0+ [4]. 7. Created product frameworks-baloo and added versions 5.13.0+ [4]. Bugs for older, out-of-KF5 versions go into the "Baloo" product. 8. Added product "BalooWidgets", it's part of KDE Applications. Moved relevant bugs from the "Baloo" product. 9. Added product "Baloo KCM", it's part of Plasma (plasma-desktop.git/kcms/baloo). Moved relevant bugs from the "Baloo" product. I guess now the products "kpeople" and "Baloo" can be obsoleted in Bugzilla. If the above looks good, please add the product "Baloo KCM" into releaseme.git/plasma/plasma-add-bugzilla-versions. [1] https://www.kde.org/announcements/kde-frameworks-5.6.0.php [2] https://www.kde.org/announcements/kde-frameworks-5.8.0.php [3] https://www.kde.org/announcements/kde-frameworks-5.9.0.php [4] https://www.kde.org/announcements/kde-frameworks-5.13.0.php -- Alexander Potashev
Re: Product versions on bugs.kde.org
2016-03-12 22:38 GMT+03:00 Vishesh Handa : > In the future, I would appreciate it if such decisions were run by the > maintainer. I now have more work since my existing filters and > bookmarks are now invalid. And the documentation which tells where to > file a bug. Hi Vishesh, Sorry for not asking you in advance. I just wanted to beatify the frameworks-* products while I'm at it. Let me explain how I came up with tthe new Baloo products in Bugzilla and why it seems to me like a trivial decision: 1. Because the Baloo core (libKF5Baloo*.so, balooctl, etc) is part of KF5, the Bugzilla product for it should be called consistently: "frameworks-baloo". 2. We already had some bugs against baloo-5.13.0+, so I moved them into "frameworks-baloo". 3. The old product "Baloo" should be obsoleted because otherwise it will be hard for users to decide if they need to report bugs against "Baloo" or "frameworks-baloo". 4. If we obsolete the "Baloo" product, we need to have other products to let users report Baloo-related bugs. For KF5::Baloo we already have "frameworks-baloo", and besides it we have 3 UIs to Baloo: krunner, KCM "File Search" and baloo-widgets. 4a. For the Baloo runner we already have the component "filesearch" of the "krunner" product in Bugzilla. 4b. Regarding KCM... I thought there was no umbrella product for KCMs, but actually we have "systemsettings/kcm_[...]" components, and systemsettings/kcm_baloo seems to be the best place for Baloo KCM. Nice catch! 4c. For baloo-widgets we also need another product because it does not fit any existing products. After we obsolete the Bugzilla product "Baloo", you won't need to look inside it anymore because all the bugs remaining in that product have been reported against old versions of Baloo and therefore can all be marked as UNMAINTAINED. -- Alexander Potashev
Re: [kde-community] Sunsetting of Infrastructure and the Phabricator migration
Hi Ben, Please find my questions below. 2016-03-18 9:46 GMT+03:00 Ben Cooksley : > The XML file upon which numerous utilities (including kdesrc-build) > depend will continue to be made available. It will instead be > generated by a Python script periodically, based on the contents of a > Git repository. How do we change i18n branches in this XML file after disabling projects.kde.org? > I should also note that as a side affect of the Phabricator > transition, scratch/clone repositories will to a certain extent cease > to exist - everything will now be a mainline repository. As a Do I get it right that it will be impossible to create a scratch repository for a 30-minute task or for a proof-of-concept application without asking the "majors"? I think it's totally fine because there are many other Git hostings where you can do quick-and-dirty development from scratch. And you can move your repo to git.kde.org as soon as it matures. The main pros of this approach would be a cleaner quickgit.kde.org page and of course saving of disk space on servers. -- Alexander Potashev
Re: Product versions on bugs.kde.org
Hi Vishesh, Please find my comments below. 2016-03-16 23:40 GMT+03:00 Vishesh Handa : > On Sun, Mar 13, 2016 at 7:57 PM, David Faure wrote: >> So I think frameworks-baloo makes sense (and is consistent). The "users" >> of the framework are application developers, who know how to find it in >> bugzilla. > > Except that Baloo isn't just a library. It provides a daemon, and a > CLI search interface. I also know a few people running Baloo on > servers. These executables are part of KF5. I've just changed the description for this product to "Baloo is responsible for File Searching and Indexing. This framework includes balooctl, balooshow, baloosearch, baloo_file, baloo_file_extractor, etc.", now it should be clear to users where to report bugs [1]. > This whole "frameworks-baloo" vs "baloo" seems more pedantic than > anything else. Specially considering the amount of overhead this is > actively causing. I just have a crash report from 2 hours ago filed to > Baloo (not Baloo-frameworks). Bug reports against previous versions of > Baloo won't automatically go to this new "baloo-frameworks". And I > have over 130+ new bug emails, which aren't relevant. The incident from 2 hours earlier you mentioned will not be possible after closing the "Baloo" product. Are we ready for this? By 130+ bug emails do you mean automated emails from Bugzilla or people reporting bugs to you in private emails? [1] https://bugs.kde.org/enter_bug.cgi?format=guided -- Alexander Potashev
Re: Product versions on bugs.kde.org
2016-03-09 1:09 GMT+03:00 Kevin Funk : > Added all versions from 5.5.0 to 5.19.0. 5.20.0 is out, could you please add it to Bugzilla as well? -- Alexander Potashev
Re: KDE Frameworks 5.21.0 released
2016-04-09 17:36 GMT+03:00 David Faure : > 09th April 2016. KDE today announces the release of KDE Frameworks 5.21.0. Hi David, You forgot to mention a new framework in 5.21.0: KActivitiesStats. -- Alexander Potashev
Review Request 128214: Do not use C-style casts into void*
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128214/ --- Review request for kdelibs. Bugs: 325055 http://bugs.kde.org/show_bug.cgi?id=325055 Repository: kdelibs Description --- See also the respective commit in kross.git. BUG: 325055 Diffs - kross/core/metatype.h 08f7c6cecb9e374e97ebbcddc5528b5c71b72b97 Diff: https://git.reviewboard.kde.org/r/128214/diff/ Testing --- Thanks, Alexander Potashev
Re: Review Request 128214: Do not use C-style casts into void*
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128214/ --- (Updated Июнь 17, 2016, 12:32 д.п.) Status -- This change has been marked as submitted. Review request for kdelibs. Bugs: 325055 http://bugs.kde.org/show_bug.cgi?id=325055 Repository: kdelibs Description --- See also the respective commit in kross.git. BUG: 325055 Diffs - kross/core/metatype.h 08f7c6cecb9e374e97ebbcddc5528b5c71b72b97 Diff: https://git.reviewboard.kde.org/r/128214/diff/ Testing --- Thanks, Alexander Potashev
Re: liquidshell in kdereview
Hi, thanks for the good stuff.
Tried to build it here against relatively old Qt version, failed at
first attempt and had to do some tweaks (see attachment).
OS: gentoo
gcc 5.4.0
Qt 5.7.1
KF 5.37.0
2017-11-03 23:30 GMT+03:00 Martin Koller :
> Hi all,
>
> I'd like to announce an application I've implemented over the last few weeks
> - liquidshell
>
> liquidshell is a replacement for plasmashell
>
> It does not use QtQuick but instead relies on QtWidgets,
> therefore no hardware graphics acceleration is needed.
>
> Main Features:
> - Wallpaper per virtual desktop
> - No animations, no CPU hogging, low Memory footprint
> - Instant startup
> - No use of activities (I never used nor needed them)
> - QtWidgets based, therefore follows widget style from systemsettings
> - Icons are used from your globally defined icon theme from systemsettings
> - Colors are used from your globally defined color theme from systemsettings
> - Can additionally be styled with css by passing the commandline option
> -stylesheet filename.css
> (see included example stylesheet.css)
> - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual
> Desktops, Bluetooth, Network
> - Just one bottom DesktopPanel, containing:
> StartMenu (allowing drag of entries into konqueror/dolphin to configure
> QuickLaunch or AppMenu entries)
> QuickLaunch (showing icons for .desktop files from a configurable folder)
> AppMenu (showing .desktop files in a menu from a configurable folder,
> defaults to users desktop folder)
> Pager (for switching virtual desktops)
> WindowList (Popup showing all open windows on all desktops)
> TaskBar (showing windows on the current desktop, allowing drag of an entry
> onto the Pager to move to a different desktop)
> LockLogout
> SysLoad widget including CPU, Memory, Swap and Network bars, live updated
> tooltip
> SysTray with integrated Network-, Notifications-, Device Notifier-,
> Bluetooth-, Battery- display.
> Display of StatusNotifier items from other applications (no legacy
> embedded icons yet).
> Notifications kept in a history list for some minutes, including
> timestamp and text selectable per mouse
> (very handy for copy/paste of TAC numbers from online banking received
> via SMS and transferred to KDE
>via kdeconnect)
> Clock widget (with calendar popup, tooltip for selected cities)
> - Desktop can contain applets (there's currently only a weather applet)
>
> The main motivation was to have a reliable desktop shell which does not hog
> the CPU or RAM.
> (CPU usage and stability were the things driving me mad with plasmashell)
> It should be slick and have just the features I need in my daily
> work. No need having all the bells and whistles anyone can think of.
> Just have a plain, solid, fast workhorse.
>
> I think the final place should be extragear.
>
> Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory
> are already in place
> and ready to be installed.
>
> Screenshots:
> light color theme:
> http://members.aon.at/m.koller/liquidshell_20171103_174650.png
> dark color theme:
> http://members.aon.at/m.koller/liquidshell_20171103_174944.png
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
>
>
--
Alexander Potashev
diff --git a/Battery.cxx b/Battery.cxx
index cc9b6fc..01dda67 100644
--- a/Battery.cxx
+++ b/Battery.cxx
@@ -22,7 +22,7 @@
#include
#include
-#include
+//#include
#include
#include
@@ -49,7 +49,7 @@ Battery::Battery(QWidget *parent)
hide();
else
{
-connect(Solid::Power::self(), &Solid::Power::acPluggedChanged, this,
&Battery::changed);
+///connect(Solid::Power::self(), &Solid::Power::acPluggedChanged, this,
&Battery::changed);
connect(device.as(),
&Solid::Battery::chargePercentChanged, this, &Battery::changed);
connect(device.as(), &Solid::Battery::chargeStateChanged,
this, &Battery::changed);
connect(device.as(), &Solid::Battery::timeToFullChanged,
this, &Battery::changed);
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7077710..1cabcfa 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -16,7 +16,7 @@ find_package(Qt5 5.7 CONFIG REQUIRED COMPONENTS
find_package(KF5 REQUIRED COMPONENTS
WindowSystem WidgetsAddons ConfigWidgets Config KIO IconThemes
ItemViews Archive
- Notifications I18n NetworkManagerQt Service Solid BluezQt
KCMUtils Cra
Re: liquidshell in kdereview
2017-11-06 14:16 GMT+03:00 Kevin Funk : > You're free to work on whatever you like to of course, but to me this sounds > like wasted effort. Your good incentives would be better spent with joining up > with others aiming for the same (LxQt for instance). Hi, I had a bad impression of LxQt because: 1. it didn't work for me out of the box, 2. it consists of many components, it's hard to figure out which of them are optional, 3. it has poor infrastructure compared to KDE, e.g. their i18n server hadn't been working for about a year. Thus liquidshell looks better to me than lxqt; joining an inferior project is not a good idea. -- Alexander Potashev
Re: Review Request 101343: remove functions *Command::name() which are not used
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/101343/ --- (Updated Dec. 24, 2018, 12:03 p.m.) Status -- This change has been discarded. Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- konq-plugins/domtreeviewer builds without there functions. May be these functions were left for future integration of domtreeviewer undoable commands' into Konqueror's undo stack. But for now, they only add a few translatable strings the user won't ever see. Diffs - konq-plugins/domtreeviewer/domtreecommands.h df8272e konq-plugins/domtreeviewer/domtreecommands.cpp e4c7fff Diff: https://git.reviewboard.kde.org/r/101343/diff/1/ Testing --- konq-plugins/domtreeviewer compiles after this change. Thanks, Alexander Potashev
Re: Review Request 101343: remove functions *Command::name() which are not used
> On Feb. 16, 2014, 9:12 p.m., Albert Astals Cid wrote: > > Alexander, did you see David's comment? Do you plan to implement what he > > suggests? Hi, I think Konqueror is kind of unstable for now, and Chromium is a good enough alternative, thus will not spend more time on this. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/101343/#review49935 --- On May 12, 2011, 10:55 a.m., Alexander Potashev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/101343/ > --- > > (Updated May 12, 2011, 10:55 a.m.) > > > Review request for KDE Base Apps and David Faure. > > > Repository: kde-baseapps > > > Description > --- > > konq-plugins/domtreeviewer builds without there functions. > > May be these functions were left for future integration of domtreeviewer > undoable commands' into Konqueror's undo stack. But for now, they only add a > few translatable strings the user won't ever see. > > > Diffs > - > > konq-plugins/domtreeviewer/domtreecommands.h df8272e > konq-plugins/domtreeviewer/domtreecommands.cpp e4c7fff > > > Diff: https://git.reviewboard.kde.org/r/101343/diff/1/ > > > Testing > --- > > konq-plugins/domtreeviewer compiles after this change. > > > Thanks, > > Alexander Potashev > >
Re: Tipping the apple cart?
вт, 2 июл. 2019 г. в 14:07, Ben Cooksley : > > On Tue, Jul 2, 2019 at 6:42 PM Boudewijn Rempt wrote: > > Try opening the changes tab for > > https://invent.kde.org/kde/krita/merge_requests/54. This makes my browser > > warn me two or three times that the page is using a lot of CPU and it takes > > ages before it succeeds. > > I opened this just now on my system and it gave me no issues (using > both Google Chrome and Firefox). > > It did take a little while to open (around 20 seconds or so from the > moment I hit refresh), but that's to be expected given it is a review > spanning 509 files, with circa 14,500 additions and 7,000 removals, Hi Ben, We discussed GitLab performance a few months ago on kde-devel mailing list, then the discussion stopped. You can re-read it below. I believe all my statements there are still valid, and I still believe 20 seconds of loading time is very painful. = = вс, 24 февр. 2019 г. в 00:47, Ben Cooksley : > > On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev > wrote: > > > > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley : > > > Based on all of the above we'd like to propose migrating towards > > > Gitlab. Comments? > > > > Hi, > > Hi Alexander, > > > > > 1. We migrated from github.com to self-hosted GitLab when I worked > > full-time in a team of 4 developers. A major drawback we noticed back > > then was slow page loading when browsing a large diff (e.g. in a merge > > request). For example, this commit takes around 15 seconds to load: > > https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 > > That commit is massive and is far beyond what would be routine for a > project to commit, so I think it's quite reasonable for the system to > take a bit of time to process it. > Loading that page right now using the web inspector shows it takes > about 8 seconds to generate, followed by a further 4 seconds to > download, which doesn't seem unreasonable for 3200 lines of changes, > plus context, over 187 files - especially given it syntax highlights > it. Hi Ben, The thing is, it's much slower than github - that's why we noticed the issue. I'm not sure if GitLab is slower than Phabricator, but at least it tries to feel fast and loads the whole diff incrementally, so that the first portion is available in less than 1 second. For reference, here is that same commit in 4 different web UIs: - https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 - https://github.com/KDE/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533 - https://phabricator.kde.org/R158:aadd9305b0467fa39e5c84af606c7d9eb1568533?show_all=true - https://cgit.kde.org/kdenlive.git/commit/?id=aadd9305b0467fa39e5c84af606c7d9eb1568533 (cgit also has syntax highlighting :)) You are right merge requests as large as this commit are not common, but 1. Once you have a large merge request, maintainers will probably spend some days reviewing it and may be open the same diff page many times, thus multiplying the suffering. 2. Diffs that are 10x smaller that this one are common, and a 1.5 second loading time (15s / 10 = 1.5s) is still not very comfortable. 3. A merge request may comprise multiple commits (e.g. 20 commits) and it's handy to browse/review a squashed diff for the whole merge request, making the diff 20 times longer that an average commit diff. Reviewing of multi-commit merge requests is also available on GitHub, and it's still fast there unlike GitLab. -- Alexander Potashev
Re: Quick Charts in KDE Review
Hi Arjen, 1. I don't see any checks in the autotests. Would it be easy to compare the displayed chart against a reference screenshot image, in each of the tests? The same screenshots could also help developers understand what kind of charts kquickcharts is good for. 2. How to add a grid, ticks and labels to a line chart? пн, 21 окт. 2019 г. в 16:46, Arjen Hiemstra : > > On 21-10-2019 15:22, Arjen Hiemstra wrote: > > Hi, > > > > Quick Charts has been moved to KDE review. The intent is to make it a > > Tier 1 framework. > > > > Quick Charts is a QML module that implements a set of > > high-performance, GPU accelerated > > charts. Currently the main user of it is a new KSysGuard UI I have > > been working on, but > > once it is part of Frameworks I also hope to convert several bits of > > Plasma to using it. > > And of course, a link would be useful: > > https://invent.kde.org/kde/kquickcharts > > > > > - Arjen -- Alexander Potashev
Re: Quick Charts in KDE Review
чт, 7 нояб. 2019 г. в 13:53, Arjen Hiemstra : > > On 21-10-2019 15:22, Arjen Hiemstra wrote: > > Hi, > > > > Quick Charts has been moved to KDE review. The intent is to make it a > > Tier 1 framework. > > > > Quick Charts is a QML module that implements a set of > > high-performance, GPU accelerated > > charts. Currently the main user of it is a new KSysGuard UI I have > > been working on, but > > once it is part of Frameworks I also hope to convert several bits of > > Plasma to using it. > > It has now been a little over two weeks. If there are no objections, I > will move this to frameworks later today. Hi Arjen, Did anyone from the Plasma team approve the new KSysGuard UI? -- Alexander Potashev
Re: plasma-nano and plasma-phone-components are now in kdereview
пт, 8 нояб. 2019 г. в 10:10, Bhushan Shah : > > Hello! > > plasma-nano: https://invent.kde.org/kde/plasma-nano Hi, 1. Messages.sh files do not extract from ./shell/* 2. There is a Messages.sh file under "./components", however there is nothing to extract from that directory. Looks like the "components" component is designed not to have any translatable messages. > plasma-phone-components: https://invent.kde.org/kde/plasma-phone-components I looked for missing Messages.sh files here as well, found it missing from at least ./containments/panel/* -- Alexander Potashev
KTimeTracker in kdereview
Hi, KTimeTracker [1] has been moved to kdereview. KTimeTracker is a time tracker desktop application which is well suited for tracking labor time you spend on a specific project/feature/customer. Its latest release was made on 2015-07-01 as part of KDE PIM 4.14.10. Since then I ported KTimeTracker to Qt5/KF5, did a lot of refactoring and reworked some dialogs. The major changes since 4.14.10 are listed in [2]. KDE CI is set up at [3]. The project is currently in playground-pim, destination would be extragear-pim. [1] https://cgit.kde.org/ktimetracker.git [2] https://cgit.kde.org/ktimetracker.git/tree/ChangeLog.md [3] https://build.kde.org/job/Extragear/job/ktimetracker/ -- Alexander Potashev
Re: KTimeTracker in kdereview
вт, 19 нояб. 2019 г. в 11:44, Friedrich W. H. Kossebau : > > Am Dienstag, 19. November 2019, 05:20:23 CET schrieb Alexander Potashev: > > Hi, > > > > KTimeTracker [1] has been moved to kdereview. > > Did some favourite-nitpicks review comments as direct fixes. Thanks! > You want to instruct the Messages.sh to just care for the src/ subdir, and > there also exclude the test/ subdir (just in case and to speed up execution). > Possibly first part can best be handled by moving Messages.sh into the src/ > subdir. Moved Messages.sh into src/, it's enough for now IMO. -- Alexander Potashev
Re: plasma-nano and plasma-phone-components are now in kdereview
пт, 8 нояб. 2019 г. в 10:10, Bhushan Shah : > plasma-nano: https://invent.kde.org/kde/plasma-nano Scripty (i18n daemon) fails to push to plasma-nano.git, find this in https://logs.l10n.kde.org/191122.trunk_l10n-kf5: remote: FATAL: W refs/heads/master plasma-nano scripty DENIED by refs/.* remote: error: hook declined to update refs/heads/master To ssh://g...@git.kde.org/plasma-nano.git ! [remote rejected] HEAD -> master (hook declined) error: failed to push some refs to 'ssh://g...@git.kde.org/plasma-nano.git' ERROR: commiting .desktop files failed for module kdereview_plasma-nano! May be some repo-specific configuration issue because the same procedure works for plasma-phone-components, see for example https://invent.kde.org/kde/plasma-phone-components/commit/78ce66807139cadfbe9e45b79e79729fc04ceb51 -- Alexander Potashev
Re: KTimeTracker in kdereview
вт, 26 нояб. 2019 г. в 00:31, Albert Astals Cid : > > El dimarts, 19 de novembre de 2019, a les 5:20:23 CET, Alexander Potashev va > escriure: > > Hi, > > > > KTimeTracker [1] has been moved to kdereview. > > > > KTimeTracker is a time tracker desktop application which is well > > suited for tracking labor time you spend on a specific > > project/feature/customer. > > > > Its latest release was made on 2015-07-01 as part of KDE PIM 4.14.10. > > Since then I ported KTimeTracker to Qt5/KF5, did a lot of refactoring > > and reworked some dialogs. The major changes since 4.14.10 are listed > > in [2]. > > > > KDE CI is set up at [3]. > > > > The project is currently in playground-pim, destination would be > > extragear-pim. > > clang-tidy says that desktops in Task::Task and sessionStartTiMe in > Task::init should be const & Fixed these [1], however I wasn't able to run clang-tidy myself to get the same hints. Tried clang-tidy features in KDevelop and JetBrains' CLion. Thanks Albert! [1] https://commits.kde.org/ktimetracker/7928253e26d6f6eb2dfe6256fe2cf15fcf9225e4 -- Alexander Potashev
Re: KTimeTracker in kdereview
вс, 1 дек. 2019 г. в 19:43, Albert Astals Cid : > > El diumenge, 1 de desembre de 2019, a les 13:09:30 CET, Alexander Potashev va > escriure: > > > clang-tidy says that desktops in Task::Task and sessionStartTiMe in > > > Task::init should be const & > > > > Fixed these [1], however I wasn't able to run clang-tidy myself to get > > the same hints. Tried clang-tidy features in KDevelop and JetBrains' > > CLion. > > clang-tidy has a million checks and almost none are enabled by default (i > think) > > What i do is enable the performance ones manually, i.e. for example this is > what we have in the poppler CI > > cmake > -DCMAKE_CXX_CLANG_TIDY="clang-tidy;-header-filter=.;-checks=-*,performance-*,bugprone-*,readability-inconsistent-declaration-parameter-name,readability-string-compare,modernize-deprecated-headers,-bugprone-narrowing-conversions,-bugprone-macro-parentheses,-bugprone-suspicious-string-compare,-bugprone-incorrect-roundings,-bugprone-undefined-memory-manipulation;-warnings-as-errors=*" > .. > > But this will probably give you lots of errors you don't want, you have to > figure out which are th eones you care about. Thanks! I managed to get that million of warnings by following this tutorial: http://mariobadr.com/using-clang-tidy-with-cmake-36.html Fixed some more, however some others would be nearly useless nitpicking. -- Alexander Potashev
Re: KTimeTracker in kdereview
вт, 19 нояб. 2019 г. в 07:20, Alexander Potashev : > KTimeTracker [1] has been moved to kdereview. > > The project is currently in playground-pim, destination would be > extragear-pim. KTimeTracker had been in kdereview for two weeks already. It is enough to assume everything is OK and we can move it to final destination (extragear-pim), according to https://community.kde.org/Policies/Application_Lifecycle#Releasing If no one objects, I will request the move to extragear-pim tomorrow. -- Alexander Potashev
Re: KTimeTracker in kdereview
Moved to extragear-pim. @Luigi, please move the translations. вт, 3 дек. 2019 г. в 13:45, Alexander Potashev : > > вт, 19 нояб. 2019 г. в 07:20, Alexander Potashev : > > KTimeTracker [1] has been moved to kdereview. > > > > The project is currently in playground-pim, destination would be > > extragear-pim. > > KTimeTracker had been in kdereview for two weeks already. It is enough > to assume everything is OK and we can move it to final destination > (extragear-pim), according to > https://community.kde.org/Policies/Application_Lifecycle#Releasing > > If no one objects, I will request the move to extragear-pim tomorrow. > > -- > Alexander Potashev -- Alexander Potashev
Re: plasma-nano and plasma-phone-components are now in kdereview
Hi Jonathan, Are you saying that Plasma 5.18 LTS will be a subset of Plasma 5.18? If so, we definitely need to notify l10n coordinators (kde-i18n-doc) and mention in the release announcement which packages are non-LTS. May also make sense to put tarballs in a separate directory, e.g. https://download.kde.org/stable/plasma/5.18.0/non-lts/plasma-nano-5.18.0.tar.xz -- Alexander Potashev пн, 9 дек. 2019 г. в 15:05, Jonathan Riddell : > > I've moved these into kde/workspace now for release with Plasma 5.18 (as non > LTS) > > Jonathan > > > On Fri, 8 Nov 2019 at 07:09, Bhushan Shah wrote: >> >> Hello! >> >> plasma-nano: https://invent.kde.org/kde/plasma-nano >> plasma-phone-components: https://invent.kde.org/kde/plasma-phone-components >> >> Two repos have been moved to kdereview, with final intended destinition >> being kde/workspace. >> >> plasma-nano is a minimal shell package which other shell package can >> extend, while plasma-phone-components is a shell package, look and feel >> and several other components which makes Plasma Mobile. >> >> Thanks >> -- >> Bhushan Shah >> http://blog.bshah.in >> IRC Nick : bshah on Freenode >> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
Re: KTimeTracker in kdereview
вт, 19 нояб. 2019 г. в 15:09, Adriaan de Groot : > > On Tuesday, 19 November 2019 05:20:23 CET Alexander Potashev wrote: > > KTimeTracker is a time tracker desktop application which is well > > suited for tracking labor time you spend on a specific > > project/feature/customer. > > Builds clean on FreeBSD; that's a +1. > > I ran it once, it works nicely .. I'd have a fistful of feature requests for > it before it can replace Charm Time Tracker in my workflow, though. Welcome to https://bugs.kde.org/enter_bug.cgi?product=ktimetracker for feature requests. Or you can tell me what features you need to see if they are already planned. -- Alexander Potashev
Re: plasma-nano and plasma-phone-components are now in kdereview
Appears to be fixed on L10n team side: https://websvn.kde.org/?view=revision&revision=1560522 Thanks Luigi! However I want to highlight the problem could be avoided by more complete communication from Plasma team. Thanks! -- Alexander Potashev On Mon, Dec 9, 2019 at 8:05 PM Alexander Potashev wrote: > > Hi Jonathan, > > Are you saying that Plasma 5.18 LTS will be a subset of Plasma 5.18? > > If so, we definitely need to notify l10n coordinators (kde-i18n-doc) > and mention in the release announcement which packages are non-LTS. > May also make sense to put tarballs in a separate directory, e.g. > https://download.kde.org/stable/plasma/5.18.0/non-lts/plasma-nano-5.18.0.tar.xz > > -- > Alexander Potashev > > пн, 9 дек. 2019 г. в 15:05, Jonathan Riddell : > > > > I've moved these into kde/workspace now for release with Plasma 5.18 (as > > non LTS) > > > > Jonathan > > > > > > On Fri, 8 Nov 2019 at 07:09, Bhushan Shah wrote: > >> > >> Hello! > >> > >> plasma-nano: https://invent.kde.org/kde/plasma-nano > >> plasma-phone-components: https://invent.kde.org/kde/plasma-phone-components > >> > >> Two repos have been moved to kdereview, with final intended destinition > >> being kde/workspace. > >> > >> plasma-nano is a minimal shell package which other shell package can > >> extend, while plasma-phone-components is a shell package, look and feel > >> and several other components which makes Plasma Mobile. > >> > >> Thanks > >> -- > >> Bhushan Shah > >> http://blog.bshah.in > >> IRC Nick : bshah on Freenode > >> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
Re: Information regarding upcoming Gitlab Migration
On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah wrote: > Use case 4 : Tom is a student in Germany and is interested in > contributing to wikitolearn, and he asks where can I find code of the > wikitolearn? Hi, I have a similar use case. Sometimes I need to share a URL to a project. For this purpose I used to share e.g. https://cgit.kde.org/releaseme.git/about Does this migration make such permalinks impossible? >From what I see, we lose permalinks because 1. cgit.kde.org will be discontinued 2. A once valid URL https://invent.kde.org/games/knetwalk may become unavailable if the project moves to another group, for example https://invent.kde.org/unmaintained/knetwalk -- Alexander Potashev
Re: Information regarding upcoming Gitlab Migration
On Fri, May 1, 2020 at 10:14 PM Ben Cooksley wrote: > On Sat, May 2, 2020 at 6:17 AM Alexander Potashev > wrote: > > I have a similar use case. Sometimes I need to share a URL to a > > project. For this purpose I used to share e.g. > > https://cgit.kde.org/releaseme.git/about > > > > Does this migration make such permalinks impossible? > > > > > > From what I see, we lose permalinks because > > 1. cgit.kde.org will be discontinued > > We provide the commits.kde.org redirector for permanent links. > Anywhere needing a long life link to a particular repository, commit, > etc (like documentation) should be using these links and not anything > else. This is helpful. Thank you Ben! -- Alexander Potashev
