Re: Please, return removed Konqueror feature bug (embedded advanced text editor) in KDE 4.6
On Saturday, 16. April 2011, David Faure wrote: On Friday 15 April 2011, Vladimir Koković wrote: HI, Please, return removed Konqueror feature bug (embedded advanced text editor) in KDE 4.6 !!! Wrong list, and wrong request. We didn't remove such a feature. If it doesn't appear anymore, then it must mean you don't have katepart installed. In KDE3 konqueror was never able to edit text with the embedded text view. By accident, this was possible in KDE 4.5. In KDE 4.6 we are back to read- only-mode in the embedded text part. Changing this is rather simple, but the question is whether you want Konqueror to be the app to also modify everything. That's why it's on kcd. See also: https://bugs.kde.org/show_bug.cgi?id=259338 Greetings Dominik
Re: Help in modularization
On Wednesday 13 April 2011, Joel Bodenmann wrote: So you'd need some help? Tell me what and give me some introductions etc.. It took me some time to respond because I thought I haven't written down anything yet... but actually I have already: http://techbase.kde.org/Development/CMake/DashboardBuilds This wiki page is now one year old. First thing to do would be to check that everything the page says is still correct and works. The nightly-scripts probably have to be adapted for git. When we have different configurations for kdelibs, we basically need nightly builds for these configurations. I.e. there should be a box which builds these configurations everyday, maintained by somebody who checks everyday that everything is still fine, i.e. updates dependencies etc. whenever required. Alex
Review Request: KConfig: Fix warning when compiling with GCC 4.6
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101138/ --- Review request for kdelibs and David Faure. Summary --- Fix annoying warning when compiling with GCC 4.6. Diffs - kdecore/config/conversion_check.h 8562046 Diff: http://git.reviewboard.kde.org/r/101138/diff Testing --- Thanks, Christoph
Re: Review Request: KConfig: Fix warning when compiling with GCC 4.6
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101138/#review2679 --- Ship it! i suppose it can do no harm ... - Oswald On April 16, 2011, 3:11 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101138/ --- (Updated April 16, 2011, 3:11 p.m.) Review request for kdelibs and David Faure. Summary --- Fix annoying warning when compiling with GCC 4.6. Diffs - kdecore/config/conversion_check.h 8562046 Diff: http://git.reviewboard.kde.org/r/101138/diff Testing --- Thanks, Christoph
Thursday, April 28, 2011: KDE 4.7 Soft Feature Freeze
Hi, Just a reminder that the soft feature freeze is rapidly approaching: http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule#Thursday.2C_April_28.2C_2011:_KDE_4.7_Soft_Feature_Freeze Add your features to the Feature Plan so you can work on it until the hard freeze here: http://techbase.kde.org/Schedules/KDE4/4.7_Feature_Plan For the complete schedule, now and in the future, add the ics to your favorite calendaring app: http://www.kde.org/releaseschedule.ics Best, Toma -- Tom Albers KDE Sysadmin
Review Request: Consider data: URLs local in KIO::AccessManager
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/ --- Review request for kdelibs. Summary --- Currently KIO::AccessManager blocks retrieval of embedded data: URLs if external references are disabled. This does not match the behavior in KHTML and breaks for example the display of sender photos/logos in KMail (which uses kdewebkit). Diffs - kio/kio/accessmanager.cpp bfb4721 Diff: http://git.reviewboard.kde.org/r/101140/diff Testing --- Thanks, Volker
Re: Review Request: Consider data: URLs local in KIO::AccessManager
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/#review2680 --- Wouldn't it make more sense to change KProtocolInfo::protocolClass() such that it considers data: to be local access? - Kevin On April 16, 2011, 4:27 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/ --- (Updated April 16, 2011, 4:27 p.m.) Review request for kdelibs. Summary --- Currently KIO::AccessManager blocks retrieval of embedded data: URLs if external references are disabled. This does not match the behavior in KHTML and breaks for example the display of sender photos/logos in KMail (which uses kdewebkit). Diffs - kio/kio/accessmanager.cpp bfb4721 Diff: http://git.reviewboard.kde.org/r/101140/diff Testing --- Thanks, Volker
Re: Review Request: Improvements to KFileDialog filtering
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101013/#review2681 --- Ship it! No problem, then please commit as is. - Christoph On April 2, 2011, 11:47 p.m., Parker Coates wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101013/ --- (Updated April 2, 2011, 11:47 p.m.) Review request for kdelibs. Summary --- This patch attempts to improve the usefulness and usability of KFileDialog's filter field when in Opening mode. Firstly, if the filter text isn't: * the display name of one of the filters passed to the dialog or * one or more space separated mimetype specifiers (containing a '/') or * one or more space separated file globs (containing '*', '?' or [.*]) we convert the text to a glob by prepending and appending asterisks. This lets the user enter a piece of text (without having to know any glob patterns) and see only the files whose names contain that text, much the same as they would when filtering in Dolphin. Secondly, the filtering updates on the fly as the filter text is typed. Previously, the filtering updated only when Return was pressed, which differs from the behaviour of most of KDE's other filter boxes. The old behaviour is especially confusing when one clicks the small clear button embedded in the combobox, because it clears the box, but the filtering is unchanged until the user goes to the keyboard to press enter. This addresses bug 142900. http://bugs.kde.org/show_bug.cgi?id=142900 Diffs - kfile/kfilewidget.cpp 9b8cdeb Diff: http://git.reviewboard.kde.org/r/101013/diff Testing --- I've played around with it a fair bit and it seems to work fine. I've never really worked with this code before, so if I'm doing something silly please let me know. Thanks, Parker
Re: Review Request: Add a GUI to configure window's title bar blend colours
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100821/#review2682 --- Ship it! Okey, it looks like deKorator is the only decoration that needs the button colors, and I am going to change button coloring there anyway, so please commit as is (to master, because of added strings). - Christoph On March 8, 2011, 5:23 p.m., Jonathan Marten wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100821/ --- (Updated March 8, 2011, 5:23 p.m.) Review request for KDE Base Apps and kwin. Summary --- Some of the still available window decorations (KDE2, Keramik, Modern System, Quartz, Redmond) use two colours for the title bar, either as a blend or for different parts of the bar. This patch extends the GUI in System Settings to allow the blend colour to be configured. This addresses bug 225837. http://bugs.kde.org/show_bug.cgi?id=225837 Diffs - kcontrol/colors/colorscm.h 7627db8 kcontrol/colors/colorscm.cpp 571ed86 kcontrol/colors/colorsettings.ui efd618b Diff: http://git.reviewboard.kde.org/r/100821/diff Testing --- Built kde-workspace with these changes, verified operation of systemsettings and KDE2 window decoration. Screenshots --- kcontrol screenshot http://git.reviewboard.kde.org/r/100821/s/93/ Thanks, Jonathan
Re: Review Request: Consider data: URLs local in KIO::AccessManager
On April 16, 2011, 4:45 p.m., Kevin Krammer wrote: Wouldn't it make more sense to change KProtocolInfo::protocolClass() such that it considers data: to be local access? That was indeed my first attempt, but David pointed out that this would have further (security) implications, since the protocol class is also used in a number of different places where the use of data: might not be desired. Instead, I followed the approach chosen by KHTML now, explicitly white-listing data: only for retrieval but nothing else. - Volker --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/#review2680 --- On April 16, 2011, 4:27 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/ --- (Updated April 16, 2011, 4:27 p.m.) Review request for kdelibs. Summary --- Currently KIO::AccessManager blocks retrieval of embedded data: URLs if external references are disabled. This does not match the behavior in KHTML and breaks for example the display of sender photos/logos in KMail (which uses kdewebkit). Diffs - kio/kio/accessmanager.cpp bfb4721 Diff: http://git.reviewboard.kde.org/r/101140/diff Testing --- Thanks, Volker
kwin crashes short after start
Hello! With a new account, after loging, I get everytime a crash at: ... #7 0x7f38b20627f1 in KWin::GLShader::load (this=0x1e4e520, vertexSource=..., fragmentSource=...) at /home/guy-kde/kdesvn/kde- workspace/kwin/libkwineffects/kwinglutils.cpp:785 May I get any help? What/where is to look for? What is missing? Thanks -- guy
Re: kwin crashes short after start
On Saturday 16 April 2011, Guy Maurel wrote: Hello! With a new account, after loging, I get everytime a crash at: ... #7 0x7f38b20627f1 in KWin::GLShader::load (this=0x1e4e520, vertexSource=..., fragmentSource=...) at /home/guy-kde/kdesvn/kde- workspace/kwin/libkwineffects/kwinglutils.cpp:785 May I get any help? What/where is to look for? What is missing? kwin - https://mail.kde.org/mailman/listinfo/kwin Disabling desktop effects should prevent the crash. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Please, return removed Konqueror feature bug (embedded advanced text editor) in KDE 4.6
On Saturday 16 April 2011, Dominik Haumann wrote: On Saturday, 16. April 2011, David Faure wrote: On Friday 15 April 2011, Vladimir Koković wrote: HI, Please, return removed Konqueror feature bug (embedded advanced text editor) in KDE 4.6 !!! Wrong list, and wrong request. We didn't remove such a feature. If it doesn't appear anymore, then it must mean you don't have katepart installed. In KDE3 konqueror was never able to edit text with the embedded text view. By accident, this was possible in KDE 4.5. In KDE 4.6 we are back to read- only-mode in the embedded text part. Changing this is rather simple, but the question is whether you want Konqueror to be the app to also modify everything. That's why it's on kcd. I always found it extremely irritating that I couldn't edit a text file opened in the embedded text view. For me this makes the embedded text view mostly useless. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Review Request: Consider data: URLs local in KIO::AccessManager
On April 16, 2011, 4:45 p.m., Kevin Krammer wrote: Wouldn't it make more sense to change KProtocolInfo::protocolClass() such that it considers data: to be local access? Volker Krause wrote: That was indeed my first attempt, but David pointed out that this would have further (security) implications, since the protocol class is also used in a number of different places where the use of data: might not be desired. Instead, I followed the approach chosen by KHTML now, explicitly white-listing data: only for retrieval but nothing else. Dawit Alemayehu wrote: Well I guess I am the one that broke this in an attempt to make it more generic. The change seems fine, but you patch should then do the following: if (scheme.compare(QL1S(data), Qt::CaseInsensitive) == 0) return true; if (KProtocolInfo::isKnownProtocol(scheme) KProtocolInfo::protocolClass(scheme).compare(QL1S(:local), Qt::CaseInsensitive) == 0) return true; return false; since isLocalRequest is more likely to encounter the data protocol than any other local protocol. The case-insensitive comparisson seems unnecessary, KUrl::protocol() already returns a lower-cased string. Regarding the reordering, isn't file: the most likely local protocol? I don't know where else this is used, but in KMail it definitely is much more common than data:. - Volker --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/#review2680 --- On April 16, 2011, 4:27 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/ --- (Updated April 16, 2011, 4:27 p.m.) Review request for kdelibs. Summary --- Currently KIO::AccessManager blocks retrieval of embedded data: URLs if external references are disabled. This does not match the behavior in KHTML and breaks for example the display of sender photos/logos in KMail (which uses kdewebkit). Diffs - kio/kio/accessmanager.cpp bfb4721 Diff: http://git.reviewboard.kde.org/r/101140/diff Testing --- Thanks, Volker
Re: Review Request: GUI configuration for the 'Do Not Track'?feature...
On Sat, Apr 16, 2011 at 11:54 AM, Oswald Buddenhagen o...@kde.org wrote: On Fri, Apr 15, 2011 at 09:00:11PM +0200, Ingo Klöcker wrote: On Friday 15 April 2011, Oswald Buddenhagen wrote: On Fri, Apr 15, 2011 at 09:24:47AM -0400, Dawit Alemayehu wrote: The configuration option is there to allow the user to opt-in if they so choose. that's not a very wise default. if too many people will use it (*), the data miners will just ignore the standard, based on the rightful claim that most people didn't even explicitly say they don't want to be tracked. Sorry, but this argumentation is ridiculous. Bad data miners will ignore the standard no matter what. that's besides the point. data mining is their business. with that flag on, there is no business. the only way to make them respect user privacy is either law or just making the opt-out share small enough that they don't care too much. if you default to opt-out, you give them the perfect excuse for ignoring it. Though I agree with the premise, you argument is not entirely correct and using it as a justification for why the opt-out should not be default is completely wrong. First, the idea that DNT affects most sites lively hood is something that has already been dispelled. For most sites, there is no reason to track your browsing habits to provide reasonable advertising on their pages. For example, if you were to visit a wine related page, then it is reasonable for you to expect to see wine related ads on that page. The idea of specifically targeting ads based on more specific information is mostly the domain of sites that collect vast amount about you and what you do online, e.g. google/facebook. There a lot more information about this and related subject at http://donottrack.us. Second, even if we completely accept your premise, then why exactly would it hurt the user for us to include the OPT-OUT header by default ? The sites that want to ignore that header will ignore it anyhow regardless. So what exactly is lost by simply sending the header by default ? Not sending it however means that you get no protection even at those sites that have already implemeted support for this feature. If you think that is a complete hogwash and no site will do this willingly, then may I suggest you read http://firstpersoncookie.wordpress.com/2011/03/30/industry-adoption-of-dnt-underway/. if you want to encourage people to make use of this privacy protection mechanism, you should pop up a dialog if no preference has been configured yet. You do realize that people do not read dialogs? Most users will have no clue what the dialog is talking about and just click Yes. do you realize that most people honestly couldn't care less? and they don't deserve better. let them enjoy their free internet. Well that seems like the perfect argument why the OPT-OUT should be the default. It is a well established fact that most users could not be bothered to think about security or privacy issues until they get bitten by it. Hence, the more reason why software should strive more to do right by them as much as possible. fwiw, the firefox 4 default is opt-in. and for some reason the setting isn't even under privacy, but under advanced. They will change it soon enough. For the life of me, I cannot imagine of a single person that would voluntarily opt-in to be tracked online. They have to be completely ignorant about the matter or threatened with lack of access to capitulate on this issue. Regards, Dawit A.
Re: Review Request: Consider data: URLs local in KIO::AccessManager
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/#review2686 --- Ship it! Hmm... did not know KUrl::protocol() already returned a lower case text. And it is probably true the file protocol might be more previlant when access to external content is disallowed. Well then go ahead... Do not forget to backport or forward port depending on how you work :) - Dawit On April 16, 2011, 4:27 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101140/ --- (Updated April 16, 2011, 4:27 p.m.) Review request for kdelibs. Summary --- Currently KIO::AccessManager blocks retrieval of embedded data: URLs if external references are disabled. This does not match the behavior in KHTML and breaks for example the display of sender photos/logos in KMail (which uses kdewebkit). Diffs - kio/kio/accessmanager.cpp bfb4721 Diff: http://git.reviewboard.kde.org/r/101140/diff Testing --- Thanks, Volker
