KF5 Porting question regarding KFileDialog
I'm porting kolourpaint to KF5 and see that KFileDialog is marked deprecated and QFileDialog should be used instead. However QFileDialog does not have the same functionalities as KFileDialog, e.g. the possibility to show a preview widget or to add another widget to select save options (e.g. Jpeg Quality, etc.) or even to use the special "kfiledialog:///" start url. So a complete removal of KDE4support lib seems not possible. Is there anything in the queue for Qt5 integration or shall I stick to KFileDialog for the time being ? Or shall I bake my own dialog using KFileWidget ? What did other apps do ? -- 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
Porting to KF5 - kimageio question
I'm working on porting kolourpaint to kf5. Now I find the following: KDELIBS4SUPPORT_DEPRECATED_EXPORT QStringList typeForMime(const QString &mimeType); The comment says: Use QMimeType::name() instead(). However this seems incorrect. typeForMime() returned a format string usable for QImage::save(), e.g. "image/png" returns "PNG" QMimeType::name() returns the name of the mime type, which is again "image/png", which I can not pass to QImage::save() (typeForMime() gives the X-KDE-ImageFormat field from the desktop file, and the mime type is in the X-KDE-MimeType field) So, is there a REAL alternative for this method ? -- 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
Re: Porting to KF5 - kimageio question
On Sunday 10 May 2015 19:39:07 Alex Merry wrote: > On Saturday 09 May 2015 22:54:49 Martin Koller wrote: > > I'm working on porting kolourpaint to kf5. > > Now I find the following: > > KDELIBS4SUPPORT_DEPRECATED_EXPORT QStringList typeForMime(const QString > > &mimeType); > > > > The comment says: Use QMimeType::name() instead(). > > > > However this seems incorrect. > > typeForMime() returned a format string usable for QImage::save(), e.g. > > "image/png" returns "PNG" > > QMimeType::name() returns the name of the mime type, which is again > > "image/png", which I can not pass to QImage::save() > > (typeForMime() gives the X-KDE-ImageFormat field from the desktop file, and > > the mime type is in the X-KDE-MimeType field) > > > > So, is there a REAL alternative for this method ? > > Ah, you want QMimeType::suffixes() instead, since QImage types are > essentially > file extensions. no, this is not the same. suffixes() returns a QStringList(!), for instance this would return "jpg", "jpeg" for image/jpeg. But the QImage::save() method needs exactly ONE specific string as format. How should my code know which one to use ? > I had plans a while back to submit a patch to Qt to do implement the > equivalent of typeForMime and its inverse properly (using the data in the > QImageFormat plugin metadata), but never got round to finishing it. Hopefully > I'll have the time and energy to pick that up again at some point. I'd say a better solution would be to simply have no need for such a method, e.g. allow that QImageWriter (QImage, QPimap) accepts a QMimeType. So what to do about the deprecation ? Why was it done in the first place with no alternative ? -- 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
Re: KScreenGenie moved to KDE Review
On Thursday 18 June 2015 15:03:27 Boudhayan Gupta wrote: > Here's an Imgur album with some more screenshots, including how > Rectangle Selection works: > > http://imgur.com/a/1peZa I miss the "copy" button to be able to copy the captured image to the clipboard -- 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
Re: Porting to KF5 - kimageio question
On Friday 31 July 2015 15:29:45 Albert Astals Cid wrote: > El Dilluns, 18 de maig de 2015, a les 13:38:36, Albert Astals Cid va escriure: > > El Dilluns, 18 de maig de 2015, a les 08:00:07, Martin Koller va escriure: > > > On Sunday 10 May 2015 19:39:07 Alex Merry wrote: > > > > On Saturday 09 May 2015 22:54:49 Martin Koller wrote: > > > > > I'm working on porting kolourpaint to kf5. > > > > > Now I find the following: > > > > > KDELIBS4SUPPORT_DEPRECATED_EXPORT QStringList typeForMime(const > > > > > QString > > > > > &mimeType); > > > > > > > > > > The comment says: Use QMimeType::name() instead(). > > > > > > > > > > However this seems incorrect. > > > > > typeForMime() returned a format string usable for QImage::save(), e.g. > > > > > "image/png" returns "PNG" > > > > > QMimeType::name() returns the name of the mime type, which is again > > > > > "image/png", which I can not pass to QImage::save() > > > > > (typeForMime() gives the X-KDE-ImageFormat field from the desktop > > > > > file, > > > > > and > > > > > the mime type is in the X-KDE-MimeType field) > > > > > > > > > > So, is there a REAL alternative for this method ? > > > > > > > > Ah, you want QMimeType::suffixes() instead, since QImage types are > > > > essentially file extensions. > > > > > > no, this is not the same. > > > suffixes() returns a QStringList(!), for instance this would return "jpg", > > > "jpeg" for image/jpeg. But the QImage::save() method needs exactly ONE > > > specific string as format. How should my code know which one to use ? > > > > > > > I had plans a while back to submit a patch to Qt to do implement the > > > > equivalent of typeForMime and its inverse properly (using the data in > > > > the > > > > QImageFormat plugin metadata), but never got round to finishing it. > > > > Hopefully I'll have the time and energy to pick that up again at some > > > > point. > > > > > > I'd say a better solution would be to simply have no need for such a > > > method, e.g. allow that QImageWriter (QImage, QPimap) accepts a > > > QMimeType. > > > > > > So what to do about the deprecation ? > > > Why was it done in the first place with no alternative ? > > > > People make mistakes? Have you tried emailing directly the person that did > > the deprecation? > > Ping? What happened with this? >From my side, nothing happened yet -- 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
Re: Removal of ksaneplugin from KDE Applications
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 > BTW, is Kolourpaint ready for KF5 releases? I guess the only > showstopper is qimageblitz-qt5 being unreleased. I did not check recently (very busy in my job) but I think it's mainly testing. The 2 things I can remember out of my head were scanning (seems solved now) and qimageblitz-qt5. > [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 -- 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
Re: Cervisia?
On Monday 14 September 2015 13:59:20 Jeremy Whiting wrote: > Well, it was released as part of Applications 15.08.0 (and will be in > the rest of the .x releases) I'm fine either way, but it seems like > continuing to release something that hasn't been looked at in quite > some time. I think to continue to release it we would need to have: > > 1) A port to Qt5/KF5 which could be difficult with Qt3Support stuff in > it, tricky but doable. > 2) A maintainer. > > Anyone want to try taking on one or both of those? As I still use cervisia daily, I can't let it go to /dev/null ... I started to port away from Q3 classes, so the next step to port to KF5 is easier. No promises though, since my day job is demanding -- 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
Re: Cervisia?
On Thursday 15 October 2015 15:49:32 Jeremy Whiting wrote: > Michael, Martin, > > Any progress on the cervisia front? Is there anything I can do to help? yes, a lot of progress! We have already ported away from Qt3/KDE3 support classes. This is already in master and I'm testing it by using it on a daily basis. The next step would now be to start the port to KF5 - this has not been started yet. -- 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
KF5 Porting away from KDialog
What is the replacement of KDialog::setHelp() ? -- 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
KF5_ADD_KDEINIT_EXECUTABLE linker errors
Trying to port cervisia to KF5, I struggle with above.
Having
kf5_add_kdeinit_executable(cvsaskpass cvsaskpass.cpp)
always gives linker errors:
CMakeFiles/cvsaskpass.dir/cvsaskpass_dummy.cpp.o: In function `kdeinitmain':
cvsaskpass_dummy.cpp:(.text+0x1c): undefined reference to `kdemain'
CMakeFiles/cvsaskpass.dir/cvsaskpass_dummy.cpp.o: In function `main':
cvsaskpass_dummy.cpp:(.text+0x3e): undefined reference to `kdemain'
checking the cmake macro in /usr/lib64/cmake/KF5Init/KF5InitMacros.cmake, I
wonder why
is this even there:
add_executable(${_target_NAME}
${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_dummy.cpp ${_resourcefile})
and if it's needed, then why does it not add ${_SRCS} directly, since by default
the visbility of symbols is set to hidden, so this
target_link_libraries(${_target_NAME} kdeinit_${_target_NAME})
can't work.
cvsaskpass.cpp contains:
extern "C" int kdemain(int argc, char** argv)...
What am I missing ?
--
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
KF5 Porting Notes
In the section about KApplication -> QApplication, I find: Make sure to: Call QCoreApplication::setApplicationName() and others ... It seems this is not needed when one uses KAboutData::setApplicationData() If this is correct, I would add this to the page: https://community.kde.org/index.php?title=Frameworks/Porting_Notes&action=edit§ion=16 -- 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
mailing list archive gone ?
Hi, https://mail.kde.org/pipermail/kde-core-devel/ shows only 3 mails from the year 2000. Where are the other archives gone ? -- 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
Re: mailing list archive gone ?
On Saturday 27 February 2016 17:02:27 Thomas Lübking wrote: > On Samstag, 27. Februar 2016 16:09:00 CEST, Martin Koller wrote: > > Hi, > > > > https://mail.kde.org/pipermail/kde-core-devel/ > > > > shows only 3 mails from the year 2000. > > Where are the other archives gone ? > > No idea, but it's still on https://marc.info/?l=kde-core-devel&r=1&w=2 What is the official address ? Here https://www.kde.org/support/mailinglists/ it says: https://mail.kde.org/mailman/listinfo/kde-core-devel and this pages says, the archives should be at http://mail.kde.org/pipermail/kde-core-devel/ There's somewhere something wrong... -- 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
KDE file dialog
In KDE4 times there was a common file dialog for the applications, I think this is what KFileDialog was made for. Now where some applications are already ported to KF5, there seems to be no such thing anymore (or it does not work here). KFileDialog is deprecated, QFileDialog does not have the functionality of KFileDialog (e.g. aside preview). As I find KFileWidget having e.g. preview possibility, I assume QFileDialog would use this widget via the platform integration, right ? If so, does this only work when running plasma5 as desktop or is there a way to get the KDE4 features in KF5 application file dialogs even when running inside a KDE4 session ? -- 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
Re: KDE file dialog
On Sunday 28 February 2016 15:58:20 Luigi Toscano wrote: > Martin Koller ha scritto: > > In KDE4 times there was a common file dialog for the applications, I think > > this is what KFileDialog was made for. > > Now where some applications are already ported to KF5, there seems to be no > > such thing anymore > > (or it does not work here). > > KFileDialog is deprecated, QFileDialog does not have the functionality of > > KFileDialog (e.g. aside preview). > > As I find KFileWidget having e.g. preview possibility, I assume QFileDialog > > would use this widget via > > the platform integration, right ? > > If so, does this only work when running plasma5 as desktop or is there a > > way to get the KDE4 features > > in KF5 application file dialogs even when running inside a KDE4 session ? > > > > This is what I use: > export QT_QPA_PLATFORMTHEME=kde > > and you need the integration plugin installed. It used to be part of > Frameworks (frameworksintegration), it will be part of Plasma (but hopefully > still usable without). ok, good. I've now installed frameworksintegration and I've now the preview feature back - but I have also now (in my POV) ugly black-and-white icons which I don't like. Installing systemsettings5 (openSuse 13.2) does not show any icon related section (in fact it only shows 6 different sections). I'd like to have the oxygen icons as in all my other KDE4 apps. Where can I set this ? Should a KF5 app (with frameworksintegration) not also use the settings from a still used KDE4 desktop ? How would this work in e.g. a gnome desktop ? P.S.:I have also installed all oxygen5 related things I found, e.g. oxygen5-icon-theme, oxygen5-style -- 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 -- 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
Re: KDE file dialog
On Monday 29 February 2016 21:34:13 Luigi Toscano wrote: > > Should a KF5 app (with frameworksintegration) not also use the settings > > from a still used KDE4 desktop ? > > frameworksintegration is going to be part of plasma, in fact. There would need > to be an "old plasma" integration. Or you can use an alternative system to set > it, like https://sourceforge.net/projects/qt5ct/ is this project a different frameworksintegration plugin ? I thought it's just to _configure_ things. Using it here results in: - oxygen icons as I like - good - no file dialog preview feature again ... - not good So basically I can: - not use plasma framework integration (no file preview) - use plasma framework integration with file preview but having ugly icons, different fonts, colors, ... basically having an ugly mixture of KDE4 and KDE5 things. am I missing an option ? -- 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
Qt5 version of qimageblitz
Hi,
as I want to bring kolourpaint to KF5, what is missing is a Qt5 based release
of the old
qimageblitz library, which still resides in SVN at
svn://anonsvn.kde.org/home/kde/trunk/kdesupport/qimageblitz
As this is probably the problem that I can not add a review request on
reviewboard, here is
a simple patch which allows to co-install the Qt4 and the Qt5 version.
Can someone review this, please ?
If this is ok, how would one make an official relase of this new version ?
Is it just tagging the repo ?
(If so, I'm an SVN noob. How to, please ?)
Thanks!
--
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.atIndex: CMakeLists.txt
===
--- CMakeLists.txt (revision 1454199)
+++ CMakeLists.txt (working copy)
@@ -9,6 +9,7 @@
find_package(Qt5Core QUIET)
endif()
if (Qt5Core_FOUND)
+ set(QT_PREFIX "5")
message(STATUS "Building with Qt5 support")
cmake_minimum_required(VERSION 2.8.8) # Bump requirement for automoc and convenience macros.
set(CMAKE_AUTOMOC ON)
@@ -15,6 +16,7 @@
find_package(Qt5Core REQUIRED)
find_package(Qt5Gui REQUIRED)
else()
+ set(QT_PREFIX "")
find_package(Qt4 REQUIRED)
# properly set up compile flags (QT_DEBUG/QT_NO_DEBUG, ...)
include(${QT_USE_FILE})
Index: blitz/CMakeLists.txt
===
--- blitz/CMakeLists.txt (revision 1454199)
+++ blitz/CMakeLists.txt (working copy)
@@ -72,13 +72,15 @@
ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
)
-install( FILES qimageblitz.h qimageblitz_export.h blitzcpu.h DESTINATION include/qimageblitz COMPONENT Devel )
+set(INCLUDE_INSTALL_DIR include/qimageblitz${QT_PREFIX})
+install( FILES qimageblitz.h qimageblitz_export.h blitzcpu.h DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel )
+
if(NOT WIN32)
- configure_file("qimageblitz.pc.cmake" "${CMAKE_CURRENT_BINARY_DIR}/qimageblitz.pc"
+ configure_file("qimageblitz.pc.cmake" "${CMAKE_CURRENT_BINARY_DIR}/qimageblitz${QT_PREFIX}.pc"
@ONLY)
- install(FILES ${CMAKE_CURRENT_BINARY_DIR}/qimageblitz.pc DESTINATION
+ install(FILES ${CMAKE_CURRENT_BINARY_DIR}/qimageblitz${QT_PREFIX}.pc DESTINATION
${LIB_INSTALL_DIR}/pkgconfig)
endif(NOT WIN32)
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt (revision 1454199)
+++ test/CMakeLists.txt (working copy)
@@ -23,14 +23,14 @@
cmake_policy(SET CMP0003 NEW)
endif(COMMAND cmake_policy)
-add_executable(blitztest ${blitztest_SRCS})
+add_executable(blitztest${QT_PREFIX} ${blitztest_SRCS})
if (Qt5Core_FOUND)
- qt5_use_modules(blitztest Core Gui Widgets)
+ qt5_use_modules(blitztest${QT_PREFIX} Core Gui Widgets)
endif()
-target_link_libraries(blitztest ${QT_QTCORE_LIBRARY}
+target_link_libraries(blitztest${QT_PREFIX} ${QT_QTCORE_LIBRARY}
${QT_QTGUI_LIBRARY} qimageblitz)
-install(TARGETS blitztest DESTINATION ${BIN_INSTALL_DIR})
+install(TARGETS blitztest${QT_PREFIX} DESTINATION ${BIN_INSTALL_DIR})
Re: Qt5 version of qimageblitz
On Saturday 05 March 2016 09:42:01 Boudhayan Gupta wrote: > Hi Martin, > > > If this is ok, how would one make an > > official relase of this new version ? > > The first step would be to migrate to a Git repo. SVN is mostly used for > translations and websites these days. I'm not the original author of qimageblitz, nor am I the maintainer, nor do I have any clue how to migrate the SVN repo to a git repo (including history). Who is in charge of the old SVN repos ? Who is in charge of qimageblitz ? -- 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
Re: Qt5 version of qimageblitz
On Sunday 06 March 2016 12:35:32 Albert Astals Cid wrote: > El Sunday 06 March 2016, a les 08:38:14, Boudhayan Gupta va escriure: > > On 6 March 2016 at 01:26, Martin Koller wrote: > > > Who is in charge of the old SVN repos ? > > > Who is in charge of qimageblitz ? > > > > I asked around on IRC and it seems QIB is "community maintained" and > > as such doesn't have a maintainer. > > > > You should just be able to file a sysadmin ticket to get it migrated > > from SVN to Git. > > It was my understanding that qimageblitz is actually not something we want to > port to Qt5 and we should just try to use Qt's own stuff for this. AFAIK Qt does not provide the features of qimageblitz, e.g. emboss etc. > If qimageblitz gets ported to Qt5 it should basically be a Tier 0 frameworks > so CC'ing the frameworks devel list. It WAS already ported to Qt5. I did not do any porting, I just created a patch which allows to co-install the Qt4 and the Qt5 built version. -- 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
Re: Qt5 version of qimageblitz
On Sunday 06 March 2016 08:38:14 Boudhayan Gupta wrote: > On 6 March 2016 at 01:26, Martin Koller wrote: > > Who is in charge of the old SVN repos ? > > Who is in charge of qimageblitz ? > > I asked around on IRC and it seems QIB is "community maintained" and > as such doesn't have a maintainer. > > You should just be able to file a sysadmin ticket to get it migrated > from SVN to Git. I started to create a sysadmin ticket, but I don't know - "Initial maintainer identity user names, separated by ;" - "Intended location on projects.kde.org, " -- 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
Re: [Kde-pim] Qt 4 Builds
On Sunday 27 March 2016 09:21:01 laurent Montel wrote: > Le dimanche 27 mars 2016, 10:57:18 CEST Ben Cooksley a écrit : > > Hi all, > > > > As part of the CI overhaul, we've attempted to perform a complete set > > of builds for Qt 4, as it's still (unfortunately) used. > > > > Sadly, as expected for something nobody has really tried to build for > > ages, many things don't build. > > One of those is the entire PIM suite - because Baloo removed it's Qt 4 > > build metadata (meaning as far as the CI system is concerned, Baloo > > has no Qt 4 branches and is Qt 5 only) > > > > You've two options here: > > 1) Drop Qt 4 PIM. > > 2) Reinstate Baloo's Qt 4 branches. > > > > I intend to carry out option #1 if there is no response to this. > > I vote for #1 too. > We will not create more release from kdepim4, no distro uses it even debian :) The latest openSuse (Leap 42.1) ships the Qt4 based kdepim, although it uses plasma5 desktop. Speaking of it: given that openSuse decided against shipping KF5-based PIM, how stable is KF5-based PIM considered these days ? Is it ready for productive daily professional use ? -- 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
Re: Cervisia?
On Friday 16 October 2015 06:53:19 Jeremy Whiting wrote: > Awesome! Keep it up. Porting to Qt5/KF5 can happen on a branch and be > done a small bit at a time if you like. There are also some scripts in > kdesdk/kde-dev-scripts/kf5 that can help with the trivial changes. > Most are executed like find -iname *.cpp | xargs scriptname, but if > not they will say in a comment at the top of the script how to execute > them. > > On Thu, Oct 15, 2015 at 8:02 PM, Martin Koller wrote: > > On Thursday 15 October 2015 15:49:32 Jeremy Whiting wrote: > >> Michael, Martin, > >> > >> Any progress on the cervisia front? Is there anything I can do to help? > > > > yes, a lot of progress! > > We have already ported away from Qt3/KDE3 support classes. > > This is already in master and I'm testing it by using it on a daily basis. > > > > The next step would now be to start the port to KF5 - this has not been > > started yet. Just for your information: I have now completed the KF5 port and master now holds this version -- 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
Re: Cervisia?
On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> Am Samstag, 4. Juni 2016, 22:45:49 CEST schrieb Martin Koller:
> > On Friday 16 October 2015 06:53:19 Jeremy Whiting wrote:
> > > Awesome! Keep it up. Porting to Qt5/KF5 can happen on a branch and be
> > > done a small bit at a time if you like. There are also some scripts in
> > > kdesdk/kde-dev-scripts/kf5 that can help with the trivial changes.
> > > Most are executed like find -iname *.cpp | xargs scriptname, but if
> > > not they will say in a comment at the top of the script how to execute
> > > them.
> > >
> > > On Thu, Oct 15, 2015 at 8:02 PM, Martin Koller wrote:
> > > > On Thursday 15 October 2015 15:49:32 Jeremy Whiting wrote:
> > > >> Michael, Martin,
> > > >>
> > > >> Any progress on the cervisia front? Is there anything I can do to help?
> > > >
> > > > yes, a lot of progress!
> > > > We have already ported away from Qt3/KDE3 support classes.
> > > > This is already in master and I'm testing it by using it on a daily
> > > > basis.
> > > >
> > > > The next step would now be to start the port to KF5 - this has not been
> > > > started yet.
> > Just for your information: I have now completed the KF5 port and master now
> > holds this version
>
> So you want Scripty to track master to trunk_kf5 and Applications/16.04 to
> l10n stable, right?
Ermm. don't understand.
> Some i18n issues:
>
> It is a QApplication so you have to add the translators tab manually with
> aboutData.setTranslator
ok. what shall I write there (names, emails ?)
Isn't that a limited approach to name the translators in the sourcecode, since
every new translation added will need a source change ?
> no setApplicationDomain("cervisia"), so no translations of KXmlGui (.rc)
> files
> and KConfigXT (.kcfg) files, see https://api.kde.org/frameworks/ki18n/html/
> prg_guide.html
What I have in the cmake file is
add_definitions(-DTRANSLATION_DOMAIN="cervisia")
Is that not enough ?
Note that cervisia is also built as a KPart.
I put now
KLocalizedString::setApplicationDomain("cervisia");
in kdemain()
--
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
Re: Cervisia?
On Sunday 05 June 2016 19:49:08 Friedrich W. H. Kossebau wrote:
> Am Sonntag, 5. Juni 2016, 14:22:45 CEST schrieb Nicolás Alvarez:
> > > El 5 jun 2016, a las 09:08, Martin Koller escribió:
> > >> On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> > >>
> > >> Some i18n issues:
> > >>
> > >> It is a QApplication so you have to add the translators tab manually with
> > >> aboutData.setTranslator
> > >
> > > ok. what shall I write there (names, emails ?)
> > >
> > > Isn't that a limited approach to name the translators in the sourcecode,
> > > since every new translation added will need a source change ?
> >
> > No; you use something like i18n("TRANSLATOR NAME") (I don't remember the
> > exact string), so that the name comes from the translation itself.
>
> It would be
> setTranslator(i18nc("NAME OF TRANSLATORS", "Your names"),
> i18nc("EMAIL OF TRANSLATORS", "Your emails"));
>
> And it needs to be these very strings, as they are here, both comment and
> content, because for those by definition there will be in the catalog
> translation strings which then contain the names of the people who did the
> translations for the given language. Which means, the i18nc call will then
> return the names (and emails) of the translators for the current language, as
> stored in the currently used translation catalog. (So not the names of all
> the
> translators who translated to any languages, just for the current).
> And there will be always such strings with their translation in the
> translation catalog, they do not need to be present in the actual code which
> makes uses of them, and thus do not need to be present in the catalog
> template
> (pot file).
>
> And as Albert already said in his email, it might not need to be done when
> using KMainWindow (or derived classes like KXmlGuiWindow), as by tradition
> the
> KMainWindow constructor ensures those strings are set on the global
> KAboutData::applicationData object.
>
Thanks for clarification.
So cervisia is not using KMainWindow and also not KXmlGuiWindow.
It uses KParts::MainWindow.
Is that ok ?
--
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
kolourpaint now KF5 based
Hi all, just wanted to let you know that I have now completed the kolourpaint port to KF5 and this is now in its master branch. I have also updated kde-build-metadata Hope I did all correct. -- 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
Re: kolourpaint now KF5 based
On Wednesday 13 July 2016 20:24:42 Luigi Toscano wrote: > Martin Koller ha scritto: > > Hi all, > > > > just wanted to let you know that I have now completed the kolourpaint port > > to KF5 > > and this is now in its master branch. I have also updated kde-build-metadata > > Hope I did all correct. > > I'm going to update the i18n branches on repo-metadata (which generated > kde_projects.xml) and move the translations. thanks > Do you know that there is a thread on kde-devel@ about the status of the > Frameworks version of Kolourpaint? no, I missed this one > I see you don't depend anymore on qimageblitz. yes, that's correct. Since I poked people for the last few months about it, I had to go my own route. I just copied the few methods kolourpaint uses. > Would you reintroduce the > dependency if qimageblitz was released for Qt5? Jeremy was working on it. That can be done -- 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
Re: kolourpaint now KF5 based
On Wednesday 13 July 2016 20:51:24 Christoph Feck wrote: > On Wednesday 13 July 2016 20:12:46 Martin Koller wrote: > > just wanted to let you know that I have now completed the > > kolourpaint port to KF5 and this is now in its master branch. I > > have also updated kde-build-metadata Hope I did all correct. > > The about dialog says it is version 5.25.0 (=frameworks version). I > guess this is not intended. Hmm ... it was like that since 2008 Changed that now. -- 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
Re: kolourpaint now KF5 based
On Thursday 14 July 2016 19:26:42 Ragnar Thomsen wrote: > On Thu, Jul 14, 2016 at 8:12 AM, Martin Koller wrote: > > > On Wednesday 13 July 2016 20:51:24 Christoph Feck wrote: > > > On Wednesday 13 July 2016 20:12:46 Martin Koller wrote: > > > > just wanted to let you know that I have now completed the > > > > kolourpaint port to KF5 and this is now in its master branch. I > > > > have also updated kde-build-metadata Hope I did all correct. > > > > > > The about dialog says it is version 5.25.0 (=frameworks version). I > > > guess this is not intended. > > > > Hmm ... it was like that since 2008 > > Changed that now. > > > > I propose that you instead follow KDE Applications version. This way you > can get automatic update of version number. See e.g. this commit: > https://quickgit.kde.org/?p=gwenview.git&a=commit&h=a992a8cdbe41db2c8869c79d42ff9cd09dfaf66b Thanks for the hint. Done that now like this. -- 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
KDirWatch issue
Hi,
just wondering if I'm doing something wrong or there really is a bug in
KDirWatch
(I'm on openSuse Leap 42.2, KF5 5.33.0)
From the docs I understand that when I call
KDirWatch::stopDirScan(dir);
... create files in the dir ...
KDirWatch::restartDirScan(dir)
it should not emit the dirty signal when I run this, right ?
Well, it does.
I've attached a small test.
When I modify the code and use stopScan() ... create ... startScan()
I still receive the dirty signal with the path to the file I created.
Only way it works without signal is
removeDir(dir) ... create ... addDir(dir)
Is this how it's supposed to work ?
--
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.atcmake_minimum_required(VERSION 3.5)
project(dirwatch)
find_package(ECM 5.19 REQUIRED NO_MODULE)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})
include(KDEInstallDirs)
include(KDECompilerSettings NO_POLICY_SCOPE)
include(KDECMakeSettings)
find_package(KF5CoreAddons)
add_executable(dirwatch main.cxx)
target_link_libraries(dirwatch KF5::CoreAddons)
#include
#include
#include
#include
#include
QString watchedDir;
KDirWatch *watch = 0;
class Object : public QObject
{
Q_OBJECT
public slots:
void createFile()
{
watch->stopDirScan(watchedDir);
//watch->stopScan();
//watch->removeDir(watchedDir);
QFile f(watchedDir + "/watched");
f.open(QIODevice::WriteOnly);
f.write("123");
f.close();
watch->restartDirScan(watchedDir);
//watch->startScan();
//watch->addDir(watchedDir);
}
void dirChanged(const QString &dir)
{
qDebug() << "dir changed" << dir;
}
};
int main(int argc, char **argv)
{
QCoreApplication app(argc, argv);
watchedDir = QFile::decodeName(argv[1]);
watch = new KDirWatch;
watch->addDir(watchedDir);
Object o;
o.connect(watch, &KDirWatch::dirty, &o, &Object::dirChanged);
QTimer::singleShot(2000, &o, SLOT(createFile()));
return app.exec();
}
#include "main.moc"
http://commitfilter.kde.org/ ?
Should http://commitfilter.kde.org/ still exist ? Currently I get "unknown host" -- 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
Re: http://commitfilter.kde.org/ ?
> On Sun, Oct 29, 2017 at 9:47 PM, Martin Koller wrote: > > Should http://commitfilter.kde.org/ still exist ? > > Currently I get "unknown host" On Sonntag, 29. Oktober 2017 22:33:20 CET Harald Sitter wrote: > See > > http://markmail.org/thread/hekkp2rcdvir732q > http://markmail.org/thread/b6neyhjak2h4g2yd rephrasing: is there still a way to receive commit mails to the various git repositories or is this feature completely gone ? -- 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
liquidshell in kdereview
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
Re: liquidshell in kdereview
On Samstag, 4. November 2017 02:35:27 CET Alexander Potashev wrote: > 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 thanks. I've fixed things now to compile with older Qt (5.6) and older compiler (g++ 4.8.5) -- 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
Re: liquidshell in kdereview
s which would justify this. Maybe it's the problem that there are devices shown which should not. Let's find out which ones. > network also doesn't seem scrollable yes, it isn't. But I also think you will not have that many entries shown. Am I wrong ? > * No battery applet, I don't understand. You'd like to have a battery desktop applet ? That's of course doable if needed (I just had no need for that). > icon just opens KCM More importantly: It shows the current battery status and has a tooltip. What do you mean by "just" ? > * "Bluetooth is not operational", why show the icon then Because otherwise you would not be able to turn it on (a click opens the kcm) > * Notifications doesnt handle multiple incoming ones well (just stacks > dialogs ontop of each other) interesting use case. never had problems with that, but that can be changed, of course. > * Start button breaks Fitt's law (I cannot open it by janking the cursor into > the lower-left corner) I can live with that (BTW: in plasmashell you can't either) > * No multi-screen support whatsoever commit a03d66c69d78c6eec9f0728c38a597ea874e3787 Author: Martin Koller Date: Sat Nov 4 13:50:46 2017 +0100 handle multi-screen setup Desktop Panel always only on primary screen, Wallpaper drawn per screen in corresponding scaled version > * I like the background color selector combination of ComboBox and "custom" thanks, but kudos go to KDE's KColorCombo > * Often uses QString instead of enums You probably mean the Weather Applet (units) where this is done since the selected units is used as string in the URL to be queried. > * Task Bar does not announce "iconified geometries" to KWin thus minimize > animations go to the wrong place (centre of screen usually) Interesting point. How would I do this ? (Since openGL does not work on my machine (crappy Intel driver) - therefore also the need to have a widgets based solution - I don't use animations ...) > * The coding style and naming practises do not follow "modern" KDE Frameworks > guidelines It's the coding style and naming practises I use for the last 25 years, and liquidshell is no framework lib. -- 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
Re: liquidshell in kdereview
On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote: > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote: > > Hi all, > ... > > - Just one bottom DesktopPanel, containing: > > I always put my panel to the right or left edge (intead at the bottom)... Then I fear liquidshell is simply not for you. > ... > > 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. > > Not sure whether "liquid" is a good choice then, I don't really associate > "solid" with it ;-) I was thinking about "solidshell" but "Solid" has already a different meaning inside KDE ... -- 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
Re: liquidshell in kdereview
On Sonntag, 5. November 2017 23:01:52 CET Alexander Neundorf wrote: > On 2017 M11 5, Sun 19:27:27 CET Martin Koller wrote: > > On Samstag, 4. November 2017 20:58:49 CET Alexander Neundorf wrote: > > > On 2017 M11 3, Fri 21:30:19 CET Martin Koller wrote: > > > > Hi all, > > > > > > ... > > > > > > > - Just one bottom DesktopPanel, containing: > > > I always put my panel to the right or left edge (intead at the bottom)... > > > > Then I fear liquidshell is simply not for you. > > ... I guess in doubt you wouldn't mind some patches ? of course patches are welcome, at least until they do not introduce a whole lot of troubles (e.g. I fear that the taskbar as it is right now is rather useless when running the panel vertically, except you make it ridiculously wide). I just can remember that I tried to fix panel widgets in KDE3 times(!) where there were troubles with the widgets trying to be useful even in vertical orientation. But let's see with what you come up ;-) -- 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
Re: liquidshell in kdereview
On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > Hi all, > > > > I'd like to announce an application I've implemented over the last few > > weeks - liquidshell > > > > liquidshell is a replacement for plasmashell > > > > Hi Martin, > I'm a bit confused, who is liquidshell for? Whoever does not like plasmashell, for whatever reason. My reasons are mentioned in the README or the announcement mail. Free software is about choice, no ? -- 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
Re: liquidshell in kdereview
On Montag, 6. November 2017 10:03:05 CET Tomaz Canabrava wrote: > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller wrote: > > > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller wrote: > > > > Hi all, > > > > > > > > I'd like to announce an application I've implemented over the last few > > weeks - liquidshell > > > > > > > > liquidshell is a replacement for plasmashell > > > > > > > > > > > > Hi Martin, > > > I'm a bit confused, who is liquidshell for? > > > > Whoever does not like plasmashell, for whatever reason. > > My reasons are mentioned in the README or the announcement mail. > > Free software is about choice, no ? > > > > It is, of course. Then, it's also about non-fragmentation, and you know, > human resources are spare. > I know it's your time and your project and I will never tell you what to > do, > but considering that there's lxqt which exists basically for the same > 'whatever reasons', why not help them instead of creating yet another > desktop shell? lxqt say on their web page "The Lightweight Qt Desktop Environment" I don't want to create yet another Desktop Environment. I was just unhappy with plasmashell, which liquidshell replaces -- 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
Re: liquidshell in kdereview
On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote: > Some more branding oriented nitpicks: > > Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > > - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual > > Desktops, Bluetooth, Network > > Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs" > being a concept which no longer exists at age of KDE Frameworks and Plasma. changed > > 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 > > Please consider using a non-KDE logo on the start menu on representative/ > advertising screenshots (ideally some new liquidshell logo one, also to help > promoting it and building an identity). > Given the history meaning of the KDE logo as the logo of a desktop, using the > KDE logo will spoil the concerted effort of the rebranding done (whether it > was a good idea or not is too late to discuss) and only continue the > confusion, for no good. > > So with the Plasma workspaces having moved to the Plasma logo, leaving the > KDE > logo for the community, liquidshell should have and use its own dedicated > logo > as well. (and yes, the start-here-kde icons would need renaming finally) I'm very bad at creating appealing graphics, therefore I used exiting icons where possible. Is there some KDE artist who is willing to create a new logo for me ? Regarding the rebranding: does that mean KDE (the people behind the project) does not like to promote KDE ? Very confusing in my view. I really meant to show "that is a KDE (based) application" by using its logo - was not clear that this is not welcomed. -- 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
Re: liquidshell in kdereview
On Montag, 6. November 2017 17:12:31 CET Friedrich W. H. Kossebau wrote: > Hi Martin, > > Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller: > > I'd like to announce an application I've implemented over the last few weeks > > - liquidshell > > Congrats to the achievement. It surely feels good to run a workspace one has > created one themselves :) > > While myself I will choose Plasma over liquidshell due to my needs and > expectations of certain features, I can see that liquidshell would satisfy > those persons who need or want just a simple hard-coded shell following a > well-known UI design & concept, yet stay with the usual tools and apps from > the KDE software world, ideally perfectly integrated with the workspace > (think > filemanager, terminal, text editor, etc). People like obviously yourself :) > So > those persons might be surely happy about you sharing your work with them. > > My hopes for liquidshell as another project under the KDE community umbrella: > * improvements for shared middleware, perhaps even introducing some more > where it makes sense to share between Plasma, liquidshell & others > (pushing for more clear UI-core separation, which in theory is for good) > libtm might be one such thing, the weather data provider system also calls > for being shared code with Plasma (and e.g. the Marble weather plugin) > * another testing ground for protocols & standards in development > * make more obvious that "KDE" is about a community, not a certain software > * give perhaps remaining trinity desktop developers and other > Plasma-no-Qt-jay-fans a new center for their goals and as result also new > contributors for the shared middleware, tools and apps (at least for their > current QtWidgets UI variant ;) ) > > Re: gosh, yet another workspace > In a perfect world everybody would join work on the one true golden workspace > solution, reality is that there is no such one-workspace-which-fits-all. Not > to forget the mythical person-month issue. > > And if people rather go and write their own software instead of joining > existing projects, it should be the projects asking themselves why they have > not been attractive enough in the first place. > Telling people instead "you should not do X, but Y" is rather the opposite of > what Free Software is about. Even when first saying "Your are free, but". > > I applaud you, Martin, for managing to solve your needs yourself and for > sharing the results with the rest of the world, instead of keeping them for > yourself. > And as KDE community we can feel honored you trust us to be the best place > for > further development of your software, instead of going github or elsewhere. thanks for the appreciation > Re: liquidshell as name > When I read liquidshell I first thought about something very dynamic, highly > animated. So not sure "liquid" is the best term to use in the name. But then > we all know naming is hard, good luck with it :) This was a tough one. really not easy to select a sensible name. I was considering "solidshell" but Solid has already a meaning in the KDE world. -- 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
Re: liquidshell in kdereview
On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote: > Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller: > > On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote: > > > > 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 > > > > > > Please consider using a non-KDE logo on the start menu on representative/ > > > advertising screenshots (ideally some new liquidshell logo one, also to > > > help promoting it and building an identity). > > > Given the history meaning of the KDE logo as the logo of a desktop, using > > > the KDE logo will spoil the concerted effort of the rebranding done > > > (whether it was a good idea or not is too late to discuss) and only > > > continue the confusion, for no good. > > > > > > So with the Plasma workspaces having moved to the Plasma logo, leaving the > > > KDE logo for the community, liquidshell should have and use its own > > > dedicated logo as well. (and yes, the start-here-kde icons would need > > > renaming finally) > > I'm very bad at creating appealing graphics, therefore I used exiting icons > > where possible. > > Is there some KDE artist who is willing to create a new logo for me ? > > I recommend to follow https://vdesign.kde.org/how.html and poke the VDG > people > directly with your requirement. thanks, will do > > > Regarding the rebranding: does that mean KDE (the people behind the project) > > does not like to promote KDE ? > > Very confusing in my view. > > I really meant to show "that is a KDE (based) application" by using its logo > > - was not clear that this is not welcomed. > > Surely we want to promote KDE, the community :) Just, like e.g. apps like > Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the > community, they do it via the entry in the Help menu or in the About data. > Still they have their own logo/icon for showing off e.g. "he, it's me, > okular" > and have their logo/icon displayed as identifier. > > The start menu icon here serves a similar purpose usually, it shows "he, its > me, workspace product X/operating system Y". But not saying "I am done by A", > especially when A creates different variants of the product type. > > And with the history of "KDE" being once the name of a workspace product, > using its logo on the start menu like in the formerly named "KDE" product > could trigger the uninformed people to consider liquidshell being the new > "KDE". Adding to confusion and wasted resources in fighting those > misconception. > So better prevent from the start, so our time could be spent in bug fixing > instead. ok, understand. > BTW, would you like assistance to have liquidshell covered on build.kde.org? > Seems it is not there yet. Wow - didn't know that this exists. Is this just for testing if it compiles or are packages released from there ? I've currently uploaded a version to build.opensuse.org which compiles currently some openSuse versions. -- 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
Re: liquidshell in kdereview
On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote: > Am 2017-11-03 21:30, schrieb 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. > > [snip] > > > 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'm now playing devils advocate: which window manager are you using? personally I'm using kwin, since I only replaced plasmashell, but I assume this is irrelevant to what "shell" one is using. > If I understand correctly this is supposed to be a replacement for > plasmashell in Plasma, which would mean that you use KWin. yes > Are you aware that KWin uses QtQuick for all its UI elements, such as > Alt+TAB? I have deactivated the compositor since sadly it simply does not work on my laptop (the intel graphics driver just freezes the whole machine). > Isn't that also a memory and resource hog? not here. It's not in the top 10 processes of CPU or memory usage > Shouldn't you come up with a replacement for KWin as well? no (as long as it works good enough for me) > Also concerning no hardware graphics acceleration needed: who is going > to render your UI? Do you really think the QPainter API is the best and > most efficent to render a UI? Especially considering that in the end the > whole thing needs to be transferred to the GPU. Are you aware that the > compositor uses hardware acceleration to render the UI? If you don't use > a compositor: are you aware that XServer itself uses hardware > acceleration to render its UI (check glamor). Are you aware that if you > don't have hardware acceleration everything is going to be rendered > through llvmpipe? Do you really think QPainter is better than llvmpipe? > Because I - having worked with that stuff for years in a low level area > - doubt so. You're barking at the wrong tree. I don't care how it's done deep down in the stack. I can tell you that now with liquidshell my CPU uses 0% CPU most of the time, and starting plasmashell it's more - sometimes much, much more without changing anything in the workspace setup. That is simply not acceptable for me. If plasmashell would work better, I would not have created liquidshell in the first place. Just wanting to WORK with my system, which I simply could not with plasmashell. > I don't mind what you develop in your spare time. Not at all. What I > mind is if a product is added to KDE as a competitor/replacement to a > product I work on because of misunderstood things. What I see here is > that you completely misunderstood what hardware acceleration means and > gives to the system. See above. I did not start liquidshell because I was bored. Believe me, I have other hobbies. I started it just because I got fed up with the problems I had with plasmashell and I need to use some DE for my daily work. Restarting plasmashell multiple times a day is just not funny. > I know, I know more than 90 % and all the > "lightweight" people get this wrong. But you know what I observed more > and more over the last years: people praise Plasma for the fast speed, > responsiveness and low memory consumption. Why is that so, why do people > no longer consider our software as bloated? Because we use QML and we > use it well! For me it - sadly - got worse over time. > So if that gets added I want to have it made clear that this is not a > "lightweight" product Did you read "lightweight" anywhere in my README ? > and I don't want it to be advertised as not using > hardware acceleration. > I don't want to see what you list in the main > motivation. I did not know that I need permission from you for what motivates me > Because that will just result in people going all "KDE dev > develops new desktop shell, because Plasma is unreliable". which it is for me, sorry > If that happens it pisses me off! And that's what's going to happen the way > you > phrased it. And what would piss me even more of is if that is due to you > misunderstanding hardware acceleration. I removed now the "no hardware acceleration" sentence from my README, since I&
Re: liquidshell in kdereview
On Donnerstag, 9. November 2017 15:32:46 CET Friedrich W. H. Kossebau wrote: > Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller: > > On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote: > > > Am 2017-11-03 21:30, schrieb Martin Koller: > > > I don't mind what you develop in your spare time. Not at all. What I > > > mind is if a product is added to KDE as a competitor/replacement to a > > > product I work on because of misunderstood things. What I see here is > > > that you completely misunderstood what hardware acceleration means and > > > gives to the system. > > > > See above. I did not start liquidshell because I was bored. Believe me, I > > have other hobbies. I started it just because I got fed up with the > > problems I had with plasmashell and I need to use some DE for my daily > > work. Restarting plasmashell multiple times a day is just not funny. > > I think what Martin F. is also asking here, and what surely one expects as > standard in KDE, is that the description of the liquidshell product/project > is > not making false or unresearched claims I did not make false or unresearched claims. QPainter, wich is the base for drawing in QWidgets, is - AFAIK - not using hardware acceleration. At least inside Qt. Martin F. just explained that deep down in the graphics stack there is still acceleration used, but that was not my point. > or speaking badly about alternative solutions, especially from the same > community. > In short: being respectful :) > So e.g. if this was about some new liquidhexeditor, I as author of Okteta > would be not happy about phrases like: > > * "liquidhexeditor is a replacement for okteta" > "replacement" (to me) comes with meaning of successor, being better. Which is > attributing things. > The more neutral word "alternative" might be better here. will change > * "It does not use QtQuick but instead relies on QtWidgets." > "not use X but relies on Y" also tells me that "X" sucks and better is > avoided. > Where one could rather say "Uses X for everything because property 1, > property > 2 and property 3", without losing a word about "Y". Just listing the factors > one made their choice on for using "X" leaves everyone with their idea about > the qualities of "Y". > E.g. it could be said that QWidgets are a stable mature UI technology and > (like already is sayed) provide a consistent UI across shell and apps (at > least the QWidget-based apps). > No need to speak here about alternatives like QQ, Gtk, or EFL, there are > people for any who think that to be a better base to build a UI on. the major difference between plasmashell and liquidshell IS the non-usage of QtQuick, therefore it definitely needs to be mentioned. That does not imply judgement. It's just an explanation of what technology it uses and which it does not - given that these are the two major possibilities from Qt. I have adjusted the README > BTW, you are surely aware that other UI components of the Plasma workspace, > like the System Settings, are ported to QtQuick currently. So given your > implementation choices, do you plan to create a liquidsystemsettings variant > as well? not planned -- 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
Re: liquidshell in kdereview
On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > Hi all, > > I'd like to announce an application I've implemented over the last few weeks > - liquidshell since more than 3 weeks have passed, I hopefully have addressed all issues and I got no further comments, are there any blocking points you see or can I proceed requesting the move to extragear ? A note regarding the comment to not use the start-here-kde logo: I got in contact with the visual design group and got the information to stay with this logo. -- 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
Re: liquidshell in kdereview
On Donnerstag, 30. November 2017 10:04:51 CET Sebastian Kügler wrote: > On woensdag 29 november 2017 21:23:15 CET Martin Koller wrote: > > On Freitag, 3. November 2017 21:30:19 CET Martin Koller wrote: > > > > > > > Hi all, > > > > > > I'd like to announce an application I've implemented over the last few > > > weeks - liquidshell > > since more than 3 weeks have passed, I hopefully have addressed all issues > > and I got no further comments, are there any blocking points you see or can > > I proceed requesting the move to extragear ? > > > > A note regarding the comment to not use the start-here-kde logo: > > I got in contact with the visual design group and got the information to > > stay with this logo. > > I strongly disagree. Could you point me to the discussion? it was mail exchange in private (german) mails with the breeze/oxygen-icons maintainer "kainz.a" -- 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
kbackup in kdereview
Hi all, I'd like to announce kbackup - A Backup program with an easy to use User Interface KBackup is a program that lets you back up any directories or files, whereby it uses an easy to use directory tree to select the things to back up. The program was designed to be very simple in its use so that it can be used by non-computer experts. It can do full- and incremental backups. The storage format is the well known TAR format, whereby the data is still stored in compressed format (bzip2 or gzip). The backup can be put onto a local directory (mounted device, etc.) but also on a remote URL (thanks to KDE KIO). I started development already a long time ago in 2006, based on Qt3(!). I released it on https://www.linux-apps.com/content/show.php?content=44998 and it quickly became a much downloaded program. Over the years I always added new features when something I felt was missing. In the last year I finally managed to upgrade it to using KF5, and I feel it's time to integrate it more deeply with the KDE project. It has also a handbook and was already integrated with the translation team, thanks to Luigi Toscano and Burkhard Lück I think a good harbor for it will be kdeutils. It is already in playground at https://cgit.kde.org/kbackup.git -- 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
Re: kbackup in kdereview
On Mittwoch, 10. Jänner 2018 00:05:53 CET Albert Astals Cid wrote: > > It is already in playground at https://cgit.kde.org/kbackup.git > > Quick notes: > * You don't need the setTranslator call in main.cxx there's automagic for > that fixed now > * You should remove the kol...@aon.at in the about data and get a > bugs.kde.org product How can I get one ? > * Seems there's some issues with i18n, after a quick backup i got > ...finished slice /home/kdeunstable/kbackup/build/ > backup_2018.01.10-00.02.29_1.tar(I18N_ARGUMENT_MISSING) > -- Filtered Files: 0(I18N_ARGUMENT_MISSING) this was already fixed by the awesome translation guys. > * What is the Medium: label and the percentage bar after it? Medium: is telling you to which medium you are currently writing to, e.g. the first ZIP disk The application was built when ZIP drives and other smaller removable devices were more common. Therefore the backup can be split into multiple slices, put onto several media. The percentage shows how full the medium is right now, and the size to the right of the bar tells you how much data you can store on it (free space). > * How do i get a non full backup? ( i guess it would be an incremental one? ) right. In the profile settings, set the full backup interval to at least 2 days, then start the backup and it will display "Next backup: Incremental backup" > Also crashes on Alt+F4 Ah, damned. I introduced this just a few days ago trying to fix a hang on exit with dbus ... Thanks for finding. Fixed. -- 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
liquidshell in kdereview
Hi, since some time has already passed and there was no conclusion, I'll try once again to announce liquidshell. I have made adjustments to the README which now says: liquidshell is a basic Desktop Shell implemented using QtWidgets. Main Features: - Wallpaper per virtual desktop - No animations, low memory and CPU footprint - Instant startup - No use of activities - 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 Frameworks 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. It also features PackageKit software updates integration. The DeviceList also shows devices connected and paired with KDEConnect. 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) I think the final place should be extragear. openSuse's OBS has already packages for some distributions Screenshots: http://members.aon.at/m.koller/liquidshell_20190310_light.png http://members.aon.at/m.koller/liquidshell_20190310_dark.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
Re: liquidshell in kdereview
On Montag, 11. März 2019 10:34:35 CET Tomaz Canabrava wrote: > On Sun, Mar 10, 2019 at 1:25 PM Martin Koller wrote: > > > > Hi, > > > > since some time has already passed and there was no conclusion, I'll try > > once again > > to announce liquidshell. > > > > I have made adjustments to the README which now says: > > > > liquidshell is a basic Desktop Shell implemented using QtWidgets. > > > > Main Features: > > - Wallpaper per virtual desktop > > - No animations, low memory and CPU footprint > > - Instant startup > > - No use of activities > > How apps that deal with activities will work on? they will just > silently ignore activities? Since I do not use activities, I have no idea. But since liquidshell does not even offer anything related to activities, why would an application face an issue with that in the first place ? -- 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
Re: liquidshell in kdereview
On Freitag, 12. April 2019 12:48:17 CEST Adriaan de Groot wrote: > On Sunday, March 10, 2019 1:25:14 PM CEST Martin Koller wrote: > > since some time has already passed and there was no conclusion, I'll try > > once again to announce liquidshell. > > # Documentation issues > > The features list, both in German and English, lists a bunch of features that > distinguish it from, say, twm, not from Plasma. I don't understand your point. What do you want me to change? > The feature list in English doesn't match the one in German. The English one > includes dubious claims such as "instant startup" and "low memory footprint", > which I'd still want to see measured and/or demonstrated. you can see them when you start liquidshell. What do you want me to change ? > Typo's in (English) README. > > # License issues > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > want > to add SPDX identifiers, but that would be the icing on the cake. Where, which and how would I need to add SPDX identifiers ? Where is this documented in KDE guidelines ? Here https://community.kde.org/Policies/Licensing_Policy I don't find anything. > # Source issues > > Doesn't report nicely at end of CMake (use FeatureSummary). included now > # Compatibility issues > > Fails to document that NetworkManager and BlueZ are required. Not sure I understand. The cmake file includes find_package(KF5 REQUIRED COMPONENTS for NetworkManagerQt and BluezQt > Uses bash for things that are POSIX shell scripts. What do you mean ? There is exactly one shellscript which is not build related: start_liquidshell it contains #!/bin/bash if you're referring to this. I did this since I remember having read that /bin/sh is not the correct way. > Those (two items) above are symptoms of "liquidshell is a shell for Martin > Koller and people with exactly his computer setup and workflow". "my workflow" - of course. "exactly his computer" - not so. E.g. it seems Arch Linux provides liquidshell: https://aur.archlinux.org/packages/liquidshell-git/ Also KaOS have included liquidshell https://linuxscoop.com/video/whats-new-kaos-2018-01 I'm using openSuse. > Since the KDE community has traditionally produced general, flexible > software, it's weird to > have a restricted, limited, non-flexible product as well. If you find liquidshell too limited and unflexible for you, don't use it. liquidshell's intent is exactly being this: simple and not over complex (aka general, flexible) -- 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
Re: liquidshell in kdereview
On Freitag, 12. April 2019 13:07:41 CEST Marco Martin wrote: > On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić wrote: > > Anyhow, while I do find it strange to market a non-feature in the features > > list, I don't have anything against it. > > I have a bit of a problem about putting doesn't use activities as a > feature, because it's a bit confrontational towards other KDE products > (and as you point out, often not 100% true as kactivitymanagerd will > be very probably started anyways) I have removed the mentioning of activities now > That said, i don't have problems of having a competing shell as a KDE > project, choice is usually good. Thanks for your open mind! -- 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
Re: liquidshell in kdereview
On Sonntag, 14. April 2019 12:44:20 CEST Adriaan de Groot wrote: > On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote: > > > # License issues > > > > > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > > > want to add SPDX identifiers, but that would be the icing on the cake. > > > > Where, which and how would I need to add SPDX identifiers ? > > You don't *need* to. Like I said, icing on the cake, which is like .. vanilla > sauce on the apfelstruedel. Makes it complete and wonderful, but it's > acceptable without it. > > SPDX identifiers are machine-readable, standardised, tags in source files > that > help tooling that works with licensing (meta) data. See spdx.org; something > like (off the top of my head, not necessarily the right identifier or format, > etc.) > > // SPDX-Identifier: GPLv2+ > > at the top of C++ source files does the trick. ok, done. > > Where is this documented in KDE guidelines ? > > Here > > https://community.kde.org/Policies/Licensing_Policy > > I don't find anything. > > It's not. should it ? > > > # Compatibility issues > > > > > > Fails to document that NetworkManager and BlueZ are required. > > > > Not sure I understand. > > Would have been nice to have that in the README, is what I mean. I'm not a fan of doing duplicate things. The cmake file is the ultimate source for specifying what the application depends on. Adding this somewhere else will easily get out of sync. -- 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
Re: liquidshell in kdereview
On Sonntag, 14. April 2019 23:34:43 CEST Luca Beltrame wrote: > Il giorno Sun, 14 Apr 2019 16:43:54 +0200 > Martin Koller ha scritto: > > > The cmake file is the ultimate source for specifying what the > > application depends on. Adding this somewhere else will easily get > > READMEs can be useful for packagers instead of manually watching the > output of CMake or reading CMakelists.txt (fine for simpler projects, > but not for large ones). since in this case we are talking about required software, the packager will not get the app compiled. I assume this will hit his attention. I would understand that optional dependencies are different since the app would build but not with all options. -- Best regards/Schöne Grüße Martin () ascii ribbon campaign - against html e-mail /\- against proprietary attachments
Re: What to do with KScanDialog
On Saturday 31 August 2013 23:11:57 Kåre Särs wrote: > I would vote to move it to kde4support and deprecate it. I can volunteer to > port kolourpaint to libksane if needed. Hi all, I'm the current maintainer of kolourpaint. I have no problem with using anything else than what's currently available. I'd be happy when Kåre would do the migration - he knows best how to use libksane. Thanks -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
Re: Review Request 113175: Always use an external viewer application to view files
On Tuesday 08 October 2013 20:35:01 Sven Brauch wrote: > > > On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote: > > > I'm not totally happy with this change. Yes, the internal viewer is > > > limited in functionality, but it has advantages: (1) it is fast to open > > > and can be closed again with a single keystroke; (2) it remembers its > > > size and can be resized without affecting the default window size of, > > > say, KWrite or whichever external application is used; (3) it can be > > > forced to display an archive component of any type as plain text. What is the advantage of having ark at all ? konqueror/dolphin can already open at least tar/(gz, bzip) and zip files directly and there you have all the functionality you are discussing currently (e.g. viewing the file according to defined association, right click menu, everything one would expect ... I don't know the drawbacks, so please enlighten me. Thanks. -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
Re: Review Request 113175: Always use an external viewer application to view files
On Saturday 19 October 2013 21:50:40 Emmanuel Pescosta wrote: > > konqueror/dolphin can already open at least tar/(gz, bzip) and zip files > directly > Dolphin can only browse through local archives, remote archives will be > opened in Ark. > > See DolphinView::openItemAsFolderUrl for more information. you think that ark can _directly_ browse into remote archives ? You're wrong. It also downloads a copy of the archive to the local filesystem. I tried to open a tar file via sftp:// -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
Re: Is kpovmodeler still valid or should it be removed
On Monday 10 March 2014 12:36:59 Burkhard Lück wrote: > extragear/graphics has more candidates for this question: > > kuickshow: > no development since > 4 years > needs an old no longer available library imlib1 to build > no deb packages provided BTW: I made a replacement application for this: http://kde-apps.org/content/show.php?content=143977 -- 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.bibibest.at
Re: Is kpovmodeler still valid or should it be removed
On Wednesday 12 March 2014 19:44:39 Albert Astals Cid wrote: > El Dimecres, 12 de març de 2014, a les 15:04:01, Martin Koller va escriure: > > On Monday 10 March 2014 12:36:59 Burkhard Lück wrote: > > > extragear/graphics has more candidates for this question: > > > > > > kuickshow: > > > no development since > 4 years > > > needs an old no longer available library imlib1 to build > > > no deb packages provided > > > > BTW: I made a replacement application for this: > > http://kde-apps.org/content/show.php?content=143977 > > Any reason this doesn't live in kde.org? good question. There's no reason (except that I'm still a noob in git usage ...) What are the steps to get the app into playground so that I can then request it to move to kdereview ? Or can I start in kdereview given that the app was already released 2 years ago ? (It's hard to find information on techbase regarding this. Most information is about svn and therefore outdated and I find nothing how to start a new app w.r.t to git repository) -- 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.bibibest.at
Review Request 121746: avoid wrong trash size calculation when removing file from trash and cached size info is wrong
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121746/ --- Review request for KDE Runtime and Tobias Koenig. Bugs: 245482 http://bugs.kde.org/show_bug.cgi?id=245482 Repository: kde-runtime Description --- The trash kio-slave stores the current trash size in a KConfig cache file. However it can happen that the information inside this file is wrong, e.g. when another (non-KDE) program puts some files into the trash. This happens e.g. by using the ebook management software "calibre" when I delete a book. calibre implements the FDO trash specification on its own and therefore knows nothing about the KDE size cachefile. This leads to the problem that when I move a file out of the trash which was put there by calibre, the subtraction underflows the cached size value resulting in a wrong huge absolute number, finally leading to the bug described here: https://bugs.kde.org/show_bug.cgi?id=245482 Diffs - kioslave/trash/trashsizecache.cpp 2fae964 Diff: https://git.reviewboard.kde.org/r/121746/diff/ Testing --- - unit tests - calibre Thanks, Martin Koller
Re: Review Request 121746: avoid wrong trash size calculation when removing file from trash and cached size info is wrong
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121746/ --- (Updated Dec. 29, 2014, 10:43 p.m.) Review request for KDE Runtime, David Faure and Tobias Koenig. Changes --- add David since the bug is assigned to him Bugs: 245482 http://bugs.kde.org/show_bug.cgi?id=245482 Repository: kde-runtime Description --- The trash kio-slave stores the current trash size in a KConfig cache file. However it can happen that the information inside this file is wrong, e.g. when another (non-KDE) program puts some files into the trash. This happens e.g. by using the ebook management software "calibre" when I delete a book. calibre implements the FDO trash specification on its own and therefore knows nothing about the KDE size cachefile. This leads to the problem that when I move a file out of the trash which was put there by calibre, the subtraction underflows the cached size value resulting in a wrong huge absolute number, finally leading to the bug described here: https://bugs.kde.org/show_bug.cgi?id=245482 Diffs - kioslave/trash/trashsizecache.cpp 2fae964 Diff: https://git.reviewboard.kde.org/r/121746/diff/ Testing --- - unit tests - calibre Thanks, Martin Koller
Re: Review Request 121746: avoid wrong trash size calculation when removing file from trash and cached size info is wrong
> On Dec. 29, 2014, 10:49 p.m., David Faure wrote: > > I'm confused. Are you patching old code? > > > > kde-runtime branch Applications/14.12 has my rewrite of this code to use > > the cache as per the trash spec v1.0, replacing the KConfig-based code. > > It solves that issue. > > > > See commit 591acfe8f5e281f416ee925e1ff160c0aac81163 in kde-runtime.git. obviously I use the wrong branch. Here on openSuse 13.1 I currently have KDE-4.14.3 and I thought this is the latest one ... But since you fixed the bug, why is it still open on bko ? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121746/#review72751 ------- On Dec. 29, 2014, 10:43 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121746/ > --- > > (Updated Dec. 29, 2014, 10:43 p.m.) > > > Review request for KDE Runtime, David Faure and Tobias Koenig. > > > Bugs: 245482 > http://bugs.kde.org/show_bug.cgi?id=245482 > > > Repository: kde-runtime > > > Description > --- > > The trash kio-slave stores the current trash size in a KConfig cache file. > However it can happen that the information inside this file is wrong, e.g. > when another (non-KDE) program puts some files into the trash. > This happens e.g. by using the ebook management software "calibre" when I > delete a book. calibre implements the FDO trash specification on its own and > therefore knows nothing about the KDE size cachefile. > > This leads to the problem that when I move a file out of the trash which was > put there by calibre, the subtraction underflows the cached size value > resulting in a wrong huge absolute number, finally leading to the bug > described here: > https://bugs.kde.org/show_bug.cgi?id=245482 > > > Diffs > - > > kioslave/trash/trashsizecache.cpp 2fae964 > > Diff: https://git.reviewboard.kde.org/r/121746/diff/ > > > Testing > --- > > - unit tests > - calibre > > > Thanks, > > Martin Koller > >
Re: Review Request 121746: avoid wrong trash size calculation when removing file from trash and cached size info is wrong
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121746/ --- (Updated Dec. 29, 2014, 11:08 p.m.) Status -- This change has been discarded. Review request for KDE Runtime, David Faure and Tobias Koenig. Bugs: 245482 http://bugs.kde.org/show_bug.cgi?id=245482 Repository: kde-runtime Description --- The trash kio-slave stores the current trash size in a KConfig cache file. However it can happen that the information inside this file is wrong, e.g. when another (non-KDE) program puts some files into the trash. This happens e.g. by using the ebook management software "calibre" when I delete a book. calibre implements the FDO trash specification on its own and therefore knows nothing about the KDE size cachefile. This leads to the problem that when I move a file out of the trash which was put there by calibre, the subtraction underflows the cached size value resulting in a wrong huge absolute number, finally leading to the bug described here: https://bugs.kde.org/show_bug.cgi?id=245482 Diffs - kioslave/trash/trashsizecache.cpp 2fae964 Diff: https://git.reviewboard.kde.org/r/121746/diff/ Testing --- - unit tests - calibre Thanks, Martin Koller
Re: Review Request 121746: avoid wrong trash size calculation when removing file from trash and cached size info is wrong
> On Dec. 29, 2014, 10:49 p.m., David Faure wrote: > > I'm confused. Are you patching old code? > > > > kde-runtime branch Applications/14.12 has my rewrite of this code to use > > the cache as per the trash spec v1.0, replacing the KConfig-based code. > > It solves that issue. > > > > See commit 591acfe8f5e281f416ee925e1ff160c0aac81163 in kde-runtime.git. > > Martin Koller wrote: > obviously I use the wrong branch. Here on openSuse 13.1 I currently have > KDE-4.14.3 and I thought this is the latest one ... > > But since you fixed the bug, why is it still open on bko ? > > David Faure wrote: > I implemented this because it was on my todo list after freedesktop > discussions. I didn't see the bug report (there are far too many for me to > keep up). I see, thanks for explanation. Will discard this review request. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121746/#review72751 ------- On Dec. 29, 2014, 10:43 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121746/ > --- > > (Updated Dec. 29, 2014, 10:43 p.m.) > > > Review request for KDE Runtime, David Faure and Tobias Koenig. > > > Bugs: 245482 > http://bugs.kde.org/show_bug.cgi?id=245482 > > > Repository: kde-runtime > > > Description > --- > > The trash kio-slave stores the current trash size in a KConfig cache file. > However it can happen that the information inside this file is wrong, e.g. > when another (non-KDE) program puts some files into the trash. > This happens e.g. by using the ebook management software "calibre" when I > delete a book. calibre implements the FDO trash specification on its own and > therefore knows nothing about the KDE size cachefile. > > This leads to the problem that when I move a file out of the trash which was > put there by calibre, the subtraction underflows the cached size value > resulting in a wrong huge absolute number, finally leading to the bug > described here: > https://bugs.kde.org/show_bug.cgi?id=245482 > > > Diffs > - > > kioslave/trash/trashsizecache.cpp 2fae964 > > Diff: https://git.reviewboard.kde.org/r/121746/diff/ > > > Testing > --- > > - unit tests > - calibre > > > Thanks, > > Martin Koller > >
kio man + khelpcenter
Hi, a recent update (openSuse TW, kio-extras5 Version: 21.08.1) had the effect that whenever I want to view a man page via Alt-F2 (Krunner) and e.g. "#ls", now khelpcenter is opened, instead konqueror, which I had before. What defines which application is started an how can I change this back to konqueror ? -- 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 Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at
global shortcuts
Hi, which component is responsible for acting on global shortcuts, e.g. what triggers that Alt-F2 is opening krunner ? -- 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 Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at
Re: kio man + khelpcenter
On Sonntag, 26. September 2021 21:53:12 CEST you wrote: > Martin Koller ha scritto: > > Hi, > > > > a recent update (openSuse TW, kio-extras5 Version: 21.08.1) had the effect > > that whenever I want to view a man page > > via Alt-F2 (Krunner) and e.g. "#ls", now khelpcenter is opened, instead > > konqueror, which I had before. > > What defines which application is started an how can I change this back to > > konqueror ? > > > > It was discussed in this thread: > > https://mail.kde.org/pipermail/kde-frameworks-devel/2021-September/119021.html I see that this issue was fixed 8 month ago for konqueror. Great, I can now again enter "#ls" in konqi and see the man page inside konqueror. However: using krunner and "#ls" still opens KDE Help Center, instead of konqueror. Where can I configure that this opens the man page in konqi, as it was before ? -- 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 Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at
Re: Kandalf: request for review
On Freitag, 15. Dezember 2023 00:29:19 CET Justin Zobel wrote: > I'm a fan of K when it's used well e.g. Kalendar or Kontact but not KMyApp "Kamel" (german for camel) which is a kind of Lama -- 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 Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at
git clone kde:kde-workspace hangs
Hi, I've tried already several times today to get a clone of kde-workspace and it always gets stuck at about 10-15% What can I do ? -- Best regards/Schöne Grüße Martin () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: git clone kde:kde-workspace hangs
On Sunday, 6. February 2011 23:54:07 Thiago Macieira wrote: > On Sunday, 6 de February de 2011 16:48:21 Shaun Reich wrote: > > On Sun, Feb 6, 2011 at 4:30 PM, Martin Koller wrote: > > > Hi, > > > > > > I've tried already several times today to get a clone of kde-workspace > > > and it always gets stuck at about 10-15% > > > > > > What can I do ? > > > > You can try using the tarball form on project.kde.org, for now (no idea why > > it hangs up). at least then you can resume it. > > Note that the git clone/fetch/push percentage is by number of objects, not > size. I have tried cloning kde-workspace now and it worked fine, but I did > notice a slowdown around 14-15%. My guess is that there are some big objects > being transferred. Thanks for the hint, but in my case my internet connection did not transfer anything during this hang (no LED activity on my router) even for 10 minutes or so ... Nevertheless, I've downloaded the tarball for now. -- Best regards/Schöne Grüße Martin () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Review Request: add some "currentView" 0-pointer checks in konqueror/src/konqmainwindow.cp
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101586/ --- Review request for KDE Base Apps. Summary --- add some "currentView" 0-pointer checks in konqueror/src/konqmainwindow.cpp to avoid crashes like #272557 This addresses bug 272557. http://bugs.kde.org/show_bug.cgi?id=272557 Diffs - konqueror/src/konqmainwindow.cpp a309f48 Diff: http://git.reviewboard.kde.org/r/101586/diff Testing --- Thanks, Martin
Re: Review Request: add some "currentView" 0-pointer checks in konqueror/src/konqmainwindow.cp
> On June 19, 2011, 11:15 p.m., Dawit Alemayehu wrote: > > Looks good, but can you also add Q_ASSERT(m_currentView) before the if > > (!m_currentView) checks so that in debug mode this will assert. The view > > should not be null and if it is someone needs to figure out why that is the > > case. as per our mail conversation: "Well if m_currentView can be NULL, then there is definitely no need to add a Q_ASSERT right ? I was not aware that it could be until you forwarded what David said ; so forget about my comment and handle it as David suggested." I found also now a way to actually make the current view disappear: start konqueror (in my case starts with empty page), select "Settings -> load view profile -> midnight commander" This closes the current view in konqi and opens a new window. Closing active view (Ctrl+Shift+W) crashes konqueror without this patch. I've committed/pushed it now - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101586/#review4036 ------- On June 11, 2011, 6:56 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101586/ > --- > > (Updated June 11, 2011, 6:56 p.m.) > > > Review request for KDE Base Apps. > > > Summary > --- > > add some "currentView" 0-pointer checks in konqueror/src/konqmainwindow.cpp > to avoid crashes like #272557 > > > This addresses bug 272557. > http://bugs.kde.org/show_bug.cgi?id=272557 > > > Diffs > - > > konqueror/src/konqmainwindow.cpp a309f48 > > Diff: http://git.reviewboard.kde.org/r/101586/diff > > > Testing > --- > > > Thanks, > > Martin > >
Go Daddy root certificates
Hi, can anyone answer the case https://bugs.kde.org/show_bug.cgi?id=277319 , please ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: Go Daddy root certificates
On Monday, 25. July 2011 02:10:56 Thiago Macieira wrote: > On Sunday, 24 de July de 2011 14:51:34 Gary Greene wrote: > > On Jul 23, 2011, at 10:33 AM, Martin Koller wrote: > > > Hi, > > > > > > can anyone answer the case https://bugs.kde.org/show_bug.cgi?id=277319 , > > > please ? > > Honestly, I really wish that Mozilla/KDE/Google/Wget/ > has their own root certificate store here> would get together on fdo and > > create a common project that the root certificates could be aggregated at > > instead of each project doing it themselves... > > The answer is: STOP distributing our own certificates. Rely on Qt's support, > which also doesn't distribute certificates. The burden then falls on the > system > integrator (the distros), which will select a root CA package that they feel > confident about. > > They're also the ones who can roll out security updates directly to the > users. > We can't. How does the resolution process work here in KDE - I mean: who has the final say that KDE stops (or doesn't stop) to deliver the certificates ? Can I close mentioned bko entry as INVALID or WONTFIX ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
KImageIO::mimeTypes and SVG/SVGZ Files
Hi, In my application I use KImageIO::mimeTypes to determine which formats I can load (e.g. the output of it is used in my .desktop file to fill in the MimeType definition). However I see that obviously Qt can already (to some degree) load .svg and .svgz files, but KImageIO::mimeTypes does not return image/svg+xml image/svg+xml-compressed The solution would be to add 2 new desktop files in kdelibs/kimgio (attached). This would automatically allow all image applications to also load these file types, as they are then allowed in the file selector as "supported format". However, Qt can not load all SVG files correctly ... Despite this fact, gwenview added these 2 MimeTypes as supported formats in the .desktop file, so I wonder if we can add these generally. Opinions ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at svg+xml.desktop Description: application/desktop svg+xml-compressed.desktop Description: application/desktop signature.asc Description: This is a digitally signed message part.
Re: KImageIO::mimeTypes and SVG/SVGZ Files
On Wednesday, 31. August 2011 11:13:49 Albert Astals Cid wrote: > > I think you don't need to add the [x-test] lines, they are generated > > by scripty, as far as I know. > > That's correct. ok, removed. But I have a general question: Why is there a "Name[lang]=" field at all ? The translation for the mime types is already given in the shared-mime-info database. -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: KImageIO::mimeTypes and SVG/SVGZ Files
On Wednesday, 31. August 2011 14:03:57 Allan Sandfeld Jensen wrote: > You should remember to also make the compressed type a subtype of the correct > compressed archive type. This way the file can be recognized and decompressed > even if no direct image/svg+xml-compressed handler is registered. Hmmm... not sure if I understand. In the shared-mime-info database file /usr/share/mime/image/svg+xml-compressed.xml there is already Is this information not used already ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: KImageIO::mimeTypes and SVG/SVGZ Files
On Wednesday, 31. August 2011 17:54:45 David Faure wrote: > The translated name is redundant indeed, though, it's not used, except when > looking at the servicetype's associated plugins in keditfiletype. even in keditfiletype I do not see where the name is used. E.g. using "keditfiletype image/png" I see nowhere only the name "PNG" which is inside the .desktop file. So the main question is: can't we simply get rid of the translation lines in these image.desktop files and save our translators some time ? (BTW: If the translation is not used/needed, I assume I do not need to ask the translation team for permission to add these new files in the 4.7 branch, right ?) Another question: the line X-KDE-ImageFormat seems to be used when I want to pass this format to e.g. QImage::save(). But I see here inconsistencies in the different .desktop files, where some include only the lowercase string, e.g. X-KDE-ImageFormat=gif others lower and uppercase, e.g. X-KDE-ImageFormat=eps,EPS,EPSI,epsf,EPSF (The latter is even more strange as EPSI has no lowercase version) Can this be simply made consistent so that all files only contain the lowercase version ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Wednesday, 12. October 2011 02:12:55 Thomas Lübking wrote: Let me give my view here: > Do you have configured a "saver" beyond dpms? > And if, why? > Do you use a locker beyond a black screen? > And if, why? yes to both (diashow). Reason: make other people wandering by (or sitting in the same room during a presentation when the screen content is currently not needed but the display is still shown with the beamer, e.g. lengthy discussions) aware of an OS called Linux and a desktop system called KDE. I show pictures from kde-look etc. showing the KDE and Linux logos. Note: I very seldom have my laptop running on battery. Mostly AC, so power saving is of no concern to me. -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Tuesday, 11. October 2011 21:11:03 Martin Gräßlin wrote: > > I consider most effects being "bling" yes, with that said I like it and > > appreciate it but still most effects add no real productive value. > I have to disagree. By default we ship no effect which is "bling" > only. They all add productive value. Even something like a fade effect is a > productive value and not bling as it makes the system a more natural thing to > use. I'm sorry but this makes me laugh. What productivity gain do I have when using the "Snow" or "wobbly windows" effect ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Re: [proposal] KSecretsService components moving from playground
On Wednesday, 12. October 2011 01:09:51 Valentin Rusu wrote: > > I personally have been looking forward to KSecretsService and I like > > the idea of leaving KSecretsService unused by default for now, but it > > should at least be stressed to downstream to leave it off by default > > and why you chose it to be off for this release, if you do decide to > > implement it for 4.8. I assume there is a reason you decided to leave > > it off by default? > Yes, I decided that precisely to avoid pitfalls I saw when KDE 4 > arrived. Let's put the code in for 4.8, voluntarily test it by > voluntarily checking that box, then put it on by default with the next > 2012 release. What about adding a "warning" text at the checkbox, e.g. "(experimental)" like with Linux kernel drivers when configuring which makes the status clear and brave people only will try to activate it ? -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Review Request: make KFileWidget keep current extension if possible
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102986/ --- Review request for kdelibs. Description --- In trying to fix mentioned bug, I found out the original problem lies in KFileWidget: If I'm editing a JPEG file which has the non-mainExtension ".jpg" and KFileWidget was told to auto-select an extension, then it did not check if the already given extension is one which is also allowed and simply removed ".jpg" and added ".jpeg", which is not what a user would expect. This patch now checks the current extension against all allowed extensions and if there's a match, it keeps the current extension. Only otherwise will it add the default extension. This addresses bug 229547. http://bugs.kde.org/show_bug.cgi?id=229547 Diffs - kfile/kfilewidget.cpp 09b86d4 Diff: http://git.reviewboard.kde.org/r/102986/diff/diff Testing --- Used kolourpaint with "name.jpg", "name.jpeg", "name.", "name", "name.tif", "name.tiff" Thanks, Martin Koller
Re: Review Request: make KFileWidget keep current extension if possible
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102986/ --- (Updated Nov. 17, 2011, 6:53 p.m.) Review request for kdelibs. Changes --- I'm now using KMimeType::extractKnownExtension as the set filter is not necessarily a MimeType filter (can be also just *.cpp etc.) And if the KFileWidget is used with an uncommon filter which is not a known MimeType, I fall back to get the last part of the filename after the dot as with my first patch. Description --- In trying to fix mentioned bug, I found out the original problem lies in KFileWidget: If I'm editing a JPEG file which has the non-mainExtension ".jpg" and KFileWidget was told to auto-select an extension, then it did not check if the already given extension is one which is also allowed and simply removed ".jpg" and added ".jpeg", which is not what a user would expect. This patch now checks the current extension against all allowed extensions and if there's a match, it keeps the current extension. Only otherwise will it add the default extension. This addresses bug 229547. http://bugs.kde.org/show_bug.cgi?id=229547 Diffs (updated) - kfile/kfilewidget.cpp 09b86d4 Diff: http://git.reviewboard.kde.org/r/102986/diff/diff Testing --- Used kolourpaint with "name.jpg", "name.jpeg", "name.", "name", "name.tif", "name.tiff" Thanks, Martin Koller
Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103699/ --- Review request for kdelibs. Description --- All KUniqueApplications issue the warning QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. when runngin with Qt-4.8.0 (qWarning in QDBusDefaultConnection ctor) The patch avoids this by temporarily creating a QCoreApplication instance Diffs - kdeui/kernel/kuniqueapplication.cpp 777fc35 Diff: http://git.reviewboard.kde.org/r/103699/diff/diff Testing --- running kdepasswd Thanks, Martin Koller
Re: Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
On Saturday, 14. January 2012 22:36:44 Thiago Macieira wrote:
> On Saturday, 14 de January de 2012 18.38.02, Martin Koller wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://git.reviewboard.kde.org/r/103699/
> > ---
> >
> > Review request for kdelibs.
> >
> >
> > Description
> > ---
> >
> > All KUniqueApplications issue the warning
> > QDBusConnection: session D-Bus connection created before QCoreApplication.
> > Application may misbehave. when runngin with Qt-4.8.0 (qWarning in
> > QDBusDefaultConnection ctor)
> >
> > The patch avoids this by temporarily creating a QCoreApplication instance
>
> If this is done before the fork, it's a REALLY BAD IDEA.
it is done after the fork (if there is a fork and not used with --nofork).
> If it's done after the fork, why is the connection created this early? I
> might
> have written this code, but I certainly don't remember it anymore.
According to the header doc KUniqueApplication shall be used like this:
...
*if (!KUniqueApplication::start()) {
* fprintf(stderr, "myAppName is already running!\n");
* return 0;
*}
*KUniqueApplication a;
*return a.exec();
So one of the very first things the static start() method does is to
open the session dbus, and this is before a QCoreApplication is available.
So my idea here was to create one and delete it afterwards, which should
result in the same state as before the call to tryToInitDBusConnection()
If that is a bad idea, i'd like to learn why and what can be done otherwise.
(One other workaround to get rid of the warning message would be to set up
an own message handler to discard this message, but I'd rather not do that...)
--
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
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
signature.asc
Description: This is a digitally signed message part.
Re: Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
On Sunday, 15. January 2012 11:47:10 Martin Koller wrote:
> On Saturday, 14. January 2012 22:36:44 Thiago Macieira wrote:
> > On Saturday, 14 de January de 2012 18.38.02, Martin Koller wrote:
> > > ---
> > > This is an automatically generated e-mail. To reply, visit:
> > > http://git.reviewboard.kde.org/r/103699/
> > > ---
> > >
> > > Review request for kdelibs.
> > >
> > >
> > > Description
> > > ---
> > >
> > > All KUniqueApplications issue the warning
> > > QDBusConnection: session D-Bus connection created before QCoreApplication.
> > > Application may misbehave. when runngin with Qt-4.8.0 (qWarning in
> > > QDBusDefaultConnection ctor)
> > >
> > > The patch avoids this by temporarily creating a QCoreApplication instance
> >
> > If this is done before the fork, it's a REALLY BAD IDEA.
>
> it is done after the fork (if there is a fork and not used with --nofork).
>
> > If it's done after the fork, why is the connection created this early? I
> > might
> > have written this code, but I certainly don't remember it anymore.
>
> According to the header doc KUniqueApplication shall be used like this:
>
> ...
>*if (!KUniqueApplication::start()) {
>* fprintf(stderr, "myAppName is already running!\n");
>* return 0;
>*}
>*KUniqueApplication a;
>*return a.exec();
>
> So one of the very first things the static start() method does is to
> open the session dbus, and this is before a QCoreApplication is available.
>
> So my idea here was to create one and delete it afterwards, which should
> result in the same state as before the call to tryToInitDBusConnection()
>
> If that is a bad idea, i'd like to learn why and what can be done otherwise.
> (One other workaround to get rid of the warning message would be to set up
> an own message handler to discard this message, but I'd rather not do that...)
ok, I see why this is a bad idea: The Qt doc says:
"... the sessionBus() and systemBus() ...
Those connections are opened when first used and are closed when the
QCoreApplication destructor is run."
so it seems the return value of tryToInitDBusConnection() is no longer valid
when the QCoreApplication
was destroyed before ...
Hmmm... When the check for uniqueness needs a coreapplication object, but
KUniqueApplication
is designed in this way to create the coreapplication after checking ... this
is a problem.
It seems creating and deleting QCoreApplication can really only be done once in
a process ...
Any idea how to solve this ?
--
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
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
signature.asc
Description: This is a digitally signed message part.
Re: Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103699/ --- (Updated Jan. 15, 2012, 5:28 p.m.) Review request for kdelibs. Changes --- Don't create QCoreApplication but an own session bus QDBusConnection object. Description --- All KUniqueApplications issue the warning QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. when runngin with Qt-4.8.0 (qWarning in QDBusDefaultConnection ctor) The patch avoids this by temporarily creating a QCoreApplication instance Diffs (updated) - kdeui/kernel/kuniqueapplication.cpp 777fc35 Diff: http://git.reviewboard.kde.org/r/103699/diff/diff Testing --- running kdepasswd Thanks, Martin Koller
Re: Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
On Sunday, 15. January 2012 13:18:58 Thiago Macieira wrote:
> On Sunday, 15 de January de 2012 11.47.10, Martin Koller wrote:
> >*if (!KUniqueApplication::start()) {
> >* fprintf(stderr, "myAppName is already running!\n");
> >* return 0;
> >*}
> >*KUniqueApplication a;
> >*return a.exec();
> >
> > So one of the very first things the static start() method does is to
> > open the session dbus, and this is before a QCoreApplication is available.
>
> It should open a session bus connection, but not *the*
> QDBusConnection::sessionBus() connection.
>
> I know I designed the code like that. You can't open it before because that
> would mean the file descriptor is opened in the wrong process. So where is
> the
> warninig coming from?
qWarning is in QDBusDefaultConnection ctor
> Did I place the warning in the wrong object in QtDBus?
> Or is there something *else* creating that connection?
no, it's the call to QDBusConnection::sessionBus()
which creates the QDBusDefaultConnection object which throws that warning.
> Your description still requires the QCoreApplication object to be created
> before the fork. It doesn't matter that you're going to close that open and
> open a new one after the fork: it's still a bad idea. Some Unix operations do
> not survive forks, like creation of threads. If you do that, I'm pretty sure
> QProcess will be irreparably broken.
Sorry, I don't understand that.
Nevertheless, I tried now what you've suggested above, namely to create my own
QDBusConnection object to the session bus. This seems to work now, however
as I'm new to DBus, I do not fully understand everything.
What I've found out is that the KUniqueApplication's DBus call to
/MainApplication
only works if I create a QDBusConnection object on the session bus only if it
uses the same name as the Qt-internal QDBusDefaultConnection object, which is
"qt_default_session_bus", even when I would create my QDBusConnection objects
in the way that they live as long as the app lives.
Does that mean that a registered Object on DBus is linked to the
QDBusConnection's name ?
I've updated the diff https://git.reviewboard.kde.org/r/103699/diff/2/
--
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
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
signature.asc
Description: This is a digitally signed message part.
KPushButton and deprecated setIcon ?
Hi,
I'm developing a new KDE application and use designer for the UI.
In designer I can set the icon for a KPushButton to a name in the field "Theme"
which results in a call to
QIcon icon(QIcon::fromTheme(QString::fromUtf8("contact-new")));
newCustomer->setIcon(icon);
However I get a compiler warning due to setIcon being defined as deprecated with
the following comment:
* Sets the pixmap for this button. Rarely used. This one exists mostly for
usage in Qt designer,
* with icons embedded into the ui file. But you should rather save them
separately, and load them
* with KIcon("name") so that the icons are themeable.
*/
#ifndef KDE_NO_DEPRECATED
KDE_DEPRECATED void setIcon( const QIcon &pix );
I assume this deprecation was done before Qt itself had the possibility to load
an icon from a theme ?
So should the KDE_DEPRECATED be simply removed ?
--
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
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
signature.asc
Description: This is a digitally signed message part.
Review Request: remove KDE_NO_DEPRECATED from KPushButton::setIcon( const QIcon &pix );
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104084/ --- Review request for kdelibs and David Faure. Description --- remove KDE_NO_DEPRECATED from KPushButton::setIcon( const QIcon &pix ); since QIcon can already load icons from the theme. The diff is against KDE/4.8 - to which branch shall I commit ? Diffs - kdeui/widgets/kpushbutton.h 279ac5e kdeui/widgets/kpushbutton.cpp 6e45631 Diff: http://git.reviewboard.kde.org/r/104084/diff/ Testing --- compiled kdelibs Thanks, Martin Koller
Re: Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
> On June 15, 2012, 11:38 p.m., Steven Sroka wrote: > > Martin, what's the status of this patch? I think a bunch of bug reports on > > bko are waiting to get closed ;) There was a mail thread on core-devel for this and Thiago Macieira said it's the wrong approach. I'll remove the patch ... - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103699/#review14773 --- On Jan. 15, 2012, 5:28 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103699/ > --- > > (Updated Jan. 15, 2012, 5:28 p.m.) > > > Review request for kdelibs. > > > Description > --- > > All KUniqueApplications issue the warning > QDBusConnection: session D-Bus connection created before QCoreApplication. > Application may misbehave. > when runngin with Qt-4.8.0 (qWarning in QDBusDefaultConnection ctor) > > The patch avoids this by temporarily creating a QCoreApplication instance > > > Diffs > - > > kdeui/kernel/kuniqueapplication.cpp 777fc35 > > Diff: http://git.reviewboard.kde.org/r/103699/diff/ > > > Testing > --- > > running kdepasswd > > > Thanks, > > Martin Koller > >
Review Request: konqueror shall allow to click a mailto: link without showing a (...this URL is untrusted...) confirmation dialog
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105395/
---
Review request for kdelibs.
Description
---
When a non-local webpage contains a mailto: link and you click on it, konqueror
shows a confirmation dialog:
This untrusted page links to
mailto: some.name@some.domain.
Do you want to follow the link?
(using the page with opera or firefox does not give any such warning and opens
kmail)
The check is done by KAuthorized:authorizeUrlAction("redirect", pageURL,
linkURL);
This patch fixes this by always allowing a redirection to a mailto link.
Diffs
-
kdecore/kernel/kauthorized.cpp f7d795a
Diff: http://git.reviewboard.kde.org/r/105395/diff/
Testing
---
The following simple html page when
the page is served from a local running HTTP Server
( http://localhost:8080/data/test.html )
mailto:test.t...@test.at";>test.t...@test.at
Thanks,
Martin Koller
khtml/kmultipart/kmultipart.cpp uses wrong signal
Hi, for this trivial bugfix I'd rather not go through reviewboard: Error: Object::connect: No such signal KHTMLPartBrowserExtension::openURLNotify() Object::connect: (sender name: 'KHTMLBrowserExtension') Object::connect: No such signal KHTMLPartBrowserExtension::setLocationBarURL(QString) Object::connect: (sender name: 'KHTMLBrowserExtension') Patch: --- a/khtml/kmultipart/kmultipart.cpp +++ b/khtml/kmultipart/kmultipart.cpp @@ -356,8 +356,8 @@ void KMultiPart::setPart( const QString& mimeType ) // Forward signals from the part's browser extension // this is very related (but not exactly like) KHTMLPart::processObjectRequest -connect( childExtension, SIGNAL(openURLNotify()), - m_extension, SIGNAL(openURLNotify()) ); +connect( childExtension, SIGNAL(openUrlNotify()), + m_extension, SIGNAL(openUrlNotify()) ); connect( childExtension, SIGNAL(openUrlRequestDelayed(KUrl,KParts::OpenUrlArguments,KParts::BrowserArguments)), m_extension, SIGNAL(openUrlRequest(KUrl,KParts::OpenUrlArguments,KParts::BrowserArguments)) ); @@ -380,8 +380,8 @@ void KMultiPart::setPart( const QString& mimeType ) connect( childExtension, SIGNAL(enableAction(const char*,bool)), m_extension, SIGNAL(enableAction(const char*,bool)) ); -connect( childExtension, SIGNAL(setLocationBarURL(QString)), - m_extension, SIGNAL(setLocationBarURL(QString)) ); +connect( childExtension, SIGNAL(setLocationBarUrl(QString)), + m_extension, SIGNAL(setLocationBarUrl(QString)) ); connect( childExtension, SIGNAL(setIconUrl(KUrl)), m_extension, SIGNAL(setIconUrl(KUrl)) ); connect( childExtension, SIGNAL(loadingProgress(int)), -- 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 /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at signature.asc Description: This is a digitally signed message part.
Review Request: khtml/kmultipart/kmultipart.cpp uses wrong signal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105552/ --- Review request for kdelibs and David Faure. Description --- khtml/kmultipart/kmultipart.cpp uses wrong signal (obviously a porting error) Error: Object::connect: No such signal KHTMLPartBrowserExtension::openURLNotify() Object::connect: (sender name: 'KHTMLBrowserExtension') Object::connect: No such signal KHTMLPartBrowserExtension::setLocationBarURL(QString) Object::connect: (sender name: 'KHTMLBrowserExtension') Diffs - khtml/kmultipart/kmultipart.cpp fe531e5 Diff: http://git.reviewboard.kde.org/r/105552/diff/ Testing --- Thanks, Martin Koller
KIO::UDSEntry and URL encoding
Hi,
(using 4.9.0)
when using konqueror and typing "man:" it starts to list possible entries which
the kio_man slave generates.
However, konqueror displays percent encoded URLs, e.g. "man:%281%29/" instead
of "man:(1)/"
kio_man creates the KIO::UDSEntry as follows:
QString name = "man:/(" + *it + ')';
uds_entry.insert( KIO::UDSEntry::UDS_NAME, sectionName( *it ) );
uds_entry.insert( KIO::UDSEntry::UDS_URL, name );
(sectionName(...) delivers a human readable text)
What I do not find in the KIO::UDSEntry documentation is if the URL should use
percent encoded strings or not.
However doing a simple test where I explicitely use QString name = "man:/%28" +
*it + "%29";
does not work either.
Is this a general problem in konqueror (or the combobox it uses or I don't know
where in kdelibs) or do I
have to change something in kio_man ?
--
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
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
signature.asc
Description: This is a digitally signed message part.
Review Request: avoid duplicate entries in konqueror address completion list
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106046/ --- Review request for KDE Base Apps. Description --- When opening e.g. "man:mdoc.samples" as URL in konqueror, the next time I type "man:mdoc" konqueror shows "man:mdoc, man:mdoc.samples, man:mdoc.samples" in the completion box (history list is added to completion list giving duplicates) This patch simply avoids having duplicates in that list. Diffs - konqueror/src/konqmainwindow.cpp c5468f9 Diff: http://git.reviewboard.kde.org/r/106046/diff/ Testing --- yes Thanks, Martin Koller
Re: KIO::UDSEntry and URL encoding
On Monday, 13. August 2012 16:03:48 Thiago Macieira wrote:
> On segunda-feira, 13 de agosto de 2012 14.28.02, Martin Koller wrote:
> > Hi,
> > (using 4.9.0)
> >
> > when using konqueror and typing "man:" it starts to list possible entries
> > which the kio_man slave generates. However, konqueror displays percent
> > encoded URLs, e.g. "man:%281%29/" instead of "man:(1)/" kio_man creates the
> > KIO::UDSEntry as follows:
> >
> > QString name = "man:/(" + *it + ')';
> > uds_entry.insert( KIO::UDSEntry::UDS_NAME, sectionName( *it ) );
> > uds_entry.insert( KIO::UDSEntry::UDS_URL, name );
> >
> > (sectionName(...) delivers a human readable text)
> >
> > What I do not find in the KIO::UDSEntry documentation is if the URL should
> > use percent encoded strings or not. However doing a simple test where I
> > explicitely use QString name = "man:/%28" + *it + "%29"; does not work
> > either.
>
> That's not a decision of UDSEntry. That's a decision of who's displaying the
> URL.
>
> The two URLs are equivalent, so there's nothing wrong with the encoding. It's
> just a matter of whether konqueror decides to decode the parentheses.
>
> > Is this a general problem in konqueror (or the combobox it uses or I don't
> > know where in kdelibs) or do I have to change something in kio_man ?
>
> It's not a problem. The behaviour you're describing is "general" though.
Well, it's a problem for the user.
I found out that the culprit is KUrlCompletion, which - for whatever reason -
uses QUrl::toPercentEncoding() when an URL is to be shown.
I also found out that Qt seems to have a "bug" (in quotes because as you said
percent encoding
is equivalent to unecoded chars): QUrl::toPercentEncoding() defines unreserved
chars as:
Unreserved is defined as: ALPHA / DIGIT / "-" / "." / "_" / "~"
but rfc2396 defines this set as:
unreserved = alphanum | mark
mark= "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
I'd like to fix the problem in KUrlCompletion and tried to simply add an
additional
exclude array of "()!*'", which at least makes man:(1)/ etc. URLs human
readable.
However, I see that there is still some inconsistency in what konqueror shows
in its
completion list. E.g. when typing "man:mklos" it shows "man:mklost%2Bfound" in
the completion list,
but when I select this entry, the URL in the address line edit is changed and
displays as
"man:mklost+found"
Even worse: when I now again type "man:mklos", I get 2 entries in the
completion list
"man:mklost%2Bfound" and "man:mklost+found" (the one coming from the
completion, the other from the history)
No matter which one I chose, the result in the address line edit is always the
unencoded one, which
- for a user - makes much more sense.
So my main question is: would it hurt anyone to simply completely get rid of
QUrl::toPercentEncoding()
in the KUrlCompletion implementation ?
Why would I ever want to get a percent encoded string from a completer, which
is about helping a human ?
--
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
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
signature.asc
Description: This is a digitally signed message part.
Re: Review Request: avoid duplicate entries in konqueror address completion list
> On Aug. 15, 2012, 7:05 p.m., Mark Gaiser wrote: > > I don't know the konqueror code, but i don't think this is the right way to > > do it. Imho it shouldn't even be inserted in the first place. Though > > someone else would have to confirm. Well, I see it this way: there is the list of completion strings coming from the completer. And there is the history. Both things shall be shown here. "should not be inserted" is what this patch is about, by filtering the ones which are in both lists. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106046/#review17474 ------- On Aug. 15, 2012, 5:24 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106046/ > --- > > (Updated Aug. 15, 2012, 5:24 p.m.) > > > Review request for KDE Base Apps. > > > Description > --- > > When opening e.g. "man:mdoc.samples" as URL in konqueror, the next time I > type "man:mdoc" konqueror shows "man:mdoc, man:mdoc.samples, > man:mdoc.samples" in the completion box (history list is added to completion > list giving duplicates) > This patch simply avoids having duplicates in that list. > > > Diffs > - > > konqueror/src/konqmainwindow.cpp c5468f9 > > Diff: http://git.reviewboard.kde.org/r/106046/diff/ > > > Testing > --- > > yes > > > Thanks, > > Martin Koller > >
Review Request: in KUrlCompletion do not percent encode to make it human readable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106096/ --- Review request for kdelibs, David Faure and Thiago Macieira. Description --- when using konqueror and typing "man:" it starts to list possible entries which the kio_man slave generates. However, konqueror displays percent encoded URLs, e.g. "man:%281%29/" instead of "man:(1)/", which is not human readable. Also, there is some inconsistency in what konqueror shows in its completion list. E.g. when typing "man:mklos" it shows "man:mklost%2Bfound" in the completion list, but when I select this entry, the URL in the address line edit is changed and displays as "man:mklost+found" Even worse: when I now again type "man:mklos", I get 2 entries in the completion list "man:mklost%2Bfound" and "man:mklost+found" (the one coming from the completion, the other from the history) No matter which one I chose, the result in the address line edit is always the unencoded one, which - for a user - makes much more sense. This patch removes the calls to make the matches percent encoded. Why would I ever want to get a percent encoded string from a completer, which is about helping a human ? Diffs - kio/kio/kurlcompletion.cpp 269fdc1 Diff: http://git.reviewboard.kde.org/r/106096/diff/ Testing --- man:, fish:, local dir /tmp and checking the completion in konqueror when using a dir e.g. named "some ö ä ü umlauts", "some file with#anchor" Thanks, Martin Koller
Re: Review Request: in KUrlCompletion do not percent encode to make it human readable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106096/ --- (Updated Aug. 20, 2012, 1:51 p.m.) Review request for kdelibs, David Faure and Thiago Macieira. Description --- when using konqueror and typing "man:" it starts to list possible entries which the kio_man slave generates. However, konqueror displays percent encoded URLs, e.g. "man:%281%29/" instead of "man:(1)/", which is not human readable. Also, there is some inconsistency in what konqueror shows in its completion list. E.g. when typing "man:mklos" it shows "man:mklost%2Bfound" in the completion list, but when I select this entry, the URL in the address line edit is changed and displays as "man:mklost+found" Even worse: when I now again type "man:mklos", I get 2 entries in the completion list "man:mklost%2Bfound" and "man:mklost+found" (the one coming from the completion, the other from the history) No matter which one I chose, the result in the address line edit is always the unencoded one, which - for a user - makes much more sense. This patch removes the calls to make the matches percent encoded. Why would I ever want to get a percent encoded string from a completer, which is about helping a human ? Diffs - kio/kio/kurlcompletion.cpp 269fdc1 Diff: http://git.reviewboard.kde.org/r/106096/diff/ Testing --- man:, fish:, local dir /tmp and checking the completion in konqueror when using a dir e.g. named "some ö ä ü umlauts", "some file with#anchor" Thanks, Martin Koller
Re: Review Request: in KUrlCompletion do not percent encode to make it human readable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106096/ --- (Updated Aug. 20, 2012, 1:51 p.m.) Review request for kdelibs, David Faure and Thiago Macieira. Description --- when using konqueror and typing "man:" it starts to list possible entries which the kio_man slave generates. However, konqueror displays percent encoded URLs, e.g. "man:%281%29/" instead of "man:(1)/", which is not human readable. Also, there is some inconsistency in what konqueror shows in its completion list. E.g. when typing "man:mklos" it shows "man:mklost%2Bfound" in the completion list, but when I select this entry, the URL in the address line edit is changed and displays as "man:mklost+found" Even worse: when I now again type "man:mklos", I get 2 entries in the completion list "man:mklost%2Bfound" and "man:mklost+found" (the one coming from the completion, the other from the history) No matter which one I chose, the result in the address line edit is always the unencoded one, which - for a user - makes much more sense. This patch removes the calls to make the matches percent encoded. Why would I ever want to get a percent encoded string from a completer, which is about helping a human ? Diffs - kio/kio/kurlcompletion.cpp 269fdc1 Diff: http://git.reviewboard.kde.org/r/106096/diff/ Testing --- man:, fish:, local dir /tmp and checking the completion in konqueror when using a dir e.g. named "some ö ä ü umlauts", "some file with#anchor" Thanks, Martin Koller
