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 > >
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
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
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. 24, 2012, 4:01 p.m.) Review request for kdelibs, David Faure and Thiago Macieira. Changes --- according to Davids comment I changed the patch now so that instead of using QUrl::toPercentEncoding() I'm using now KUrl::prettyUrl() to only encode the necessary characters and have the rest human readable. 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 ? This addresses bug 141157. http://bugs.kde.org/show_bug.cgi?id=141157 Diffs (updated) - kio/kio/kurlcompletion.cpp 269fdc1 Diff: http://git.reviewboard.kde.org/r/106096/diff/ Testing (updated) --- man:, fish:, local dir /tmp and checking the completion in konqueror when using a dir e.g. named "some ö ä ü umlauts", "some file with#anchor" (this is a file literally named like this). Tested also the case mentioned in bug #141157 with the zip ioslave Thanks, Martin Koller
Review Request: elide completion entries in the middle in konq-address completion list
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106183/ --- Review request for KDE Base Apps and David Faure. Description --- Currently the completion list shows the URLs as right-elided entries, which, as described in the bug report, is not optimal. For filenames and man pages at least middle-elide is much more sensible. This addresses bug 111821. http://bugs.kde.org/show_bug.cgi?id=111821 Diffs - konqueror/src/konqcombo.cpp 8169aec Diff: http://git.reviewboard.kde.org/r/106183/diff/ Testing --- local dirs, www, man pages Thanks, Martin Koller
Review Request: konqueror: strip new line character from URL on paste automatically
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106184/ --- Review request for KDE Base Apps and David Faure. Description --- This patch removes line-breaking chars when an URL is entered. Very handy if you paste URLs from e.g. an email which shows the complete URL broken into multiple lines. This addresses bug 159002. http://bugs.kde.org/show_bug.cgi?id=159002 Diffs - konqueror/src/konqcombo.h 5c86fcd konqueror/src/konqcombo.cpp 8169aec Diff: http://git.reviewboard.kde.org/r/106184/diff/ Testing --- yes Thanks, Martin Koller
Re: Review Request: konqueror: strip new line character from URL on paste automatically
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106184/ --- (Updated Aug. 25, 2012, 7:56 p.m.) Review request for KDE Base Apps and David Faure. Changes --- changed connect as suggested (why is normalization needed ? for performance only ?) Description --- This patch removes line-breaking chars when an URL is entered. Very handy if you paste URLs from e.g. an email which shows the complete URL broken into multiple lines. This addresses bug 159002. http://bugs.kde.org/show_bug.cgi?id=159002 Diffs (updated) - konqueror/src/konqcombo.h 5c86fcd konqueror/src/konqcombo.cpp 8169aec Diff: http://git.reviewboard.kde.org/r/106184/diff/ Testing --- yes Thanks, Martin Koller
Re: Review Request: konqueror: strip new line character from URL on paste automatically
> On Aug. 25, 2012, 10:15 p.m., David Faure wrote: > > Looks good. I'm not sure where the need for ParagraphSeparator and > > LineSeparator comes from though, do websites actually use that? I found these two in QChar and thought it might happen that the clipboard contains not \n but one of these two. So I don't know if that ever happens but I thought id does not hurt either. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106184/#review18003 --- On Aug. 25, 2012, 7:56 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106184/ > --- > > (Updated Aug. 25, 2012, 7:56 p.m.) > > > Review request for KDE Base Apps and David Faure. > > > Description > --- > > This patch removes line-breaking chars when an URL is entered. > Very handy if you paste URLs from e.g. an email which shows the complete URL > broken into multiple lines. > > > This addresses bug 159002. > http://bugs.kde.org/show_bug.cgi?id=159002 > > > Diffs > - > > konqueror/src/konqcombo.h 5c86fcd > konqueror/src/konqcombo.cpp 8169aec > > Diff: http://git.reviewboard.kde.org/r/106184/diff/ > > > Testing > --- > > yes > > > Thanks, > > Martin Koller > >
Review Request: fix bounding box in EPS kimgio plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106290/ --- Review request for kdelibs. Description --- this very old bug reappeared. Obviously Qt internals have changed since then. This patch fixes the bounding box to be the real image width/height This addresses bug 85217. http://bugs.kde.org/show_bug.cgi?id=85217 Diffs - kimgio/eps.cpp dc09619 Diff: http://git.reviewboard.kde.org/r/106290/diff/ Testing --- With a Qt only prog and with my fix and kolourpaint Thanks, Martin Koller
Review Request: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/ --- Review request for kdelibs. Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru The patch is missing a cmake rule to make it optional, though, but I sent a mail to KDE-core list in the hope someone knows... This addresses bug 267365. http://bugs.kde.org/show_bug.cgi?id=267365 Diffs - kimgio/webp.cpp PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/webp.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106300/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
new WebP image plugin (kimgio) and cmake question
Hi all, I've implemented a new kimgio plugin for the WebP image format. read/write with variable quality is supported. I hope you can help me with the following questions: - how do I have to change the CMakeLists.txt file, so that this new plugin is optional depending on if the libwebp headers are installed ? cmake does not offer a FindWebP module and I know nearly nothing about cmake - how can I add a new MIME Type for image/x-webp ? - given that this is in kdelibs, in which branch could I commit this ? I did already create a review request: https://git.reviewboard.kde.org/r/106300/ -- 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: add kimgio WebP image format plugin
> On Sept. 1, 2012, 1:20 p.m., Christoph Feck wrote: > > kimgio/webp.cpp, line 5 > > <http://git.reviewboard.kde.org/r/106300/diff/1/?file=82610#file82610line5> > > > > We need to be more verbose here, it has to state the versions, and a > > pointer where to get the license text. Please check the KDE licensing page > > for correct texts. Note: I copied the license lines from xview.cpp I've changed my files now according to the KDE policy, but probably someone should also change the older files > On Sept. 1, 2012, 1:20 p.m., Christoph Feck wrote: > > kimgio/webp.cpp, line 49 > > <http://git.reviewboard.kde.org/r/106300/diff/1/?file=82610#file82610line49> > > > > Needs to check image.isValid() before writing data via scanLine() > > pointers. The allocation may fail because of too large width*height. > > > > Additionally, I would like the loader to return a Format_RGB32 image, > > when the data did not contain an alpha component. QImage has no isValid() method. Also I find no hint in QImage docu that it _can_ be invalid after this constructor. Regarding alpha: the version of the WebP library I have installed on openSuse 12.1 (0.1.2) does not have a function to check if the image has alpha data. On the Google page https://developers.google.com/speed/webp/docs/api?hl=ru I find the function WebPGetFeatures() but as said, my version does not have it. > On Sept. 1, 2012, 1:20 p.m., Christoph Feck wrote: > > kimgio/webp.cpp, line 87 > > <http://git.reviewboard.kde.org/r/106300/diff/1/?file=82610#file82610line87> > > > > Same here, should handle pure RGB case. Same problem as above. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/#review18386 --- On Sept. 1, 2012, 8:33 a.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106300/ > --- > > (Updated Sept. 1, 2012, 8:33 a.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch adds support for the new Google invented WebP image format. See > https://developers.google.com/speed/webp/?hl=ru > > The patch is missing a cmake rule to make it optional, though, but I sent a > mail to KDE-core list in the hope someone knows... > > > This addresses bug 267365. > http://bugs.kde.org/show_bug.cgi?id=267365 > > > Diffs > - > > kimgio/webp.cpp PRE-CREATION > kimgio/webp.desktop PRE-CREATION > kimgio/webp.h PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/106300/diff/ > > > Testing > --- > > some KDE apps, including read/write with a modified kolourpaint (to be able > to change the quality) > > > Thanks, > > Martin Koller > >
Re: Review Request: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/ --- (Updated Sept. 1, 2012, 9:23 p.m.) Review request for kdelibs. Changes --- changes as per comments Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru The patch is missing a cmake rule to make it optional, though, but I sent a mail to KDE-core list in the hope someone knows... This addresses bug 267365. http://bugs.kde.org/show_bug.cgi?id=267365 Diffs (updated) - kimgio/CMakeLists.txt 26329c0 kimgio/webp.cpp PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/webp.h PRE-CREATION mimetypes/kde.xml a82b87c Diff: http://git.reviewboard.kde.org/r/106300/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Re: Review Request 106300: add kimgio WebP image format plugin
> On Sept. 10, 2012, 10:48 p.m., Allan Sandfeld Jensen wrote: > > kimgio/webp.cpp, lines 67-73 > > <http://git.reviewboard.kde.org/r/106300/diff/2/?file=82722#file82722line67> > > > > This seems needlessly explicit, why not just copy the whole block into > > QImage? QImage::scanLine docu says "the pixel format depends on the byte order on the underlying platform." So to be sure to create correct rgba tuples, I explicitely pass the values to qRgba/qRgb > On Sept. 10, 2012, 10:48 p.m., Allan Sandfeld Jensen wrote: > > kimgio/webp.cpp, lines 92-100 > > <http://git.reviewboard.kde.org/r/106300/diff/2/?file=82722#file82722line92> > > > > Same as for decoding. Why copy it color by color like this, when the > > formats are identical? Same answer as above: scanLine data depends on the machines byte order, but WebP has always the same data representation > On Sept. 10, 2012, 10:48 p.m., Allan Sandfeld Jensen wrote: > > kimgio/webp.cpp, line 127 > > <http://git.reviewboard.kde.org/r/106300/diff/2/?file=82722#file82722line127> > > > > Not really required, but it would be nice to support the Size option. > > It is quite often used, and should be available through WebPGetInfo() ok, added > On Sept. 10, 2012, 10:48 p.m., Allan Sandfeld Jensen wrote: > > kimgio/webp.cpp, line 159 > > <http://git.reviewboard.kde.org/r/106300/diff/2/?file=82722#file82722line159> > > > > Should it also require "VP8 " in byte 12 to 16, to protect against new > > unsupported versions? > > > > For some reason I have code that checks the file is atleast 32 bytes > > long, I think that is because it is what WePGetInfo requires. not really. The spec says that the WebP header is 12 bytes and contains what I check. There is an Extended file format which starts with a ‘VP8X’ chunk (can currently contain "VP8 " or "VP8L") but as I do not interpret that VP8 data, why restrict the reader to it? Maybe a future libwebp supports something else than VP8 after the WebP Header ... - Martin ------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/#review18829 --- On Sept. 1, 2012, 9:23 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106300/ > --- > > (Updated Sept. 1, 2012, 9:23 p.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch adds support for the new Google invented WebP image format. See > https://developers.google.com/speed/webp/?hl=ru > > The patch is missing a cmake rule to make it optional, though, but I sent a > mail to KDE-core list in the hope someone knows... > > > This addresses bug 267365. > http://bugs.kde.org/show_bug.cgi?id=267365 > > > Diffs > - > > kimgio/CMakeLists.txt 26329c0 > kimgio/webp.cpp PRE-CREATION > kimgio/webp.desktop PRE-CREATION > kimgio/webp.h PRE-CREATION > mimetypes/kde.xml a82b87c > > Diff: http://git.reviewboard.kde.org/r/106300/diff/ > > > Testing > --- > > some KDE apps, including read/write with a modified kolourpaint (to be able > to change the quality) > > > Thanks, > > Martin Koller > >
Re: Review Request 106300: add kimgio WebP image format plugin
> On April 10, 2013, 10:52 p.m., Albert Astals Cid wrote: > > Martin, can you clarify Allan's comments? done - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/#review30892 --- On Sept. 1, 2012, 9:23 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106300/ > --- > > (Updated Sept. 1, 2012, 9:23 p.m.) > > > Review request for kdelibs. > > > Description > --- > > This patch adds support for the new Google invented WebP image format. See > https://developers.google.com/speed/webp/?hl=ru > > The patch is missing a cmake rule to make it optional, though, but I sent a > mail to KDE-core list in the hope someone knows... > > > This addresses bug 267365. > http://bugs.kde.org/show_bug.cgi?id=267365 > > > Diffs > - > > kimgio/CMakeLists.txt 26329c0 > kimgio/webp.cpp PRE-CREATION > kimgio/webp.desktop PRE-CREATION > kimgio/webp.h PRE-CREATION > mimetypes/kde.xml a82b87c > > Diff: http://git.reviewboard.kde.org/r/106300/diff/ > > > Testing > --- > > some KDE apps, including read/write with a modified kolourpaint (to be able > to change the quality) > > > Thanks, > > Martin Koller > >
Re: Review Request 106300: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/ --- (Updated May 9, 2013, 6:20 p.m.) Review request for kdelibs. Changes --- added answers to comments and added "Size" option Description (updated) --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru This addresses bug 267365. http://bugs.kde.org/show_bug.cgi?id=267365 Diffs (updated) - kimgio/CMakeLists.txt 26329c0 kimgio/webp.cpp PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/webp.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106300/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Re: new WebP image plugin (kimgio) and cmake question
After a too long time, I try it again: On Saturday 01 September 2012 10:34:27 Martin Koller wrote: > Hi all, > > I've implemented a new kimgio plugin for the WebP image format. > read/write with variable quality is supported. > > - how can I add a new MIME Type for image/x-webp ? There was a comment by David Faure: > Follow the instructions at > http://www.freedesktop.org/wiki/Specifications/AddingMIMETutor > in order to submit the mimetype definition for inclusion into > shared-mime-info itself [which I can do, then]. However in the meantime somebody did that already: https://bugs.freedesktop.org/attachment.cgi?id=77271&action=edit although it seems unclear if the mime type shall be image/webp or image/x-webp and also I think the magic check is wrong and should only be see https://developers.google.com/speed/webp/docs/riff_container?hl=ru#webp-file-header > - given that this is in kdelibs, in which branch could I commit this ? > > I did already create a review request: > https://git.reviewboard.kde.org/r/106300/ Is this something which can be included into 4.11, and if so, where ? If it's not possible for kdelibs, I could also include it into the kolourpaint repository (given that I'm the maintainer of 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
Re: Review Request 106300: add kimgio WebP image format plugin
On Tuesday 21 May 2013 21:34:23 Christoph Feck wrote: > > > On May 18, 2013, 12:44 p.m., Commit Hook wrote: > > > This review has been submitted with commit > > > df845b06bc440fff5a43a9cdc149e8c88c29bc67 by Martin Koller to branch > > > master. > > Just noticed this has been committed to kolourpaint instead of kdelibs. Did I > miss a discussion about this change? Probably. I sent again an email to kde-core-devel on May 11th, which was ignored, so I thought nobody cared. As the deadline for 4.11 approached, I decided to commit this to kolourpaint, which I'm the maintainer of, to at least have it in 4.11 > > > - Christoph > > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106300/#review32734 > ------- > > > On May 18, 2013, 12:44 p.m., Martin Koller wrote: > > > > --- > > This is an automatically generated e-mail. To reply, visit: > > http://git.reviewboard.kde.org/r/106300/ > > --- > > > > (Updated May 18, 2013, 12:44 p.m.) > > > > > > Review request for kdelibs. > > > > > > Description > > --- > > > > This patch adds support for the new Google invented WebP image format. See > > https://developers.google.com/speed/webp/?hl=ru > > > > > > This addresses bug 267365. > > http://bugs.kde.org/show_bug.cgi?id=267365 > > > > > > Diffs > > - > > > > kimgio/CMakeLists.txt 26329c0 > > kimgio/webp.cpp PRE-CREATION > > kimgio/webp.desktop PRE-CREATION > > kimgio/webp.h PRE-CREATION > > > > Diff: http://git.reviewboard.kde.org/r/106300/diff/ > > > > > > Testing > > --- > > > > some KDE apps, including read/write with a modified kolourpaint (to be able > > to change the quality) > > > > > > Thanks, > > > > Martin Koller > > > > > -- 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 106300: add kimgio WebP image format plugin
On Wednesday 22 May 2013 22:15:56 Albert Astals Cid wrote: > > > On May 18, 2013, 12:44 p.m., Commit Hook wrote: > > > This review has been submitted with commit > > > df845b06bc440fff5a43a9cdc149e8c88c29bc67 by Martin Koller to branch > > > master. > > > > Christoph Feck wrote: > > Just noticed this has been committed to kolourpaint instead of kdelibs. > > Did I miss a discussion about this change? > > If you addressed Allan's comment i'd sincerely put it where it belongs, which > is obviously not kolourpaint :D Where does it belong to, as kdelibs is feature-frozen ? -- 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 106300: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106300/ --- (Updated May 26, 2013, 12:12 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru This addresses bug 267365. http://bugs.kde.org/show_bug.cgi?id=267365 Diffs - kimgio/CMakeLists.txt 26329c0 kimgio/webp.cpp PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/webp.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106300/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Review Request 110649: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110649/ --- Review request for KDE Runtime. Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru This is what was submitted before in https://git.reviewboard.kde.org/r/106300/ but it was suggested to move it to kde-runtime Diffs - kimgio/webp.h PRE-CREATION kimgio/webp.xml PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/CMakeLists.txt PRE-CREATION kimgio/webp.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/110649/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Re: Review Request 110649: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110649/ --- (Updated May 26, 2013, 12:20 p.m.) Review request for KDE Runtime. Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru This is what was submitted before in https://git.reviewboard.kde.org/r/106300/ but it was suggested to move it to kde-runtime Diffs - kimgio/webp.h PRE-CREATION kimgio/webp.xml PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/CMakeLists.txt PRE-CREATION kimgio/webp.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/110649/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Re: Review Request 110649: add kimgio WebP image format plugin
> On May 26, 2013, 2:15 p.m., Fredrik Höglund wrote: > > kimgio/webp.cpp, line 58 > > <http://git.reviewboard.kde.org/r/110649/diff/1/?file=146351#file146351line58> > > > > This is not particularly efficient. WebPDecodeBGRAInto() can decode > > directly into a QImage without using an intermediate buffer. As far as I understand the QImage documentation, I can not use this: "You cannot use the uchar* pointer directly, because the pixel format depends on the byte order on the underlying platform. Use qRed(), qGreen(), qBlue(), and qAlpha() to access the pixels." I understood it as: WebPDecodeRGBA() delivers always 4 consecutive bytes as RGBA, regardless of the endianess of the platform, but QImage::bits() returns a pointer to the data which contains the bytes in the order of the platform, which might be different than what WebPDecodeRGBA() delivers. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110649/#review33153 ------- On May 26, 2013, 12:20 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110649/ > --- > > (Updated May 26, 2013, 12:20 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > This patch adds support for the new Google invented WebP image format. See > https://developers.google.com/speed/webp/?hl=ru > > This is what was submitted before in > https://git.reviewboard.kde.org/r/106300/ but it was suggested to move it to > kde-runtime > > > Diffs > - > > kimgio/webp.h PRE-CREATION > kimgio/webp.xml PRE-CREATION > kimgio/webp.desktop PRE-CREATION > kimgio/CMakeLists.txt PRE-CREATION > kimgio/webp.cpp PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/110649/diff/ > > > Testing > --- > > some KDE apps, including read/write with a modified kolourpaint (to be able > to change the quality) > > > Thanks, > > Martin Koller > >
Re: Review Request 110649: add kimgio WebP image format plugin
> On May 26, 2013, 6:45 p.m., Albert Astals Cid wrote: > > How is this hooked up to the rest of kde-runtime? The patch missed the diff of the CMakeLists.txt file from kde-runtime directly. I'll upload a new diff - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110649/#review33167 --- On May 26, 2013, 12:20 p.m., Martin Koller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110649/ > --- > > (Updated May 26, 2013, 12:20 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > This patch adds support for the new Google invented WebP image format. See > https://developers.google.com/speed/webp/?hl=ru > > This is what was submitted before in > https://git.reviewboard.kde.org/r/106300/ but it was suggested to move it to > kde-runtime > > > Diffs > - > > kimgio/webp.h PRE-CREATION > kimgio/webp.xml PRE-CREATION > kimgio/webp.desktop PRE-CREATION > kimgio/CMakeLists.txt PRE-CREATION > kimgio/webp.cpp PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/110649/diff/ > > > Testing > --- > > some KDE apps, including read/write with a modified kolourpaint (to be able > to change the quality) > > > Thanks, > > Martin Koller > >
Re: Review Request 110649: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110649/ --- (Updated May 30, 2013, 10:11 a.m.) Review request for KDE Runtime. Changes --- include toplevel CMakeLists.txt diff Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru This is what was submitted before in https://git.reviewboard.kde.org/r/106300/ but it was suggested to move it to kde-runtime Diffs (updated) - CMakeLists.txt 9f1f886 kimgio/CMakeLists.txt PRE-CREATION kimgio/webp.cpp PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/webp.h PRE-CREATION kimgio/webp.xml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/110649/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Re: Review Request 110649: add kimgio WebP image format plugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110649/ --- (Updated June 16, 2013, 11:58 a.m.) Review request for KDE Runtime. Changes --- changed image decoding to directly read into memory owned by QImage Description --- This patch adds support for the new Google invented WebP image format. See https://developers.google.com/speed/webp/?hl=ru This is what was submitted before in https://git.reviewboard.kde.org/r/106300/ but it was suggested to move it to kde-runtime Diffs (updated) - CMakeLists.txt 9f1f886 kimgio/CMakeLists.txt PRE-CREATION kimgio/webp.cpp PRE-CREATION kimgio/webp.desktop PRE-CREATION kimgio/webp.h PRE-CREATION kimgio/webp.xml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/110649/diff/ Testing --- some KDE apps, including read/write with a modified kolourpaint (to be able to change the quality) Thanks, Martin Koller
Re: Review Request 106300: add kimgio WebP image format plugin
On Sunday 16 June 2013 01:13:13 Christoph Feck wrote: > > > On May 18, 2013, 12:44 p.m., Commit Hook wrote: > > > This review has been submitted with commit > > > df845b06bc440fff5a43a9cdc149e8c88c29bc67 by Martin Koller to branch > > > master. > > > > Christoph Feck wrote: > > Just noticed this has been committed to kolourpaint instead of kdelibs. > > Did I miss a discussion about this change? > > > > Albert Astals Cid wrote: > > If you addressed Allan's comment i'd sincerely put it where it belongs, > > which is obviously not kolourpaint :D > > This still is only in kolourpaint, which is unfortunate. Bug 267365 is a KDE > general feature request. People who do not install kolourpaint will be left > out. > > Additionally, having it installed will make it work with other Qt programs > (Gwenview etc.), but not the thumbnailer. I cannot add the mime type to the > thumbnailer, if the plugin is only in kolourpaint. > > AFAIK, it was decided to move it to kde-runtime. I created a new review request for kde-runtime: http://git.reviewboard.kde.org/r/110649/ I hopefully solved the last open comment from Fredrik Höglund today, so I'm waiting now for the final "ship it" and hope that this move from kolourpaint to kde-runtime isn't now too late for 4.11 -- 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: 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
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
